Most product teams don't fail because they can't build software. They fail because they build the wrong software very well.
I learned this in payments. When you co-own a payments P&L across 10+ markets, every sprint has a price. A payment method nobody uses still costs integration, certification and support time. A cheaper processing route that never ships is margin you give away every month.
The hard part was never the building. It was keeping a straight line from "grow payments revenue and cut cost" in the leadership deck to the ticket an engineer picks up on a Tuesday. Lose that line and you get a feature factory: a roadmap of outputs and dates where nobody can say what problem a feature solves.
This is the model I use to keep that line intact. Four layers of planning, two one-page canvases, and a loop that runs in both directions.
Four layers, each sharper than the last
Strategy isn't one document. It's a chain of decisions that get more specific as the time horizon gets shorter.
Delivery and metrics flow back up: they change the roadmap, and sometimes the strategy canvas.
The vision is the why: the change the product should make, five to ten years out. The strategy is the path to it: who the product is for, what problem it solves, how it wins, and what it's worth to the business.
The roadmap turns that into a sequence of goals for the next 6 to 12 months. Outcomes, not features. The backlog is the work for the current goal only: epics, stories, flows, designs and non-functional requirements.
The test I use is simple. Pick any ticket in the sprint and walk it up. If you can't reach the vision in three steps, ask why it's there.
Put the strategy on one page
Before any roadmap, I want the strategy on a single canvas. Five boxes: the vision across the top, then target group, needs, product and business goals. If the team can't fill it in, the roadmap will be guesswork.
Here's a simplified version for a payment facilitation (PayFac) product, the kind I launched at Delivery Hero. The details are illustrative.
Each box has a trap, and payments teams fall into all of them.
| Box | What it answers | The trap |
|---|---|---|
| Vision | What change do we want to create? | A revenue target ("hit $50M monthly GMV") or a tech choice ("build our own gateway") posing as a vision |
| Target group | Who uses it, and who pays? | "All merchants." A new strategy needs one narrow segment you can actually serve well |
| Needs | What problem do we solve? | A feature posing as a need ("merchants need Apple Pay"). Ask what job it does for them, then rank the needs |
| Product | Which 3 to 5 things set us apart? | A list of 25 payment methods, or table stakes like a merchant login |
| Business goals | Why is the company investing? | "Grow payments" with no link to the margin, cost or adoption you'll measure |
- Box
- Vision
- What it answers
- What change do we want to create?
- The trap
- A revenue target ("hit $50M monthly GMV") or a tech choice ("build our own gateway") posing as a vision
- Box
- Target group
- What it answers
- Who uses it, and who pays?
- The trap
- "All merchants." A new strategy needs one narrow segment you can actually serve well
- Box
- Needs
- What it answers
- What problem do we solve?
- The trap
- A feature posing as a need ("merchants need Apple Pay"). Ask what job it does for them, then rank the needs
- Box
- Product
- What it answers
- Which 3 to 5 things set us apart?
- The trap
- A list of 25 payment methods, or table stakes like a merchant login
- Box
- Business goals
- What it answers
- Why is the company investing?
- The trap
- "Grow payments" with no link to the margin, cost or adoption you'll measure
The canvas is a hypothesis until real merchants and users have tested it. Validate it before you plan against it.
Plan outcomes, not features
Most roadmaps are a list of features with dates. I flip that. Each column is a quarter or a release, and a goal sits at the centre of it.
Every column carries five things: a timeframe, a short name, one goal, three to five features, and the metrics that prove the goal was met. The goal pairs a user need with a business goal from the canvas. A feature only earns its place if it serves that goal.
Here's how the PayFac roadmap reads in that shape. The GMV numbers are what we hit; the features are simplified and the third column is illustrative.
| Months 1–2 | Months 3–6 | Next | |
|---|---|---|---|
| Name | Launch | Scale | Optimise |
| Goal | Get the first merchants paid on our own rails and prove the model | Move most merchants across and grow payment revenue | Cut the cost of every transaction |
| Features | Sub-merchant onboarding, core payment methods, payouts | More local payment methods, faster onboarding | Cost-based routing, 3-way reconciliation |
| Metrics | About $10M monthly GMV | $50M monthly GMV by month six | Lower processing cost per order |
- Name
- Months 1–2
- Launch
- Months 3–6
- Scale
- Next
- Optimise
- Goal
- Months 1–2
- Get the first merchants paid on our own rails and prove the model
- Months 3–6
- Move most merchants across and grow payment revenue
- Next
- Cut the cost of every transaction
- Features
- Months 1–2
- Sub-merchant onboarding, core payment methods, payouts
- Months 3–6
- More local payment methods, faster onboarding
- Next
- Cost-based routing, 3-way reconciliation
- Metrics
- Months 1–2
- About $10M monthly GMV
- Months 3–6
- $50M monthly GMV by month six
- Next
- Lower processing cost per order
Why this protects the backlog
I only pull the first column into the backlog. That one goal anchors the sprint goals, the epics and the stories.
The later columns stay rough on purpose. I'll know far more about them once the first goal meets real traffic.
The loop is the point
A plan that only flows down is a slide deck. Two habits keep it alive.
Let the evidence flow back up
As the team ships, I track two things. Are we delivering? That's velocity or burndown. Is it working? That's the metrics row on the roadmap.
The second one needs planning before you build. At Tabsquare, before we trained any recommendation model, we planned the event tracking: which items people clicked, which they added. Without that data the metrics row would have been a wish. With it, we could see what actually changed behaviour and feed that back into the roadmap.
When the data says a feature isn't landing, or a constraint changes the economics of a release, it goes back up. It changes the roadmap. Sometimes it changes the canvas.
Build it with the team, not for them
A strategy the team didn't shape is one they won't defend. When we built the open API and developer portal at foodpanda, much of what mattered for partner adoption sat with engineering and the partner team. A strategy memo written alone would have missed it.
So I prefer a strategy session at least once a quarter. The product leader runs it and makes the final call. Stakeholders, design and engineering leads test desirability, feasibility and viability in the same room. Someone neutral facilitates, so the loudest voice doesn't win by default.
Where to start
You don't need to stop delivery to fix a feature-factory roadmap.
Start with this quarter. Can you name the one goal, a user benefit plus a business benefit, that the current sprint serves? If not, that's your first conversation.
Then put your product on the canvas. The empty boxes, and the ones full of untested assumptions, show you where the strategy is thin.
Then use the goal as a filter. When a stakeholder asks you to squeeze in an urgent feature, ask one question: does this help the current goal, or does it belong in the next planning cycle?
The clearest example I have is a sales assistant I helped a client build: a RAG tool that gives reps product context before, during and after calls. The goal was never "ship a RAG pipeline". It was reps walking into calls knowing the product, and the measure was leads closed. That number doubled.
That's the shift. You stop counting what you shipped and start counting what changed.