The product management lifecycle is the repeating sequence a product team runs from first idea to retirement: discover, define, check feasibility, design, build, test, launch, operate, retire. Published models compress that into anywhere from four stages to ten. The stages are not the difficult part. The handoffs are.
Our position is that a stage model is really a set of decisions with an expiry date, and nobody writes the expiry date down. Every stage silently assumes the previous stage's conclusion still holds. For deterministic software that assumption is usually safe. For a product that calls a model it is not, because the thing you validated at feasibility has a retirement notice, a changing behaviour profile, and a cost curve that only appears at volume. So the useful version of the product management lifecycle is not a longer list of stages. It is a short list of decisions that stay open, and get re-answered, at every stage.
A developer posting as XCSme described the failure precisely on Hacker News in March 2026. After moving one model version to another, "suddenly all my workflows were broken", and on inspection the new model was better at following instructions, exposing prompts that had been contradictory all along (Hacker News, 12 March 2026). Nothing in the product had changed. A decision made once, at feasibility, had quietly expired.
The short answer: Run the product management lifecycle as nine stages if you like, but carry five decisions — scope, owner, evidence floor, unit cost, reversal — open through all of them. Closing any of the five at a single stage is what turns a lifecycle into a waterfall.
Last updated: July 30, 2026.
One disclosure before the method. We have not run a controlled, instrumented product build against this exact framework and timed it, so nothing here is presented as a measured result from our own product organisation. The lifecycle stages, the failure patterns and the regulatory obligations are drawn from published research, official regulatory text, vendor documentation and practitioner reporting, all linked inline. The framing — the Standing Five — is ours.
The Standing Five run horizontally across the product management lifecycle: five decisions that are re-opened at every stage rather than settled once.
What the product management lifecycle actually is
The product management lifecycle is the internal process a team uses to take a product from idea to retirement — discovery, definition, feasibility, design, build, test, launch, operation and sunset. It is a description of how work moves through an organisation. It is not a description of how a product sells over time, which is a separate and much older model, and confusing the two is the single most common error in this vocabulary.
The distinction matters because the two models point at opposite audiences. The marketing product life cycle — introduction, growth, maturity, decline — is a demand curve. It tells a commercial team when to raise price, when to defend share and when to harvest. It says nothing about who writes the spec. The product management lifecycle is an operating process. It tells a product team what has to be true before work moves to the next stage. A product can sit in the "maturity" phase of the market curve while its team runs the management lifecycle four times a quarter on individual features.
A third term gets tangled in with both. Product development is the engineering and design work of actually making the thing. It is one part of the wider process, roughly stages four to six below. A product manager owns the lifecycle; the product development function owns a segment of it. Teams that use the two phrases interchangeably tend to end up with a process that starts at "build" and has no gate in front of it, which is how features arrive fully specified with nobody able to say what evidence justified them.
The second thing worth stating plainly: no canonical stage count exists. The models in circulation disagree, and they disagree for defensible reasons, because they were written for different organisations at different sizes.
| Model shape | Typical stages | Written for |
|---|---|---|
| Four-stage | conceive, plan, develop, launch-and-learn | Small teams, single product |
| Six-phase | discovery, validation, build, launch, iteration, growth | Product-led SaaS |
| Seven-step | idea management, research, planning, prototyping, validation, delivery, launch | Feature factories, roadmap tools |
| Ten-stage | idea generation through post-launch analytics | SEO reference pages and PM training |
| Nine-stage (used here) | discovery, definition, feasibility, design, build, test, launch, operate, retire | Teams shipping into a governed enterprise |
We use nine because two stages that most models fold into their neighbours deserve to be visible when a model is involved: feasibility, which in AI products is a measurement rather than an opinion, and retire, which in AI products can be forced on you by a supplier's calendar rather than chosen by you.
What the product management lifecycle is not: it is not a schedule, it is not a Gantt chart, and it is not a promise that stages happen once each in order. Treat the stages as decision gates. A gate can be crossed many times. A gate can be re-crossed backwards. What a gate cannot be is skipped without someone later paying for the information that was never gathered.
The nine stages, and the decision each one is really making
Product management lifecycle stages exist to produce one decision and one artifact each. If a stage produces neither, it is a meeting, not a stage. The giveaway is that no stakeholder outside the team can say what changed as a result of it. The table below is the compressed version; the prose that follows explains the two stages teams most often collapse.
| # | Stage | The decision it makes | The artifact that proves it |
|---|---|---|---|
| 1 | Discovery | Is this problem worth anyone's time? | Evidence of the problem from outside the building |
| 2 | Definition | What exactly are we building, and for whom? | A written scope with explicit exclusions |
| 3 | Feasibility | Can this be built and run, at this quality, at this cost? | A measured result, not an estimate |
| 4 | Design and prototype | What does the smallest testable version look like? | Something a user can react to |
| 5 | Build | Does the thing exist and pass its own tests? | Working software behind a flag |
| 6 | Test and evaluate | Is it good enough to expose to real people? | A pass rate against a frozen test set |
| 7 | Launch | Who gets it, in what order, and what stops the rollout? | A rollout plan with a named abort condition |
| 8 | Operate and iterate | Is it still working, and is it still worth its cost? | A running metric and an owner reading it |
| 9 | Retire | Is the cost of keeping it now higher than the value? | A migration path for the people using it |
Two of these get collapsed almost universally, and both collapses are expensive.
Feasibility gets collapsed into build. In deterministic software this is often harmless: an engineer knows within a day whether the API supports the operation. In a product that calls a model, feasibility is an empirical question with a numeric answer, and the answer is not knowable by reading documentation. It requires assembling real inputs, running them, and counting how often the output is acceptable. Teams that skip this discover during test that the ceiling is 71% and the business case assumed 95%, at which point the sunk cost argument starts and the honest kill decision gets harder every week.
Retire gets collapsed into nothing at all. Most lifecycle models mention post-launch iteration and stop. Retirement is treated as an unpleasant event rather than a stage with its own artifacts. For AI features this is now indefensible, because the retirement decision is partly made by your supplier. OpenAI's published deprecation policy commits to "at least 6 months" of notice for generally available models, at least three months for specialised variants such as chat or Codex snapshots, and warns that preview models "may be retired with much shorter notice, such as 2 weeks" (OpenAI deprecations, fetched 30 July 2026). On 11 June 2026 the same page records a notification to developers on older GPT-5 and o3 snapshots that those models would be removed from the API on 11 December 2026. Six months is a generous notice period by industry standards. It is also shorter than many enterprise roadmap cycles.
The practical reading: if your feature depends on a specific model snapshot, that dependency has a shelf life measured in months, and a lifecycle that has no retire stage has nowhere to put that fact.
Why the linear picture survives when nobody works that way
Almost nobody runs the product management lifecycle as a strict waterfall, yet almost every published diagram of it is a straight line with arrows. The reason is not ignorance. It is that a line is legible to people outside the product team, and the alternative picture is harder to draw.
The alternative has a documented origin. Jeff Patton traces the "dual-track development" model back to a 2007 paper by Desiree Sy, Adapting Usability Investigations for Agile User-centered Design, describing a pattern practitioners had already converged on: discovery and delivery running as two parallel tracks rather than two sequential phases. Patton's summary is blunt about what the two tracks measure — delivery optimises for predictable throughput, while "velocity is important during discovery too – but this is learning velocity" (Jeff Patton & Associates). He also says he dislikes the term, precisely because the picture makes it look like two teams doing two jobs when it should be one team doing two kinds of thinking.
That tension is worth sitting with, because both models are true about different things:
| The linear stage model | The dual-track model | |
|---|---|---|
| Good at | Communicating status outside the team, budgeting, audit trails | Describing how the work actually happens |
| Bad at | Describing how the work actually happens | Communicating status outside the team |
| Fails when | Treated as a calendar | Treated as licence to skip written decisions |
| Right unit | The decision gate | The learning loop |
The reconciliation we use is simple: stages are gates, not phases. A gate is a question with a recorded answer and a date. Discovery and delivery loop continuously; the gate is the moment someone writes down what the loop concluded and who signed it. This keeps the legibility the linear model buys you without the pretence that the work is sequential.
It also survives contact with regulators, which the pure loop model does not. An auditor asking "when did you decide this system could write to customer records, and on what evidence" is asking a gate question. "We iterate continuously" is not an answer to it.
What changes in the lifecycle when the product contains a model
Three properties of AI features break assumptions that the classic product management lifecycle quietly relies on. None of them are exotic; all three are documented in the standards and research literature, and all three have the same structural effect. They turn a one-time stage decision into a standing obligation.
One: a passing test does not stay passing. NIST's AI Risk Management Framework states the problem directly: "Measuring risk at an earlier stage in the AI lifecycle may yield different results than measuring risk at a later stage; some risks may be latent at a given point in time and may increase as AI systems adapt and evolve" (NIST AI 100-1, AI RMF 1.0, released 26 January 2023). The same document lists, among the ways AI risk differs from traditional software risk, that AI systems "may require more frequent maintenance and triggers for conducting corrective maintenance due to data, model, or concept drift." A test suite for deterministic code is a regression net. A test suite for a model-backed feature is a measurement instrument that must be re-read, and the reading changes when the model, the prompt, the retrieval corpus or the user population changes — which is to say, constantly.
Two: speed goes up and stability goes down at the same time. Google's DORA programme surveyed nearly 5,000 technology professionals between 13 June and 21 July 2025. Adoption is effectively universal: 90% of respondents use AI in their work and more than 80% believe it has increased their productivity, while 30% report little or no trust in AI-generated code. The finding that matters for lifecycle design is the outcome pair: AI adoption "now improves software delivery throughput, a key shift from last year. However, it still increases delivery instability" (DORA, State of AI-assisted Software Development 2025). DORA's framing is that AI is an amplifier — it "magnifies an organization's existing strengths and weaknesses." A lifecycle with weak gates gets weaker faster.
Three: the industry's own measurement is thinner than its capability. Stanford HAI's 2026 AI Index records 362 documented AI incidents in 2025, up from 233 in 2024, and notes that while nearly all frontier developers publish results on capability benchmarks such as MMLU and SWE-bench, "reporting on responsible AI benchmarks remains sparse." The Foundation Model Transparency Index, having risen from 37 to 58 between 2023 and 2024, fell back to an average of 40 in 2025 (Stanford HAI, 2026 AI Index). Practically, this means a product team cannot outsource its evidence floor to a model card. Whatever "good enough" means for your use case, you are going to have to measure it yourself.
Put the three together and the shape of the problem is clear. The classic lifecycle answers each question once and moves on. An AI feature needs several of those answers re-taken on a schedule, by someone with a name, for as long as the feature is live.
A practitioner posting as jaynamburi described the working discipline on Hacker News in February 2026: versioned system prompts, strict output schemas, golden test cases, regression evals on every change, and, most consequentially, "keep model upgrades behind feature flags and roll out gradually" (Hacker News, 4 February 2026). That is not an engineering nicety. It is a lifecycle decision about who is allowed to change the product without going back through a gate.
The Standing Five: decisions a lifecycle carries, not closes
The Standing Five is this article's framing, not a certification or a standard. It is five decisions that a product management lifecycle should carry open through every stage, each with a defined re-check trigger. The test of whether you are carrying one properly is whether you could answer it, with evidence, on any random Tuesday — not whether it was answered once in a definition document nobody has opened since.
| Decision | The question | Cheapest stage to decide | Stage teams usually decide it | Re-check trigger |
|---|---|---|---|---|
| Scope | What may this read, write, send or spend? | Definition (2) | Launch (7), under security review | Any new connector, data source or action |
| Owner | Who is named, on call, and holds the budget line? | Definition (2) | After the first incident | Reorg, role change, team transfer |
| Evidence floor | What counts as good enough, measured how? | Feasibility (3) | Test (6), after the build | Model change, prompt change, corpus change |
| Unit cost | What does one completed unit of work cost at full volume? | Feasibility (3) | Operate (8), when the invoice lands | Traffic step-change, provider price change |
| Reversal | How is a wrong output undone, and who may pull the feature? | Design (4) | Never, in most teams | New write action, new external recipient |
The gap between columns four and five is the whole argument. Every one of the five is dramatically cheaper to answer early and dramatically more expensive to answer under pressure. Look at each in turn.
Scope: the list, not the sentence
Scope is not "helps agents draft replies". Scope is an enumerated list: which systems it reads, which records it may write, which external parties it may contact, and which of those actions require a human to press a button first. Written as a list it is checkable; written as a sentence of intent it is a Rorschach test that engineering, security and legal each read differently.
The reason scope belongs at definition rather than at the security review is arithmetic. At definition, changing scope costs a paragraph. At security review it costs a re-architecture, and it arrives at the moment the launch date is already public. Our earlier analysis of why AI pilots stall between pilot and production found that the identity-and-access question is the one most likely to convert a stalled project into a rejected one, because it is the first thing an assessor checks and the hardest to retrofit.
A scope statement that has been written properly reads boringly. That is the sign it is right.
Owner: a person, not a team
The passing answer is a named individual with three things: the alert routing, the budget line, and the authority to switch the feature off without convening anyone. "The platform team" is not an owner. "Product" is not an owner. The failure mode is not malice or neglect; it is that features built during a push are owned by whoever was enthusiastic, that person moves, and the ownership is never re-assigned because it was never assigned in writing.
For features that act rather than merely answer, the ownership question extends to the identity the feature runs on. A feature calling a model with a developer's personal key is a feature whose permissions nobody has enumerated and whose access does not disappear when that developer leaves. We have written separately on treating non-human identities as first-class, with an owner, a scope and an expiry; the lifecycle point is narrower. Assign it at definition, re-check it at every reorg, and record the re-check.
Evidence floor: the frozen set and the number
The evidence floor is the pair of things that make "it works" falsifiable: a frozen set of representative inputs with known-correct outputs, and a pass rate you have committed to in advance. Thirty to fifty cases is enough to start; the discipline matters more than the volume. Without it, quality discussions become arguments about anecdotes, and any model change produces an unfalsifiable claim that the new one "feels better".
The floor has to be set at feasibility, before the build, for one reason: after the build, the number is negotiable. A team that has spent six weeks on a feature and discovers a 78% pass rate will find reasons why 78% was always acceptable. A team that wrote "we ship at 90% on this set" before starting has a decision instead of a debate. We covered the mechanics of writing the test set before the prompt in our guide to creating an AI agent spec-first.
The floor also needs a re-read schedule, because of the drift NIST describes. A quarterly re-run, plus a mandatory re-run on any model, prompt or retrieval change, is a defensible default for a low-risk feature. Anything touching money, employment, health or a regulated decision wants tighter.
Unit cost: per completed unit, not per token
Token prices are an input, not a cost. The number a product management lifecycle needs is the fully loaded cost of one completed unit of work: one resolved ticket, one drafted reply that shipped, one document processed and accepted. That figure includes retries, failed attempts, the human review minutes, and the share of the exception queue that this feature generates.
That number behaves differently from a licence fee. It scales with usage, it moves when a provider changes prices or you change models, and it can be dominated by the cases that fail rather than the ones that succeed. A feature at 85% automation where the 15% takes eight minutes of human handling each can easily cost more per unit than the manual process it replaced. Feasibility is where you find this out cheaply, by costing a sample by hand. Operate is where you find it out expensively, from an invoice. Routing work to a cheaper model per task is one lever once the number is visible; we have written on how model routing changes the cost picture.
Reversal: what it takes to undo
Reversal is the decision almost nobody records, and it is the one that determines how much autonomy a feature can safely be given. Two questions: what does it take to undo a wrong output, and who is allowed to pull the feature entirely?
A feature that drafts text for a human to send is trivially reversible, because the human does not send it. A feature that posts to a ledger, emails a customer, or changes an entitlement is not; undoing it costs a correction, an apology, or a regulatory notification. The design-stage decision is whether the irreversible actions sit behind an approval step. Deciding this at design costs a checkbox; deciding it after the first bad send costs an incident review and, frequently, the feature. The general case — when an approval gate is genuine control rather than theatre — we treated separately in our analysis of human-in-the-loop automation.
Running the Standing Five through every stage
The Standing Five are useless as a poster. They are useful as a recurring agenda item: five rows, added to whatever gate review you already run, answered with evidence or explicitly marked unknown. What changes stage to stage is not the questions but the quality of answer you are entitled to expect.
| Stage | Scope | Owner | Evidence floor | Unit cost | Reversal |
|---|---|---|---|---|---|
| 1 Discovery | Rough class of data involved | Sponsor named | What "better" would even mean | Order of magnitude | Is the action reversible in principle? |
| 2 Definition | Enumerated list, with exclusions | Named individual + deputy | Test-set design agreed | Costed sample by hand | Irreversible actions listed |
| 3 Feasibility | Confirmed against real systems | Unchanged, or re-assigned | Measured baseline number | Per-unit figure from a real run | Reversal cost per action type |
| 4 Design | Actions mapped to permissions | Unchanged | Floor committed in writing | Model choice priced | Approval gates placed |
| 5 Build | Permissions implemented, not intended | Unchanged | Test set frozen in the repo | Instrumentation in place | Kill switch exists and is tested |
| 6 Test | Scope verified by someone else | On-call rota exists | Pass rate measured against the floor | Cost measured under load | Rollback rehearsed |
| 7 Launch | Security review passed on the list | Owner announced to the org | Floor met, exceptions logged | Budget cap set | Abort condition written |
| 8 Operate | Drift in scope detected and reviewed | Owner still in the role | Re-run on schedule and on change | Actual vs. forecast tracked | Reversal used at least once, deliberately |
| 9 Retire | Access revoked, keys rotated | Owner runs the migration | Final measurement archived | Run-off cost known | Users migrated, not stranded |
Read the bottom-right cell again. "Reversal used at least once, deliberately" is not a joke. A kill switch that has never been pulled is a kill switch of unknown status, in the same way an untested backup is not a backup. Pull it once in a low-traffic window and find out what actually happens.
The other cell worth defending is row 5, Scope: "permissions implemented, not intended". The gap between the scope document and the credentials actually issued is where most access surprises live. Someone has to diff the two, and build is the cheapest stage at which to do it.
A worked example: a reply-drafting feature, stage by stage
This example is illustrative and constructed to show the mechanics. It is not a LeapForce customer deployment, and the figures are worked arithmetic rather than measured results from a live system. Where a real number exists, it is cited to its source.
The feature. A support tool that drafts a first reply to inbound customer email, using the ticket history and a knowledge base. A human agent reviews and sends. Volume: 4,000 tickets a month.
Stage 1, discovery. The problem evidence comes from outside the building: agent time-in-ticket, the share of tickets that are variations on eleven known questions, and a shadowing session. This is where market research and user feedback earn their keep, and where most of the ideas should die — the artifact is evidence, not enthusiasm. The Standing Five at this stage are cheap sketches. Scope: customer email content and a knowledge base, no billing data. Owner: the support operations lead. Evidence floor: "better" means agents accept the draft without substantive edit. Unit cost: unknown, order of cents. Reversal: fully reversible, because a human sends.
Stage 2, definition. Scope becomes a list with exclusions written in: reads ticket thread and knowledge base; writes a draft to the agent's compose window; does not read the billing system; does not send; does not contact the customer directly under any condition. That last line is the one that matters, because it is the line a future feature request will try to cross, and having it written makes the crossing a decision rather than a drift.
Stage 3, feasibility. Forty real tickets are assembled with known-good replies. The floor is set before the run: 80% of drafts accepted with only cosmetic edits. The first run scores 62%. This is the number that decides whether the project continues, and it arrives in week two rather than week ten. Unit cost is worked by hand from the sample: model calls plus retries, plus the review minutes the drafts still require. If the review minutes do not fall below the current time-in-ticket, the business case is gone regardless of the pass rate.
Stage 4, design. The reversal decision is trivial here and should be recorded anyway, because recording it establishes what would have to change if someone later proposes auto-send. Auto-send would move this feature from reversible to irreversible, which is a re-run of the entire gate sequence, not a configuration change.
Stage 5, build. The test set is committed to the repository next to the code, not kept in a spreadsheet on someone's drive. Prompts are versioned. Cost instrumentation is added before launch rather than after the first invoice.
Stage 6, test and evaluate. Pass rate is measured against the frozen set, by someone who did not write the prompts. The result is compared to the committed floor. If it is below, the choices are: improve, lower the floor with a written justification, or stop. All three are legitimate. Quietly proceeding is not.
Stage 7, launch. The product launch here is a rollout to one team rather than a go-to-market moment, which is the right default for anything model-backed: the first cohort exists to surface the inputs your frozen set did not contain. Rollout to one team, with an abort condition written down in advance — for example, "abort if agent acceptance falls below 60% in any week, or if any draft containing customer PII is logged outside the approved store." An abort condition invented during an incident is an argument, not a control.
Stage 8, operate. The re-check schedule now does the work. The provider ships a new model version; the feature flag holds it back until the frozen set has been re-run against it. This is exactly the discipline jaynamburi described, and exactly the failure XCSme hit without it.
Stage 9, retire. Either the feature is superseded, or the underlying model snapshot is retired by the provider. The published minimum notice is six months for generally available models and as little as two weeks for preview models (OpenAI deprecations). The migration is a stage with an owner and a date, not an emergency.
Note what the example does not contain: a stage where the team decides whether it is allowed to do this. That decision was made at stage 2, revisited at every subsequent gate, and therefore never had to be made in a panic.
Post-launch is now a stage with legal weight
For a growing set of products, the operate stage is no longer a matter of professional discipline alone. Under the EU AI Act, the risk management system for a high-risk AI system is defined as "a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating" (Article 9, AI Act Explorer text of Regulation (EU) 2024/1689). Article 72 then requires providers to "establish and document a post-market monitoring system", proportionate to the technology and its risks, based on a written post-market monitoring plan that forms part of the technical documentation (Article 72).
Read as a lifecycle instruction rather than as legal text, those two articles say something specific: stage 8 must produce documents, on a schedule, for as long as the product is on the market. That is a different operating requirement from "we monitor dashboards". It is also the point at which AI product lifecycle governance stops being an internal preference and becomes something a regulator, an auditor or an enterprise buyer's security questionnaire can ask you to evidence — which in turn makes it a cross-functional obligation rather than a product-team one. Legal, security and the product manager are all named on the same plan.
The timing has moved, so it is worth stating carefully. The European Commission's own framework page sets out that following the AI Omnibus simplification package, adopted 19 November 2025 with political agreement reached 7 May 2026, rules for systems used in certain high-risk areas including employment, education, biometrics and critical infrastructure apply from 2 December 2027, and rules for AI integrated into regulated products such as lifts and toys apply from 2 August 2028 (European Commission, regulatory framework for AI). The Commission also committed to publishing a post-market monitoring plan template, with the AI Act Explorer text giving a date of 2 February 2026 for it.
| Obligation | Lifecycle stage it lands on | Applies from |
|---|---|---|
| Risk management as a continuous lifecycle process (Art. 9) | Every stage, 1–9 | With the high-risk regime |
| Testing against predefined metrics and thresholds (Art. 9) | Feasibility (3), Test (6) | With the high-risk regime |
| Post-market monitoring system and plan (Art. 72) | Operate (8), Retire (9) | With the high-risk regime |
| High-risk uses: employment, education, biometrics, critical infrastructure | Definition (2) decides if you are in scope | 2 December 2027 |
| AI embedded in regulated products | Definition (2) | 2 August 2028 |
Two cautions. First, dates in this regime have moved more than once, and anyone planning a 2027 launch should re-check them close to the decision rather than trusting a table in a blog post — including this one. Our longer treatment is in our guide to EU AI Act compliance for deployers. Second, most product features are not high-risk under the Act, and pretending otherwise produces compliance theatre that crowds out the controls that would actually help. The definition stage is where you determine which regime you are in; getting that determination wrong in either direction is expensive.
The management-system standard route, ISO/IEC 42001, points the same way, at a governance system with planned review cycles rather than a one-time certification event. The operative point for a product team is identical to the one above. Post-launch produces evidence, or it does not count.
Product management lifecycle metrics by stage, and the ones that lie
Every stage of the product management lifecycle has a metric that tells you something and a metric that flatters you. The flattering ones are usually easier to collect, which is why they dominate dashboards.
| Stage | Metric that tells you something | Metric that flatters |
|---|---|---|
| Discovery | Number of ideas killed after evidence | Number of ideas in the backlog |
| Definition | Scope exclusions written down | Length of the spec |
| Feasibility | Measured pass rate on real inputs | Vendor benchmark scores |
| Design | Number of irreversible actions gated | Prototype fidelity |
| Build | Test set committed and green | Story points delivered |
| Test | Pass rate versus the pre-committed floor | Number of test cases |
| Launch | Time from launch to first abort-condition check | Launch-day usage spike |
| Operate | Cost per completed unit of work; drift detected | Total requests served |
| Retire | Users migrated without escalation | Cost saved by switching off |
Three of these deserve a note.
"Number of ideas killed after evidence" is the only discovery metric that distinguishes discovery from documentation. Patton's summary makes the point that if discovery is working, teams "substantially change and kill lots of ideas". A discovery process with a low kill rate is a requirements-gathering process wearing a costume.
"Vendor benchmark scores" deserve their place in the right-hand column on the evidence above: the Stanford AI Index's finding that responsible-AI benchmark reporting stays sparse while capability benchmarks are near-universal means published scores are systematically informative about the dimensions you are least likely to be sued over.
"Total requests served" is the classic AI vanity metric. It rises when the feature is used and it rises when the feature is retried after failing. Cost per completed unit of work falls when the feature improves and rises when it degrades, which is the property you want from a number you are going to look at every month. Getting that number requires per-feature attribution of spend, which most organisations discover they do not have at exactly the moment they need it; our note on proving what an AI system actually did covers the record-keeping side.
Eight ways teams get the lifecycle wrong
These are ordered roughly by how often we see them discussed as problems in practitioner forums and vendor post-mortems, not by severity.
- Treating stages as calendar phases. The gate is a decision with a date, not a month on a plan. Once stages become calendar blocks, work gets pushed through gates to hit dates and the gate stops carrying information.
- Setting the evidence floor after the build. By then the number is negotiable and the team is invested. Commit the floor at feasibility, in writing, with the test set named.
- Writing scope as intent. "Helps with X" is not scope. An enumerated list of systems and actions, with explicit exclusions, is.
- Letting the owner be a team. Alerts routed to a group inbox are alerts routed to nobody. Name a person, name a deputy, re-check at reorg.
- Costing in tokens. Tokens are an input price. Cost per completed unit of work, including retries and human review, is the number the business case rests on.
- No reversal decision. Autonomy gets granted feature by feature without anyone recording what undoing looks like. Then the first irreversible mistake produces a policy written under pressure.
- Model upgrades outside the gate. A provider ships a new version and it goes live because nothing stopped it. Feature-flag model changes and re-run the frozen set first; this is the specific failure the Hacker News accounts above describe.
- No retire stage. A feature that nobody owns and nobody measures does not get switched off; it gets forgotten, keeps its credentials, and keeps spending. Retirement needs an owner and a migration path like any other stage.
An honest ninth belongs here as a counterargument rather than a mistake. There is a real cost to gates. A five-row check at every stage, on every feature, will slow a small team down and can become the exact bureaucracy the dual-track model was invented to escape. The mitigation is proportionality: run the full Standing Five on features that write, send, spend or decide, and run a two-line version — owner and reversal — on features that only read and suggest. A team that applies maximum ceremony to a spell-checker will stop applying any ceremony at all within two quarters.
Where LeapForce fits, and where it does not
LeapForce does not sell product management software, and nothing on our platform will run your discovery interviews or hold your roadmap. The bridge is narrower, and it is the layer the Standing Five keep pointing at. Once a feature is calling models and touching systems, four of the five decisions (scope, owner, unit cost, reversal) stop being documents and become runtime controls that someone has to enforce on every call. That layer is what we build: one governed endpoint in front of every model, identity and scope for non-human callers, budgets in dollars rather than tokens, and a record of what ran and what was refused. Our published rollout model for it is deliberately staged — observe first, enforce second, optimize third — which is the same argument this article makes about gates: measure before you legislate. In keeping with our own honesty convention, per-capability build status is disclosed on the product pages, and some of the capabilities described there are still in development rather than shipping today.
Where this is still uncertain
Several parts of this article rest on evidence that is thinner than we would like, and one part is a judgement call that reasonable practitioners will contest.
The stage count is arbitrary and we know it. Nine stages is a choice that suits teams shipping into a governed enterprise. A two-person startup running the same nine gates on every feature would be strangling itself. If your reversal cost is near zero and your blast radius is one internal user, most of this machinery is overhead.
We have not measured the Standing Five in a controlled setting. No before-and-after study, no instrumented comparison of teams that ran the five against teams that did not. The framework is a synthesis of documented failure patterns; it is not an empirical result, and it should not be cited as one.
The re-check cadence is a defensible default, not a finding. Quarterly re-runs plus mandatory re-runs on change is a rule of thumb. We are not aware of published research establishing an optimal evaluation cadence for LLM-backed product features, and the honest position is that the right interval depends on your drift rate, which you can only learn by measuring.
Regulatory dates are moving. The high-risk timeline has already shifted once through the AI Omnibus. Treat every date in this article as a snapshot taken on 30 July 2026 and verify against the Commission's own page before planning around it.
Two sources a reader might expect are missing. EUR-Lex returned an empty response to us on this run, so the AI Act text quoted here comes from the AI Act Explorer reproduction of Regulation (EU) 2024/1689 rather than the official journal, and McKinsey's State of AI survey timed out on repeated attempts and is therefore not cited. Neither absence changes an argument here, but both are worth knowing about.
We could not source a credible video. The YouTube Data API returned a quota error on this run, so no video is embedded. That is a tooling failure on our side, not a statement that no good talk exists on this subject.
Frequently asked questions
No. The product management lifecycle is an internal operating process, running discovery, definition, feasibility, design, build, test, launch, operate and retire, that describes how a team moves work to a decision. The product life cycle is a market demand curve: introduction, growth, maturity, decline. One tells you what has to be true before you build; the other tells you what to do with pricing and investment as demand changes. A mature product on the market curve can run the management lifecycle many times a quarter on individual features.
As many as you have distinct decisions to record, which for most teams is between five and ten. Published sets of product management lifecycle stages range from four to ten and none is canonical. The stage count matters much less than whether each stage produces a decision and an artifact. A nine-stage model works well for teams shipping into a governed enterprise because it keeps feasibility and retirement visible as stages in their own right; a four-stage model is often correct for a small team on a single product. Judge a model by what it forces you to write down.
A minimum viable product straddles design and build, and its purpose is to buy information, not to ship a small product. In practice it produces the artifact that stage 4 owes you: the smallest thing a real user can react to. The common error is treating the MVP as stage 5 output — a cut-down version of the finished product — rather than as an instrument for answering a specific question you wrote down at definition. If you cannot state the question the MVP will answer, you are building a small product, not a minimum viable one.
Treat the stages as gates rather than phases and the two models stop fighting. Discovery and delivery run continuously and in parallel, as Jeff Patton's dual-track model describes; the gate is simply the moment someone records what the loop concluded, on what evidence, and who accepted it. The loop generates learning; the gate makes the learning auditable. If your gates are calendar milestones instead of recorded decisions, the loop will be crushed by them, which is the failure the dual-track model was written to prevent.
When the prototype can produce a wrong answer that a real user would notice. Before that point, testing measures your prototype's completeness rather than the idea's merit. For AI features there is a sharper trigger: move to validation as soon as you can assemble thirty to fifty real inputs with known-correct outputs, because that frozen set is what turns "it seems good" into a number. Validation before the evidence floor exists tends to produce enthusiastic feedback and no decision.
No. It needs the same lifecycle with several decisions left open. Creating a parallel "AI lifecycle" tends to isolate AI work from the review, release and ownership practices the rest of the product already has, which is the opposite of what you want. Extend the existing stages instead: make feasibility a measurement rather than an opinion, make test a pass rate against a frozen set, make operate produce a scheduled re-run, and add a retirement stage because your model dependency has a published shelf life.
A named individual with the alert routing, the budget line, and the authority to switch it off unilaterally. Teams and functions cannot hold those three things. The ownership question extends to the identity the feature runs on: a feature calling models with a developer's personal credentials has permissions nobody has enumerated and access that survives that developer's departure. Assign the owner at definition, record it, and re-check at every reorg rather than after the first incident.
Quarterly as a floor, plus a mandatory re-run on any change to the model, prompt, retrieval corpus or user population. Gate provider-initiated model upgrades behind a feature flag until that re-run passes. This is a defensible default rather than a researched optimum. NIST's AI RMF notes that AI systems may need more frequent corrective maintenance because of data, model and concept drift; the practical implication is that your own measured drift rate, not a published number, should eventually set the interval.
For high-risk systems, Article 9 requires risk management as "a continuous iterative process planned and run throughout the entire lifecycle", which lands on every stage, and requires testing against predefined metrics and thresholds, which lands on feasibility and test. Article 72 requires a documented post-market monitoring system and plan, which lands on operate and retire. Following the AI Omnibus package, the European Commission's framework page states that rules for high-risk areas such as employment and education apply from 2 December 2027, and for AI embedded in regulated products from 2 August 2028. Determining whether you are in scope is a definition-stage decision.
Budget in cost per completed unit of work, not tokens or seats. One completed unit includes the successful call, the retries, the failed attempts, and the human minutes spent handling what the feature could not. Establish that figure by hand from a sample at feasibility, instrument it before launch, and track actual against forecast every month at operate. A feature automating 85% of a task where the remaining 15% takes eight minutes of human handling can cost more per unit than the process it replaced, and only per-unit accounting makes that visible.
Because a passing test is a measurement taken at one moment, and the conditions move. NIST puts it directly: risk measured at an earlier lifecycle stage may differ from risk measured later, and some risks stay latent until systems adapt. Three things change underneath a shipped feature — the model version, the input distribution as real users find edge cases, and the retrieval corpus as content is added. DORA's 2025 research found AI adoption now improves delivery throughput while still increasing delivery instability, which is the same phenomenon at organisational scale.
Retire when the running cost plus the maintenance attention exceeds the value, or when your dependency forces the decision. The second case is specific to AI features: providers publish deprecation notices, and OpenAI's policy commits to at least six months of notice for generally available models and as little as two weeks for preview models. Retirement is a stage with artifacts, not an event: a named owner, a migration path for the people using it, revoked credentials and rotated keys, and a final archived measurement so the next team can learn what it actually did.
Ready to Govern Your AI?
Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.
Comments