Start with the outcome, not the feature list
Features are implementation ideas. Outcomes describe the change the product must create. “Add authentication, profiles and Stripe” is not yet a project outcome. “A customer can create an account, choose a paid plan and reach the correct member area” is much closer.
An outcome gives every later decision something to optimize against. When a requested feature does not help produce or protect that outcome, it becomes easier to defer.
Map one critical user flow
Choose the most important end-to-end path and write it as observable steps. For a membership product that might be: arrive → understand offer → purchase → verify payment → create or recover access → reach the protected member experience.
Why this matters: AI often produces impressive isolated screens. A product becomes useful when those screens form a working sequence.
Make constraints explicit
Constraints protect the project from accidental reinvention. Record the existing stack, approved brand system, commercial truth, security boundaries, required integrations and things that must not change.
- What technology already exists?
- Which data source is authoritative?
- Which prices or entitlements are approved?
- Which design tokens are locked?
- Which actions require a human decision?
Choose the smallest safe build sequence
Do not ask the AI to implement the entire roadmap in one pass. Choose the smallest increment that can be built and verified without leaving the product in a contradictory state.
Turn the plan into implementation instructions
A useful build instruction should tell the coding environment what to preserve, what to change, where the change belongs and how success will be verified.
CURRENT STATE: [what exists now] DECISION: [the approved change] PRESERVE: [things that must not regress] IMPLEMENT: [specific files / behavior / data path] VERIFY: [observable acceptance criteria] STOP: Do not redesign adjacent systems or invent missing commercial terms.