In a previous post, I defined Stailer as a platform and explored how that platform should expand its reach.
As described there, the Stailer platform will carry features with general-purpose interfaces, delivered as applications to partners. Through operating and developing those applications, Stailer indirectly supports end users' experiences and drives GMV growth — that's the business model.
How Does Online Grocery Grow?
To think about "what features Stailer should build," the most important starting point is understanding how online grocery GMV grows structurally, and then aligning Stailer's own structure to that growth model.
No matter how rare, technically sophisticated, or successful-elsewhere an idea might be — if it doesn't fit this structural alignment, it won't generate repeatable impact on the business. As with people and businesses, the skeleton is what matters most.
I've mapped out the growth structure for online grocery as a Flywheel. The blue boxes represent the key issues (levers) that spin this flywheel, and their size represents the magnitude of their impact. Since Stailer's business aims to be perfectly aligned with net supermarket growth, the Flywheel also represents Stailer's growth structure.
To set up the next discussion, let me organize the Flywheel in table form, mapping each lever to the business impact it drives.
Flywheel P# (Priority) corresponds especially to the top of the purchase funnel and supply chain. Issues at the top of the chain must move first for the flywheel to spin — making them higher business priorities.
(Flywheel P#2 has three items listed in parallel because I believe priority order among them can shift depending on the service's phase.)
Are Business Impact and Customer Experience Independent?
So far I've looked at the online grocery Flywheel from a purely business perspective. But should "customer experience" be treated as independent from this priority ordering?
The answer is no. In general, customer experience should be built in tandem with the Flywheel — and the more a lever is at Flywheel P#, the more dominant its impact on customer experience tends to be.
Organizing this the same way as before in table form:
From this, "basically" every development and business issue can be connected to the Flywheel. Spinning the flywheel should drive growth in both customer experience and business outcomes (partner success).
Conversely, unless this growth compounds, the flywheel won't spin, and reinvestment won't happen. For Stailer, the discipline of continually attacking the largest issues to spin the flywheel faster and larger is critical to long-term value growth.
Understanding the Scale of Each Issue
Each Flywheel issue has different requirements for what it takes to move it.
For example, P#5 Maximize Discovery and P#6 Deepen Relationships can generate impact largely through Stailer application improvements alone — there are many issues in these areas that can be tackled quickly and experimentally. However, the achievable outcomes here tend to be incremental 1.1x improvements, not 2x leaps.
By contrast, P#1 Open Stores / Areas / Access, P#2 Increase Supply Slot Flexibility, and P#2'' Optimize Assortment / Pricing each require partnership changes, supply chain adjustments, and operational shifts every time. These can't be executed in a few weeks; they involve many stakeholders, are harder to execute, and take longer. But the payoff can be enormous — for example, doubling supply slots on a high-demand day could realistically double order volume.
Not drifting toward only "short-term, independent, small-win issues" — and continuing to invest in "long-term, complex, large-win issues" — is the discipline needed to keep growing Stailer's value over the medium and long term. What stones do you put in the jar, and in what order — that's what matters.
How to Think About Features Stailer Needs
Using this Flywheel, I want to think through "what features Stailer truly needs and in what priority — the roadmap."
Concretely, this means breaking down each Flywheel issue further through issue analysis to surface the required application issues = features. For each feature, we continuously input information such as QCD estimates, impact size, and partner demand — through conversations with business units and partners, and behavioral data analysis. These inputs are integrated to expand the item list and refine priorities.
At this stage, though, impact estimates are just estimates. Continuous updates based on real feedback from execution and exploration are essential. And having all the information in front of you doesn't automatically determine priorities — roadmaps get much more complex in reality. That's when strong leadership is required, not just appropriate governance.
The roadmap built this way is intended to function as a compass — connected to the actual work of scoping, developing, and operating features.
A Note on Issue Analysis: One personal rule of thumb from product and business development: the deeper you get into the issues in front of you, the easier it is to lose objectivity and completeness. Issue analysis is meant to guard against that risk, with the goal of exploring "which issue should we solve right now, across the whole picture?" and "how should we allocate investment across each Flywheel issue?" It's actually not well-suited for discussing the specifics of individual issues in depth (though that is equally important) — the information density becomes too high.
Why Does a Roadmap Exist?
Before getting into the specifics, it's worth explaining why a roadmap needs to exist at all.
Simply put: to create a shared language for all stakeholders around the product, reducing cognitive load and communication overhead.
Products involve many stakeholders — internal builders, customers using the product, analysts tracking usage and insights, potential customers evaluating adoption, and more. The roadmap is the interface for consistent communication with all of them.
Maintaining a roadmap enables:
- Incorporating diverse perspectives on customer value, business impact, and more into planning
- Giving internal and external stakeholders a common basis for discussion
- Making it possible to clearly discuss and decide what to build next
- Appropriately calibrating expectations with partners about future capabilities
Stailer's Roadmap
With that groundwork laid, let's actually break down the Flywheel issues and draft the roadmap. The following is a screenshot of the initial internal roadmap draft.
The master roadmap database includes annotations such as "estimated release timing," "partner names requesting this feature," and "team responsible for development."
Note: this is created in Notion DB, but the DB was too large to cleanly format, so these are raw screenshots — apologies for the readability. Desktop viewing recommended.
This roadmap is also, in effect, a list of the issues the company is confronting.
Items on the roadmap are roughly equivalent to user stories in Agile terms. In their current form they're not ready for development — they'll need to be broken into Epics and tickets, with specs and other documents written, estimates made, and retrospectives run before actual development begins.
Managing the Roadmap Going Forward
A roadmap isn't written once and forgotten. What matters most is:
- Continuously integrating and reflecting updates from business, customer, and technical perspectives
- Keeping the roadmap as the master source and updating it continuously
- Ensuring that business development and product development activities and priorities are clearly aligned with the roadmap
To achieve these, the company needs an official roadmap governance body — and I believe that is what true product management at a company level looks like.
(The governance structure is still in early stages, but this is roughly what I'm envisioning:)
Starting in July 2022, I'm returning to lead product management at 10X — a function I had stepped back from since 2020. The first order of business is creating the roadmap governance body described above and building it into a company-wide practice.
At the same time, I want to build a product management organization that achieves both: completely eliminating individual dependency and key-person risk, and maximizing the kind of deep, first-hand insight and conviction that comes from individual PMs doing their own deep dives into real customer problems.
Stailer currently serves 8 partners. I want to drive further product transformation with two parallel engines: advancing value through feature development, and securing scalability through platform development.
If you're interested in leading, wrestling with, and delivering to customers alongside our product team — and then watching their reactions, riding the highs and lows — I'd genuinely love to hear from you. I'm looking forward to conversations and debates with many people through this post.
