Telling a real product strategy from a dressed-up roadmap
The Product Leaders work group on the choices, staffing and customer conversations that separate a strategy from a list of features.
Updated
A strategy shows up as decisions about who the team builds for, which requests it declines and where people are staffed, made before the results are certain.
- Look for choices that rule work out. Jiaona Zhang looks for decisions that change what the team builds, who it builds for and where people go. Webflow chose professionals replacing developer work on marketing sites over small businesses, which gave the team a reason to pass on work aimed at the first group.
- Check that headcount carries the choice. Jiaona expects a priority area to have a team staffed to go deep, with fewer people on work being maintained. Tamar Yehoshua notes that a stated choice alone can't show this. She would look at which problems earned a staffed team and which requests were declined or delayed before the roadmap was final.
- Name the behavior the plan should change. Noah Desai Weiss would ask what customer behavior the plan expects to change, why this approach should change it and how the team will learn whether it was right. At Slack, after hundreds of small onboarding experiments while growth had plateaued, the team rebuilt the whole first-day experience.
- Ask what the team would stop. Noam Lovinsky would ask which staffed project the team would stop to make room for the bet it says matters most. At YouTube he argued that roughly 50 engineers on the rebuild he led would do more for the business elsewhere, and leadership wound the project down.
- A strategy changes the customer conversation. At Figma, the goal of helping the whole product team work around design gave Yuhki Yamashita a reason to invest in collaboration while customers asked for individual features and offline use. When a customer brought ten requests, he would set them beside the other work under consideration and ask which mattered more.
Ask a follow-up
Product Leaders
Frequently Asked Questions
What goes into a good product strategy?
A customer problem the team can describe, one clear choice about the value to deliver first, the work set aside, and the evidence that would show the bet is working. It should let the team explain a specific 'no' to an important customer.
How do you run customer interviews that change what you build?
Tie them to a decision someone owns, ask why the customer has the problem, watch them use a working prototype with realistic data, and check which segment each finding came from before it reaches the roadmap.
How do you scope an MVP?
Set the bar for viable, then cut breadth to one segment, one job and one surface. Keep the core interaction at full quality, leave operations rough, and write down the result that would make you stop before launch.
How should a product team handle feature requests?
Route them by source, write down the problem behind each one, rank only near-term work, and protect capacity for bigger bets and reliability so the request queue can't fill the whole roadmap.
How do you tell whether a new feature worked?
Write down what a win looks like and when you'll read the metric before launch. Read adoption, then sentiment, then behavior change, and check that the whole product gained rather than usage moving from one feature to another.
How do product managers keep stakeholders aligned on scope?
Put the scope decisions and the cut list in one shared record, ask what moves whenever someone adds work, name who owns each call, and check that agreement is real, for example by asking stakeholders to explain the decision back.
How do you forecast delivery for a project full of unknowns?
Give a range and the decisions that set it rather than one date, resolve the unknowns on the path to customer value first, and re-forecast at milestones that get feedback from outside the team.
How is AI changing the way product teams are organized?
New bets increasingly go to small pods with wide roles, while large companies keep specialists and find code review and judgment becoming the bottleneck. Either way, someone on the team still has to push for the user.
What makes a product brief useful?
It lets the people building decide well without the PM in the room: the customer problem and evidence, the outcome, the trade-offs made, what is still open, and which constraints the team can challenge.
