Ideas stall when the first release tries to do everything, or when nobody has written down who it is for and how success will be judged. This sequence narrows the idea to one user, one problem and one outcome, then cuts the scope until it can ship. Each phase ends with a written decision, so engineering starts with something they can estimate.

Days 1–3 — Name the user and the problem

Goal: Agree exactly who the first release is for.

  1. Write the one user type the first release serves, and the ones it does not.
  2. Describe the problem in their words, from real conversations where possible.
  3. List how they solve it today and what that costs them.
  4. Agree the single outcome that would make the release worth shipping.

You finish with: A one-paragraph problem statement and a success measure.

Days 4–6 — Map the smallest path

Goal: Find the fewest steps that deliver the outcome.

  1. Sketch the user’s path from start to outcome in as few steps as possible.
  2. Mark each step as essential, helpful or later.
  3. Replace anything that can be manual, borrowed or configured with that simpler option.
  4. Check the path with two or three target users before committing.

You finish with: A step-by-step path with only the essential steps left in scope.

Days 7–10 — Write the scope and constraints

Goal: Turn the path into something engineering can estimate.

  1. Write acceptance criteria for each essential step.
  2. List constraints: data, integrations, security, budget and deadline.
  3. Write down what is explicitly out of scope for this release.
  4. Name the person who approves scope changes.

You finish with: A short scope document with acceptance criteria and exclusions.

Days 11–14 — Estimate, cut and commit

Goal: Agree a release that fits the time and budget.

  1. Get an estimate from the team or vendor against the written scope.
  2. If it does not fit, cut scope rather than stretch the date.
  3. Set the release date, the review cadence and how progress is shown.
  4. Plan how the success measure will be collected after launch.

You finish with: A committed first release with a date, an owner and a measure.

Common pitfalls

  • Scoping for every possible user at once.
  • Treating a feature list as a problem statement.
  • No written out-of-scope list, so scope grows quietly.
  • Stretching the date instead of cutting scope.

See it as a workflow

Product

From product idea to first release

Turn an internal idea or customer request into a scoped first release with decision gates, instead of an open-ended build.

See the workflow

More guides like this

Related answers

Read as Markdown Fractional Product Leadership