The most expensive first release is often the one that tries to answer every stakeholder’s future question. A useful first version proves a specific user outcome, handles the riskiest operational path, and gives the team evidence for what to build next.
Choose an outcome and user
Describe one target user completing one important task and the result they need. Interview and observe users to validate the problem. Define how they solve it now and what failure costs them. Keep stakeholder requests connected to that outcome or mark them for later evidence. GOV.UK purchasing strategy.
A narrow release can still solve a whole, coherent user problem. It should not force users to finish the real task in an unrelated spreadsheet or call unless that is an intentional service design.
Map the minimum end-to-end journey
List the essential steps from entry to successful completion, including authentication, data entry, confirmation, correction, support, and recovery. Include roles and dependencies. Remove features that do not support this journey, but keep necessary policy, accessibility, and operational controls.
Test assumptions with sketches or an alpha build. Research should include people with differing abilities, devices, connectivity, and familiarity where those factors affect use.
Set release and quality boundaries
Define what is included, explicitly excluded, and deferred. Set acceptance criteria for the core task, privacy, security, accessibility, performance, and support readiness. WCAG 2.2 and OWASP ASVS can help turn broad requirements into checks appropriate to the service. See also GOV.UK user research in alpha.
Identify high-risk assumptions and decide what evidence resolves each. Set thresholds for usability, task completion, defects, and operational effort before the release is judged.
Launch as a learning loop
Prepare support, monitoring, analytics with privacy safeguards, rollback, and a named product owner. Invite a limited, representative group when appropriate and watch the real task, not only page views. Record issues and prioritize changes by user impact and evidence.
A first release is successful when it safely delivers a useful outcome and informs the next decision. It does not need to contain every idea on the roadmap.
What would you do?
What would you deliberately leave out of a first release—and what evidence would make you add it later? Share your experience in the comments.
Have a related project in mind? Talk with Acorn.
Share your perspective