Lore

Lean Product Process

Dan Olsen's downstream execution sequence once a Product Strategy Grid has identified the one performance benefit and delighter to build around:

  1. Brainstorm solutions for the chosen benefit/delighter
  2. Spec an MVP
  3. Prototype
  4. Validate with customers
  5. Build

The process deliberately sits after strategy and problem-space definition (Solution Discovery vs. Problem Discovery) — Olsen's claim is that most product failures come from starting here (jumping to solution/build) without having done the problem-space and grid work first.

Four Steps

Four Steps

Dan Olsen's process for turning a Product Strategy Grid conclusion into a product: brainstorm solution ideas for the chosen benefit, spec an MVP, prototype it, and validate with customer feedback before committing to full build. Treat the grid-derived strategy as a hypothesis, not a foregone conclusion — test it with a prototype and real users first.

Common Failure Mode: Must-Haves-Only MVPs

A recurring startup failure mode: a team falls behind schedule, so it ships an MVP containing only the must-have requirements (per the Kano Model) and no performance or delighter dimension. Because must-haves alone create no differentiated customer value, the MVP underperforms — and teams tend to blame the MVP methodology itself rather than the actual cause, which is that the shipped scope skipped the Product Strategy Grid dimensions that would have made it worth choosing.

Needs-to-ROI Handoff

Olsen splits prioritization into two phases that hand off into a Return/Effort ROI calculation: first, plot candidate problems on the Importance vs. Satisfaction (Opportunity) Framework quadrant to isolate upper-left, high-opportunity needs; only then brainstorm solution ideas for those specific needs and get them scoped. The quadrant's opportunity score feeds "Return," and the resulting solution's scope estimate feeds "Effort" — so scoping effort is spent only on ideas that already address a validated high-opportunity need, not on brainstormed features in general.

Hypothesis-Test-Iterate Framing

Verrilli's version of the loop: state the expected impact of a change explicitly as a hypothesis, design the smallest test that could check it, and let the result directly decide the next version of the plan — rather than only planning long-term or only shipping reactively. Paired with Play the Accordion (Alternating Zoom-Out/Zoom-In Cadence): the hypothesis is formed during the pulled-back planning phase, and the test is what gets pressed into a shipped V1.