Product Discovery
Define success without inventing outcome metrics
A credible success measure needs a definition and an evidence source before it needs an ambitious target. Distinguish baselines, hypotheses, and observed results so a product proposal does not manufacture its own business case.
A proposal can promise faster processing without knowing when processing starts, when it ends, or how long it takes today. That is an aspiration, not a measured outcome. Define success so an operational owner can collect evidence and make a decision, even when the initial answer is that the baseline remains unknown.
Choose the business outcome before the dashboard
Start with the user or operational change that matters. Distinguish completing a meaningful task from opening a page. A usage count may help investigate adoption, but it is not automatically evidence that the service solves the problem.
GOV.UK performance guidance derives measurements from service purpose, benefits, and hypotheses.[4] Apply that sequence to the product brief. Explain why a proposed change could affect the outcome, then identify what would show that the explanation is wrong.
Make the measurement reproducible
Specify the unit being counted, eligible cases, start and end events, and treatment of incomplete work. Name the data source and responsible analyst or operational owner. Check whether staff use the same definitions across channels.
The official guidance recommends establishing a baseline across channels and interpreting metrics with context.[4] If the data is unavailable, record that limitation and plan collection. Do not borrow an industry number and present it as the organization’s measured starting point.
Hypothetical example: reviewing artwork requests
A hypothetical print service wants to shorten artwork review. The team defines review time from receipt of a complete submission to the first usable decision. It also records the wait for missing customer material separately. No current duration is assumed.
Before setting an improvement target, the team checks whether request records contain trustworthy events. It may need a short observation period and manual sampling. The example produces a measurement plan, not a claim that a new portal already saves time.
Check the measurement contract
Write a short definition that another person can apply without guessing. Review it before development so necessary evidence is not an afterthought.
- Name the outcome and the decision the measure will support.
- Define eligible cases, exclusions, and start and end events.
- Identify the data source, collection owner, and known gaps.
- Separate observed baseline values from proposed targets and forecasts.
- Pair speed measures with checks on quality or unresolved work.
Interpret change without claiming too much
A shorter average can hide incomplete cases or a different mix of work. Compare like cases where possible and report changes in volume, staffing, and process. Combine operational measures with user accounts to investigate why the numbers moved.
Measurement also has a cost. Choose a small set that supports real decisions rather than collecting everything. Retire a measure when nobody uses it to guide action. When evidence is weak, state the uncertainty. A transparent unknown baseline is more useful than a precise success story that nobody can reproduce.
