Two opposite failure modes
Product development goes wrong in two characteristic ways. Either the company has too little structure — every project is a hero's journey, schedules slip, learnings don't transfer — or it has too much structure, projects spend more time on gate reviews than on actual development, and bold ideas die in committee.The right answer is in the middle, and it's specific to the company's risk profile, regulatory environment, and culture. Below is the framing we use.
When stage-gate works
Stage-gate (Cooper-style) is right when:- Projects involve significant capital outlay before market feedback (industrial, capital equipment, regulated medical)
- Regulatory approval requires documented evidence of design controls (medical devices, automotive, aerospace)
- The cost of a wrong specification rises sharply through development (any product where late-stage changes mean tooling rework)
- Multiple internal stakeholders need synchronised commitment (engineering, supply chain, sales, finance)
Where it falls down: the gate reviews become theatre. The real decision is made before the meeting; the meeting is where it's documented. When this happens, you've added overhead without adding decision quality.
When lean / agile / iterative works
Lean works when:- Customer feedback can come back quickly (consumer software, app-based products, B2B SaaS)
- Cost of incremental experiments is low
- The product is ambiguous enough that early specs are guesses
- Cross-functional teams can self-organise without committee approval
Where it falls down: the team builds incrementally toward the wrong thing. Without a stage-gate-equivalent moment of "are we still solving the right problem", lean iterations can perfect a feature nobody actually wants.
The hybrid that works
For most industrial product development, neither pure approach fits. What we ship:- Stage-gate at the top level — concept, feasibility, development, validation, launch — with hard gate criteria and documented sign-off
- Lean / iterative within each stage — design, build, test, learn cycles inside the stage box, no per-cycle approval needed
- Stage-gate criteria written as decisions, not deliverables — "we have decided the target market is X" not "we have a 47-page market analysis"
- Pre-mortems before each stage — what would make this stage fail, how do we prevent it
- Post-mortems after each stage — what surprised us, what would we change next time
The voice of the customer (VoC) trap
Customer interviews early in development are valuable. They are also dangerous. The patterns:- Customers describe their problems accurately. They describe their solutions inaccurately. Listen for the problem, design the solution.
- Asking "would you buy this" is misleading. Asking "what would you stop doing if you had this" is more honest.
- The vocal customer who asks for a feature is often not the median customer. Quantify the asks before treating them as direction.
VoC done as a stage gate output, with structured analysis, is more useful than "we talked to customers and they were excited".
The decision-rights conversation
A common cause of slow product development: nobody can say "yes" without three other people. Map who can:- Approve a budget reallocation under $X
- Change the specification on a feature
- Sign off a design freeze
- Decide to go to market vs delay
- Stop the project
Without explicit decision rights, every meeting is a coordination meeting. With them, the decision-makers have authority and the rest of the team has clarity.
The metrics that matter mid-project
Not just schedule and budget. Also:- Risk burn-down — list of identified risks, retired or active, status changing over time
- Specification stability — how often does the spec change? High rate = we don't yet know what we're building
- Validated learning — what did we learn this sprint that changed our beliefs?
- Critical path clarity — what specifically is the bottleneck this week?
These four catch projects in trouble earlier than schedule slip does.
One thing we'd warn about
Borrowing a process from the wrong industry. Stage-gate from medical devices applied to a B2C SaaS product strangles it. Lean / startup playbooks applied to a regulated automotive subsystem produce a non-compliant product. The process must match the risk profile.One pattern that always pays off
Making the project's risk register a live document, reviewed weekly. Not a one-time deliverable. The project that retires risks faster than it accumulates them is the project on track.What's your gating process? And — for the lean folks — how do you handle the first big "buy a tool / commit to a vendor" decision in a lean framework?
