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? |
Worked example: a study session that survives interruption
Consider a hypothetical driving-theory app whose first release promises a ten-question practice session, explanations and a review of mistakes. The release boundary excludes accounts, leaderboards and cross-device sync. This is a planning example, not a report of a measured AppMe client outcome.
Write the acceptance statement before drawing screens: a learner can start a session, answer questions, leave the app and return to the same unanswered question. A completed session has exactly one result. That statement exposes decisions that a list of screens hides: when to persist an answer, how to identify a session and how to prevent a repeated submit from creating two results.
A useful prototype includes the interruption. Ask the learner to answer three questions, switch to another app and return. Then test a second interruption while the result is being saved. The design needs a visible saving state and a retry action that retains the answers; a spinner with no recovery is an unfinished journey.
For the first implementation, store a session identifier, the question-set version, ordered question identifiers, submitted answers and the current position. Do not infer completion from the last screen viewed. Treat completion as a state transition that can safely be retried. Whether this record belongs on the device or a server follows the product promise: local-only study does not need an account simply to preserve a draft.
At release review, keep the device and build identifier beside each result below. A passing screenshot alone cannot establish that answers survived termination. If question content changes between releases, define whether an existing session keeps its original question set or asks the learner to start a new session, with an explanation.
| Interruption | Expected recovery | Evidence to capture |
|---|---|---|
| Background after question three | Return to question four with previous answers intact | Before-and-after state on a named device and build |
| Terminate and reopen | Restore the persisted session without marking it complete | Session identifier and restored question position |
| Tap submit twice | Show one result for the session | One completion record and one visible result |
| Upgrade with a session in progress | Preserve the question version or explain a deliberate restart | Upgrade path and the resulting session state |
Primary references
Store requirements change. These official sources should be checked again before a release decision.