An unhurried, jargon-free guide. Each section develops one idea with everyday examples. Read it start to finish, or jump straight to the part you need.
Product strategy is the set of decisions that connect a company's broader goals to the specific things a team builds next. It answers three questions: who are we building for, what problem of theirs are we solving, and how will we know it worked.
It is not a roadmap with dates on it, and it's not a list of features a competitor shipped. A roadmap is what you do after the strategy is clear — it's the visible schedule, not the reasoning behind it.
Discovery is the work of confirming a problem is real and worth solving before any design or engineering time gets spent on it. The fastest version is five or six short interviews with people who actually have the problem — not a survey, which tells you what people say they'd do, not what they actually do.
A useful trick: ask about the last time the problem happened, in detail, instead of asking whether they'd like a feature that fixes it. People are far more honest about the past than about a hypothetical future.
Once you have more validated ideas than you have time to build, you need a way to compare them that isn't just whoever's argument was loudest in the meeting. Frameworks like RICE (Reach, Impact, Confidence, Effort) force the reasoning behind a ranking into the open, where the rest of the team can challenge it.
The score itself matters less than the conversation it creates. Teams that prioritize well usually argue about the inputs to the score, not about the final order.
Match the fidelity of what you build to the question you're trying to answer. A five-minute paper sketch can tell you whether the flow makes sense at all; you don't need a polished prototype to learn that the navigation confuses people.
Save the high-fidelity, fully clickable prototype for the moment you're testing something specific — wording, visual hierarchy, or a transaction flow — where the details genuinely change the answer.
A launch is a sequence, not a single moment. Internal teams hear first so support and sales aren't blindsided. A small group of existing users hears next, both to catch issues at low stakes and to build early word of mouth. The broader announcement comes last, once the rough edges are already gone.
Skipping straight to the broad announcement is the single most common launch mistake we see — it turns your most forgiving users into your most public bug reporters.
Pick one metric before you ship, not after — otherwise it's tempting to retroactively choose whichever number went up. A good metric reflects value delivered to the user, not just activity (a rising "clicks" count can mean people are succeeding quickly or struggling to find what they need; it doesn't tell you which).
Give a new release time to settle before judging it. Many metrics dip in the first days simply because existing users are reacting to change, then recover as the new behavior becomes normal.
The same handful of mistakes show up across most teams we've talked to: skipping discovery because "we already know what users want," prioritizing by opinion instead of a shared framework, and writing roadmaps with dates instead of outcomes — which quietly trains stakeholders to stop trusting the roadmap the first time a date slips.
None of these are complicated to fix. They're just easy to skip when a deadline is close, which is exactly when skipping them costs the most.
The glossary covers every term used in this guide in one or two plain sentences.
Open the glossary