1. Write the problem before the feature list
Begin with one audience, one recurring problem and one observable improvement. “Build a learning app” is not yet a product definition. “Help a learner identify weak road-rule topics during ten-minute study sessions” is specific enough to guide research and design.
Write down what the first release will not solve. A boundary is useful product work: it protects the team from spending weeks on secondary settings, social features or administration before the core loop has been tested.
- Name the primary user and the moment in which the product is useful.
- Describe the smallest complete outcome a user should reach.
- List assumptions that require evidence rather than debate.
2. Map the critical journeys
A journey map should show more than ideal screens. Include empty states, interrupted sessions, permission denial, slow networks, expired credentials and the route back from an error. These states often determine whether a product feels dependable.
For an initial release, choose three to five journeys that must work end to end. Give each journey an owner and an acceptance statement written in user language. This becomes a shared reference for design, engineering and testing.
3. Prototype decisions, not decoration
A prototype is valuable when it answers a question. Can a new user understand the first action? Can someone recover after choosing the wrong option? Does the product ask for a permission only when its purpose is clear? Test those decisions before polishing every surface.
Use realistic content in the prototype. Real labels, long names, empty results and error messages expose problems that neat placeholder text conceals.
4. Define architecture and data responsibility together
Choose a technical structure based on product risk: offline needs, sensitive data, device integrations, expected release cadence and the skills of the team that will maintain it. Framework preference should follow those constraints rather than replace them.
Create a simple data inventory before implementation. For each data item, record why it is needed, where it is stored, who receives it and when it is removed. Store disclosures and privacy copy should come from this inventory, not from a generic template.
5. Build in thin, complete slices
A thin slice connects interface, logic, data and monitoring for one real journey. It produces feedback earlier than building every screen first and connecting the system later. Each slice should be demonstrable on a device and testable against the acceptance statement.
Keep release controls visible. Feature flags, test accounts, environment configuration and rollback steps are part of the product, even though users never see them.
6. Test the release as a service
Device testing is only one layer. Check onboarding from a fresh install, upgrades from a previous version, account recovery, notification deep links, accessibility settings, poor connectivity and deletion flows. Verify what support will see when a user reports a problem.
Run a store-listing review separately from application testing. Screenshots, descriptions, privacy answers, support links and reviewer credentials must match the submitted build.
7. Plan the first month before launch day
A launch plan should define who watches crashes, reviews, support mail and key product events. Agree on thresholds that trigger a hotfix, a staged rollout pause or a content correction. Without ownership, useful signals become an inbox that nobody reads.
The first release is the beginning of evidence, not the end of delivery. Compare observed behaviour with the assumptions from stage one and choose the next change from that gap.
| Stage | Evidence to record | Gate question |
|---|---|---|
| Problem | User, recurring problem, intended outcome and exclusions | Is the first release boundary clear? |
| Journeys | Critical paths, failure states and acceptance statements | Can each core journey be tested end to end? |
| Prototype | Observed usability findings and unresolved assumptions | Does evidence support the interaction model? |
| Architecture | Risk spike, data inventory and maintenance owner | Do technical choices reflect product constraints? |
| Build | A device-tested thin slice with monitoring | Is the core outcome complete and observable? |
| Release | Build, policy, listing and support checks | Do the product and public materials agree? |
| Operate | Signal owners, response rules and rollback steps | Can the team act when launch evidence arrives? |
Primary references
Store requirements change. These official sources should be checked again before a release decision.