Product Discovery and Roadmap

Decide what to build or change next by starting from an outcome instead of a feature list: map the customer opportunities behind it, name what your favorite idea depends on, test the riskiest piece, prioritize, and show the plan as outcomes, not dates.

Practice, not research: the outcome, opportunity and solution tree (Torres, 2021), RICE scoring (McBride, 2018) and outcome-based roadmaps (Lombardo et al., 2017) are practitioner tools, as are jobs-to-be-done and OKRs. The case for testing assumptions before committing has emerging experimental support (Camuffo et al., 2020). Every score and threshold on this page is a rule of thumb.

Use it when:

• You are moving into a product, operations or service role and need a method for deciding what comes next.
• A backlog has grown into a wish list, or a team keeps building things nobody uses.
• You are preparing a roadmap review with your manager and want to show outcomes, not just dates.

Skip it when:

• You do not yet know who the customer is or what job they hire your offer for: start with 6.4 Jobs-to-Be-Done Canvas.
• The decision is a company-level strategy, not a product or service: use 7.13 Strategy Roadmap (12-24 months).

Most plans start from a solution someone already likes, and the roadmap becomes a list of features with dates. Discovery reverses the order. Start with one outcome; find the opportunities behind it, meaning the needs, pains and jobs customers have (Christensen et al., 2016); then compare solutions, and for the leading one list what has to be true and test the riskiest assumption first (Torres, 2021; McGrath & MacMillan, 1995). An idea that fails in a two-day test is cheap; the same idea failing after three months of building is not. There is early experimental support: in a randomized trial with 116 Italian startups, founders taught to state and test hypotheses like scientists performed better and switched ideas more often (Camuffo et al., 2020). That is one trial with startups, not proof for every organization.

RICE scores reach, impact, confidence and effort (McBride, 2018); it makes reasoning visible, but every input is an estimate. An outcome roadmap groups work as now, next and later around the problem each part addresses (Lombardo et al., 2017). None of these tools has been tested against alternatives, and they assume you can reach customers; in regulated or safety-critical work some assumptions must be tested in other ways.

Strong answer: (illustrative) "Share of fault reports that come in through the app rises from about one in four to one in two by June." Not: "Build a chatbot for tenants."

The outcome we want (a change in behavior or a result, not a feature):

How we will measure it, and the level today:

The goal or key result it serves (see 1.10 1-Year Personal OKRs or your team's OKRs):

Illustrative example: the company, roles and all numbers are made up.

An operations specialist at a property management company in Uppsala becomes product owner for the tenant app. The board wants "a chatbot". She starts with the outcome: fewer fault reports by phone, measured as the share that arrive through the app, today about one in four.

From the customer service log and six tenant calls she finds three opportunities: tenants do not know whether a fault is already reported, they cannot attach a photo, and older tenants do not trust that an app report reaches anyone. She picks the third, because it explains most of the calls. Her three ideas: a confirmation text with a named technician and a time, a chatbot, and a printed guide in the stairwell. The riskiest assumption for the text is that tenants will read and believe it. She tests it by hand for two weeks in one building; success, set in advance, is that phone follow-ups on app reports fall noticeably. They do, so the text goes into Now with a RICE score well above the chatbot's, whose confidence stays low because nothing has tested it. The roadmap she shows the board has three outcomes, not features: "tenants trust app reports" (Now), "tenants can show the fault" (Next), "fewer repeat faults" (Later).