In Roman mythology, Prudentia carried a mirror in one hand and a serpent in the other. The mirror was for seeing situations clearly. The serpent was for reading danger before it arrived. Together they stood for one discipline: always check what you're actually dealing with before you act.
Most product teams have a Prudentia problem. Not because they use the wrong process. Because they reach for the same process every time, regardless of how much risk the project in front of them actually carries.
You know this feeling. The portfolio management team has approved a line extension on an existing instrument platform. The hardware exists, and the science is proven. What you need is a validated application, a protocol tweak, and a label update. Three months later you're in MS2 paperwork for a product that didn't need MS2.
If you've read the previous post, you already know that Cooper's 5th Generation Stage-Gate® framework names this directly: not every project justifies the full process. This post is about what that looks like in practice, on a real project, with a real team.
The full phase-milestone process was built for a different kind of risk
Robert Cooper’s Stage-Gate model became standard practice because most new product development carries genuine, unresolved risk: will customers buy it, will the technology work, will manufacturing scale. Each phase exists to retire one of those risks before the company spends more money. That’s the right tool when the risks haven’t been answered yet.
A line extension on an existing platform doesn’t carry that same risk profile. The R&D is largely done, assuming the platform has already been fully qualified. The instrument already works, often has an installed base with your own customers. What’s left is the integration work: does it fit your applications, does it need a validated protocol for your specific workflow, does the labelling and documentation match your quality system. That’s still work, just a different category of risk compared to “will this technology work at all.”
Not every line extension is this clean, and at the portfolio level you’re rarely looking at just one. A company running several line extensions at once still needs a way to tell which ones are genuinely low-risk and which ones only look that way until someone checks. The classification test below is built for exactly that sorting problem.
Running the full five-phase process against integration work doesn’t make the launch safer. It just adds time without retiring any risk that was actually still open.
What right-sizing the milestone looks like in practice
Cooper’s own framework calls for tailoring the rigour of the process to the risk a project actually carries. Agile is the mechanism that makes that right-sizing possible day to day, and Cooper’s manufacturing research shows what that looks like: companies don’t throw out phase-milestone, they replace the rigid, document-heavy project management inside each phase with sprints, a backlog, and a team that’s empowered to reprioritise week to week instead of waiting for the next scheduled milestone.
For a line extension like this, here’s what I’ve seen it look like in life science tools companies. Instead of a fixed six-month MS2 with a frozen spec, the team works in two-week sprints against a backlog: validate this application, write this protocol, test this labelling claim, confirm the new configuration holds tolerance under the same stress conditions as the original platform. The product owner reprioritises the backlog as data comes in. Nobody waits for a quarterly gate to learn that one claim isn’t supportable. The team makes that call themselves.
The devil’s advocate case for keeping the gate
However, not every line extension is as clean as it sounds. If the new configuration needs its own calibration and validation data that the original platform’s data doesn’t cover, or if a regulatory submission is required before launch, the risk profile just changed, and a fully agile, gate-light process can let a genuine problem slide for months because nobody was forced to stop and check.
The fix isn’t choosing agile or phase-milestone as a blanket rule. It’s sizing the gate to the actual risk. A true cosmetic line extension might need one lightweight review before launch. A configuration that requires new calibration and validation data still needs a go/kill gate with actual teeth, just one focused on the specific risk that’s still open (the validation gap, the regulatory submission) rather than the full four-milestone checklist built for ground-up R&D.
How to tell which case you’re actually in
Before defaulting to the full phase-milestone template, run these five questions. If the first is yes and the remaining four are no, you’re in the low-risk lane. If anything in questions two through five triggers the wrong answer, you need at least a targeted gate focused on that specific risk, though a lightweight business case, even a single page, is still worth the hour it takes regardless.
Prudentia’s mirror doesn’t tell you which process to use. It just makes you answer those five questions before reaching for the same template you used last time.
