Start with a decision, not a feature list
A feature list is an inventory, not a product hypothesis. Ask which decision the first phase should make possible. Perhaps a buyer needs to compare two offers, or an operator needs to complete a request without moving data between tools. Write down the person, the triggering situation, the action and a visible completion state. If several unrelated journeys appear, choose one for the first phase and put the others in a clearly named later scope.
Draw the boundaries in ordinary language
Define what enters the system, what it changes and what it produces. “A dashboard” is too vague. “An operator can filter a synthetic shipment queue, inspect an item and mark it reviewed” is testable. State whether authentication, real integrations, payments or migration are included. A prototype and a production system can look alike while carrying very different responsibilities. Make that difference explicit in the proposal and in the interface where it matters.
Agree what completion means
Acceptance criteria describe behavior rather than taste. Include a successful path, invalid input, an empty state and a recoverable error. Decide who reviews the result and which data they use. Avoid promising business outcomes a small software phase cannot control. A useful outcome is a working journey that stakeholders can assess, documented technical assumptions and a list of unresolved risks. Sales growth or user adoption requires evidence beyond the delivery itself.
Price the next step separately
The first phase is not a cheap label for an unbounded product. After review, compare the remaining ideas with what you learned. Some assumptions may disappear; others may require deeper work. Write a new scope and budget for the next phase, including infrastructure and provider charges. This makes the investment legible without hiding future costs. A bounded starting price should describe a bounded deliverable, never imply that a complete multi-role platform fits inside it.