TL;DR: Treat the lifecycle as a series of investment decisions. A useful demonstration earns an experiment; evidence of customer value, feasible delivery and acceptable risk earns a scoped release. Assign an owner to what happens after launch before promising the launch date.
The missing decision between demo and roadmap
Original teaching case: a maintenance-software team demonstrates an assistant that reads equipment manuals. A service manager likes the answers. Sales proposes a paid pilot across every customer site.
Three questions remain unanswered. Can technicians use it with the documents they are allowed to see? Does it shorten an actual repair? Who responds when a manual changes and the assistant gives an obsolete instruction?
A good answer on a clean manual is useful evidence about that example. The PM decides which commitment it supports. In this case, fund supervised testing with technicians on a limited equipment family, with no autonomous control of machinery.
Follow the evidence through the product
The sequence below is an original planning aid. Activities can overlap or repeat. A privacy constraint discovered late can send the team back to scope; a weak demand signal can end the project even when the model works.
Follow the flow, one stage at a time.
Illustrated sequence; animation speed does not represent processing time.Read diagram description
Observe the job, compare the existing baseline, test user value, qualify data and dependencies, define release evidence, evaluate the whole task, assign operating ownership, release a bounded cohort, and decide whether to expand, revise or retire. New evidence revisits the value hypothesis.
| Decision | Evidence to bring | Artifact someone can act on |
|---|---|---|
| Is the problem worth solving? | Observed work, frequency, current workaround and affected users | Problem statement with a baseline |
| Will the proposed help matter? | Users completing a real task, including people who decline it | Value hypothesis and next experiment |
| Can this scope be delivered? | Data permissions, representative inputs, integrations and staffing | Feasibility record with unresolved dependencies |
| Does the complete system meet the bar? | Held-out outcomes, critical failures, cost and latency | Versioned evaluation and release recommendation |
| Can we operate it for this cohort? | Support capacity, monitoring, tested rollback and escalation | Named service owner and bounded rollout |
| Should we expand, revise or retire it? | Customer outcomes, maintenance burden and emerging failures | Next investment decision and migration plan |
Each artifact should name the decision it enables. A twenty-page PRD with no disputed assumption is less useful than a one-page record that tells the team what to test next.
Product work and model work have different clocks
The product might use a purchased model throughout its life. Training is optional. Data rights, evaluation and integration still require work.
A model team may finish an adaptation experiment before the product has permission to use customer documents. Conversely, a manual pilot can show that technicians need a better document filter while the team is still choosing a model. Track both dependencies; avoid calling either one “the project is 80% done.”
The model lifecycle explains versioning, training or adaptation and retirement of a model. This page concerns the larger investment: whether a customer should receive the resulting service at all.
A first release needs an operating agreement
For the maintenance assistant, record the initial equipment family, permitted documents, supported languages and excluded advice. Decide where the product hands work to a qualified person. Assign owners for document freshness, quality sampling, security incidents and customer support.
A founder may hold several of these roles. A large company may split them across teams. The document needs names and authority, not a particular org chart.
Choose a reversible release: an assistant that cites approved manuals and helps find the relevant procedure. Measure time to find the correct procedure against the existing search workflow. Track incorrect or missing instructions separately. Faster access to a wrong procedure is a failure, even if engagement rises.
Returning to an earlier decision is useful work
Suppose technicians find the right procedure quickly but still wait hours for a spare part. The assistant may have solved a small part of the delay. Revisit the value estimate before expanding it to more sites.
Suppose demand is strong but half the manuals are scans the retrieval system misreads. Narrow the supported document set, fund document preparation or stop the pilot. The choice belongs in the roadmap with the data owner and cost attached.
The system does not improve merely because it is used. Someone must inspect failures, choose a correction, verify it on fresh evidence and release it. The same discipline applies when retiring a feature: identify dependent workflows, offer a replacement and stop collecting data no longer needed for the service.
Use it in an interview
For “walk me through launching an AI product,” choose one user task and carry it through the decisions above. State what would stop the investment. Explain who owns quality after the launch team moves on, then practise prioritizing uncertain AI features.
Further reading: Marily Nika's Building AI-Powered Products, chapters 2–5, prompted this lifecycle review. The checkpoints, maintenance example and diagram here are our own teaching material. Hidden Technical Debt in Machine Learning Systems explains why model behavior depends on the surrounding system and its changing data.