A product milestone should finish a user’s job

A team can complete an upload screen, a processing service, and a dashboard while the user’s original job remains unfinished. Each component works. The person still needs to ask someone where the work went, what happened to it, or how to correct a mistake.

A stronger milestone describes a result a person can reach. For an incoming-report workflow, that might mean submitting the report, understanding its status, resolving a discrepancy, and reaching an accepted outcome. The first release may support a narrow report type or a small group of users. What matters is that the supported journey reaches a useful finish.

That creates something the team can observe, learn from, and improve.

A request for a dashboard may express a need to understand which items require intervention. A request for an AI assistant may express a need to find the source behind a decision. Start by learning what the person is trying to accomplish and where the current approach breaks down.

The GOV.UK Service Manual recommends researching people’s existing work, difficulties, and goals, including the needs of staff who operate or support the service. That is a useful discipline for commercial product development as well: the operator’s work helps determine whether the customer’s experience succeeds.

We recommend writing the milestone in language a user would recognize. It should identify the outcome and the conditions under which the product will support it.

Decide what completion means before splitting the work into components. A successful upload may mean only that a file arrived. Acceptance may require a separate person to inspect it, resolve an issue, and confirm the result.

Those distinctions matter to scope. A user should be able to tell whether the product has received a request, is still working, needs their input, or has finished the job. The team should use the same meanings in design reviews, implementation, and acceptance.

A clear finish also makes it easier to choose what to defer. The first milestone can be deliberately narrow while still delivering a coherent outcome.

The less visible parts of a journey often determine whether it is usable: a notification that reaches the right person, enough context to review an exception, a way to recover after leaving the page, or a clear explanation of why work cannot proceed.

During planning, walk through the journey with the people who will receive those handoffs. Identify who acts next, what they need to know, and how the original user finds out that the work moved forward.

This can change the implementation order. A small amount of operational visibility may be more valuable to the first release than another input format or a more elaborate dashboard.

A focused release gives the team a way to examine its assumptions with real use. Select a supported audience and task, then follow the work through completion. Observe where people hesitate, create side spreadsheets, ask for clarification, or depend on someone outside the product.

Agree on measures that match the job: completion, time waiting for a handoff, rework, or the effort needed to resolve an exception. Interpret those measures in context and inspect the underlying experiences before drawing conclusions.

The purpose is to learn whether the product’s intended value survives contact with the operating environment. That learning should influence the next investment decision.

Technical leadership should connect what the team learns to priorities and architecture. A repeated manual workaround may reveal a missing product concept. A confusing handoff may need a clearer responsibility boundary. A rare exception may be acceptable to handle manually for now.

These are judgment calls. They become easier to explain when the team has observed a complete journey and can point to the problem the next increment will solve.

A useful milestone leaves the organization with a working outcome and a better basis for deciding what deserves to be built next.