Evidence-based milestones for lean product development

Executive overview

Most companies track progress through stage gates: checkbox outputs that signal internal alignment rather than real-world traction. This approach assumes a linear path and produces decisions based on enthusiasm, not evidence.

Milestones in Lean Startup measure changes in human behavior — leading indicators of outcomes, not activity. They create a funnel that lets teams double down on what's working and confidently kill what isn't.

Stage gates vs. evidence-based milestones

• Stage gates are transactional: did you do the thing, check the box, move on
• Lean milestones are conversational, nuanced, and non-linear
• Evidence includes what customers say and what they do
• Progress isn't always linear — teams may loop before advancing
• Milestones allow comparison across a portfolio of initiatives

The four generic milestones

1. Customer hypothesis — Is there a real, impactful problem for a defined set of customers?
2. Value hypothesis — Does our solution address that problem? Is there evidence of traction?
3. Growth hypothesis — Do we have the right go-to-market, channels, and revenue model?
4. Scale hypothesis — Is the full business model ready for prime time? Are we at product-market fit?

Two bookends around the four

• Pre-milestone (strategy): Is this initiative aligned with what we said we should be working on? Backlog items should pass a strategic filter before any customer discovery begins.
• Post-scale: Once past scale, milestones shift to traditional accounting — growth rates, ROI, return on investment. Each product then tracks its own specific metrics.

Common mistakes

• Over-indexing on feasibility and viability early, at the expense of desirability
• Asking for ROI before any customer evidence exists — if you knew ROI with certainty, you wouldn't need Lean Startup
• Relying on out-of-the-box milestones without adapting to your environment (hardware vs. digital, regulated vs. agile)
• Treating milestones as a one-time design artifact rather than something to iterate on

Injecting ROI progressively

• Don't avoid ROI entirely — frame it as low-confidence, high-aperture early on
• One model: total addressable market at M1, serviceable addressable market at M2, obtainable market at M3
• If an executive demands a number now: give it, but state confidence is 5%; doing the milestone work raises it
• Use milestones as a roadmap for answering the ROI question rather than refusing to engage

Designing milestones for your context

• Start with a generic set during a pilot; learn by doing before locking in the design
• Hardware companies need early feasibility signals due to manufacturing implications; purely digital companies often do not
• Allow teams to set their own velocity targets rather than imposing generic timeframes
• Rename milestones to fit your culture (e.g., "problem validation" instead of "customer hypothesis")
• Not every initiative needs to start at milestone one — enter where uncertainty actually exists

Governance and alignment

• Leaders must know what they're holding teams accountable for — and which questions not to ask at which stage
• Without defined milestones, review meetings devolve into status updates with no basis for comparison
• When a senior leader suggests a new feature mid-review, the right response is "that goes in the backlog and runs through the milestones"
• Milestone design aligns the whole organisation on what progress looks like

Culture as the critical enabler

• Documented milestones fail if teams fear saying "we don't have evidence to proceed"
• Leaders must actively celebrate stopped initiatives, not just advancing ones
• A Department of Defense team was celebrated in a town hall for not making it through a milestone — that signal unlocked confidence across the whole program
• Killing an initiative is a win: it frees resources and avoids building something nobody wants
• Culture requires reinforcement through repeated leadership behavior, not process documentation alone