Building products in uncertainty: solution and outcome hypotheses

Executive overview

Most teams measure success by whether they finished what they were told to build. The real question is whether it worked — and whether it mattered.

Scott Sehlhorst distils lean product thinking into two paired hypotheses: a solution hypothesis (did we solve the right need?) and an outcome hypothesis (did it move the business?). These operate as nested feedback loops, connecting team-level learning to executive decision-making.

The shift from "did we finish?" to "did it work?" changes everything downstream — from how teams write acceptance criteria to how leaders prioritise investment.

From zone of control to sphere of influence

• Feature factory teams define success as hitting a spec; lean teams define it as creating change for a user.
• User stories written around specifications ("update the API") lock teams in the zone of control.
• User stories written around user goals and observable outcomes move teams into the sphere of influence.
• This shift requires psychological safety: teams must be permitted to improve the plan, not just execute it.
• Command-and-control cultures resist this because teams are compensated for delivery, not learning.

The two-hypothesis framework

• A single "if we build X, we get Y" hypothesis is too large — teams crash on it.
• Break it into two: a solution hypothesis (team-level, fast loop) and an outcome hypothesis (leadership-level, slower loop).
• Solution hypothesis: if we build this, it will address a specific need; here is the observable change that proves it.
• Outcome hypothesis: if we create that change, here is the business result (reduced churn, higher CAGR, increased CLV).
• The observable change is the output of one hypothesis and the input to the other — this is where the loops connect.
• Engineers already reason this way about solutions; product managers bridge both conversations.

Writing outcome hypotheses that force critical thinking

• A well-formed outcome hypothesis includes: the problem, who has it, how big it is, and what a meaningful improvement looks like.
• Quantify the expected outcome — "20% lift in conversion" beats "higher conversion rate."
• Use estimation ranges where precision is impossible: "between 5% and 40% lift."
• Articulating this before committing budget surfaces whether the initiative is worth the cost.
• Comparing outcome hypotheses across initiatives changes prioritisation conversations: leaders can immediately see what to do first and what not to do at all.
• Lean principle: the best way to reduce waste is to not put it in the system.

Measuring adoption of the ways of working

• Counting "teams using the approach" is a weak metric because every team has a mix of BAU, hygiene, and discretionary work.
• A stronger metric: what proportion of features or epics in the backlog have a documented solution hypothesis with a quantified outcome and an estimation range?
• This shows how much of the active work embodies the practices — independent of team headcount.
• Transformation takes three to five years; the length depends on executive support and cultural willingness.
• The maturity signal is when the conversation shifts from "how do we start?" to "how do we get better?"

Why adoption fails

• The most common failure mode is teams that are unwilling — or not empowered — to engage with uncertainty.
• Organisations that compensate for delivery on plan leave no room to improve the plan.
• Some teams prefer the comfort of elegant solutions to explicit problems over discovering what problems are actually worth solving.
• This is a systems failure, not an individual one: the incentives, not the people, are the obstacle.