Product Lifecycle: From Discovery to Iteration

Good to see you again. Last lesson, you turned a delivery commitment into a proposed customer outcome and business outcome. The next question is when a product team investigates those outcomes, commits to a solution, releases it, and learns whether it worked.

This lesson maps that work across discovery, validation, delivery, launch, evaluation, and iteration. Allow about 40 minutes, including the resources and a short addition to your portfolio note. We’ll continue with the proposed AI-assisted support-ticket summaries, so you can see where familiar delivery work fits within a wider product cycle.

A map, not a rigid sequence

The diagram below gives us a useful starting map. Its “Build” stage corresponds to delivery here; “Evaluate” names the evidence-gathering step between launch and deciding what to do next.

The stages represent different questions, not departments or mandatory hand-offs. Discovery asks whether a worthwhile problem exists. Validation asks whether a proposed response is promising enough to invest in. Delivery makes a usable, reliable version. Launch gets it into the intended users’ hands. Evaluation checks what happened. Iteration uses that evidence to continue, change course, or stop.

Read Pendo’s account of the first three phases. It starts with a business objective, then moves into the customer problem and possible solutions. Its examples of Pendo tools are optional illustrations, not requirements for following this cycle.

Treat one claim in the reading cautiously: validation does not guarantee that customers will find value in what is delivered. It reduces uncertainty before a larger investment.

Tim Herbig’s short explanation adds an important qualification: discovery itself is iterative, and a team should not rush from an assigned feature idea straight into designing it.

Discovery and validation: earn the decision to build

Suppose a client asks for AI-generated support-ticket summaries. In a delivery plan, that request may look like a ready-made scope item. In discovery, it is a clue to investigate. Are escalated-ticket handovers actually slow? Which agents experience the difficulty, and how often? What information is hard to find? You might examine existing tickets, observe handovers, and talk with agents and the operations lead. The immediate result is not a feature specification; it is a better-evidenced account of the problem and of what success would mean.

Validation then tests important assumptions about a possible response. Would a clearer handover template help enough without AI? If agents saw draft summaries, could they quickly spot omissions? Would reviewing a draft save time overall? A small, manually prepared example shown to agents might answer some of these questions before a team builds an integrated feature. Other assumptions, such as whether the approach can meet privacy and reliability requirements, may need technical investigation.

The boundary is useful but not absolute. Discovering the problem may reveal that the proposed AI solution is inappropriate. Testing a solution may expose a different underlying problem, sending the team back to discovery. The point is to make the investment decision with better evidence, not to complete a ceremonial stage called “validation.”

Delivery and launch: make it usable, then make it available

Once there is sufficient reason to proceed, delivery turns the selected approach into a working product capability. For the support-ticket example, that means agreeing on a manageable first scope, designing how an agent reviews and edits a draft, implementing it, and testing both ordinary use and likely failures. Your development and QA experience sits here, but product work does not disappear during implementation: new constraints may require a scope or value trade-off.

Launch is related to delivery, but it asks a different question. A feature can be deployed and still not be ready for its intended users. A pilot launch might require selecting eligible agents, explaining when to use the summary, training reviewers, preparing support staff, and deciding how feedback will be collected. A limited release can be more informative than announcing the feature to everyone at once.

Read the later phases in the same Pendo article. Its descriptions of launch and evaluation are particularly useful for seeing why “released” is not the end of the product decision.

Evaluation and iteration: decide what the release taught you

After launch, evaluation compares observed results with the outcomes and risks defined earlier. In our example, the proposed customer measure was the median active time agents spend preparing and reviewing a handover—not merely the time an AI system takes to produce text. The proposed quality check was whether critical information is omitted. Adoption matters too: if few eligible agents use the feature, the team needs to understand why before judging its effect on handover time.

The proposed client business measure was paid overtime cost attributable to handovers per 100 eligible tickets. That measure is only useful if the client can identify those costs reliably. Nor does a change after launch, by itself, prove the feature caused it; ticket complexity, staffing, and other process changes may also have changed. Evaluation combines measures with agent feedback and operational context.

Iteration is the decision made because of that learning. If drafts save review time but sometimes omit escalation history, the team may narrow the feature’s scope and improve how that history is checked. If agents do not trust the drafts, it may need to revisit the workflow. If a simple template performs as well at lower cost, it could pursue that instead—or stop investing in AI summaries. Iteration can mean improving what shipped, testing another approach, returning to discovery, or retiring the idea. It does not automatically mean adding features.

Here is the complete map in one place:

In practice, teams may run discovery alongside delivery or validate a new assumption after launch. The map remains valuable because it prevents a build-and-release schedule from standing in for the entire product process.

Add a lifecycle map to your portfolio note

Spend about eight minutes extending the before-and-after initiative note you made last lesson. Under each of the six stage names, write one question you would need to answer and one piece of evidence or work product that would help answer it. Keep the original initiative recognisable, but label work you did not historically perform as proposed rather than claiming it as past product ownership.

The most useful entry may be the one just after launch: specify what you would examine before saying the initiative succeeded. That entry connects your delivery experience to the customer and business outcomes you defined last lesson.

Conclusion

The product cycle begins with an intended result, investigates the user problem, tests possible responses, delivers and launches a selected approach, then evaluates what changed. Iteration closes the loop: evidence can justify improving the release, revisiting the problem, or stopping. These stages are a decision-making map, not a fixed waterfall schedule.

Next, you’ll look more closely at the decisions an AI Product Manager makes across this cycle—and where those decisions require collaboration with design, engineering, data, commercial, and other partners.