1. Define the change the product must create

Do not start with a list of screens. Describe the user, situation, current behavior and measurable outcome. If the expected change after launch is unclear, you cannot tell whether the app works.

  • Who will use the product?
  • Which expensive or frequent problem are we solving?
  • How does the user cope today?
  • Which behavior change will indicate success?

2. Validate the problem before delivery

Interviews, analysis of the current workflow and a simple prototype can disprove weak assumptions for a fraction of development cost. Test behavior, not declarations such as whether someone likes the idea.

3. Define the smallest complete flow

An MVP is not an arbitrary set of reduced features. It should let one user group complete one valuable process end to end and produce evidence for the next decision.

4. Select technology after learning the constraints

Native, cross-platform and web applications fit different situations. Devices, system features, pace of change, team capability and maintenance cost should drive the decision.

5. Design measurement before the first sprint

Define activation, retention, process value and support cost before delivery. Otherwise, a team can ship version after version without learning whether the product creates a business outcome.

Practical checklist

  • A clearly defined user and problem
  • Evidence that the problem exists outside the pitch deck
  • A prototype tested with representative users
  • One complete MVP flow
  • Activation and value metrics
  • An owner for post-launch product decisions