Write the one-sentence outcome
Use this format: “A [buyer] can turn [input] into [output] in [time] without [current failure].” For example, “A distributor can turn a disputed delivery into a shareable proof packet in ten minutes without chasing three inboxes.” The sentence gives you a design boundary.
If the output is vague, the product will expand without a clear stopping point. Ask a buyer to show an example of the input and what a good output looks like today.
Map the workflow before choosing features
Draw the trigger, data entry, decision, handoff, and final artifact. Mark each step as manual, automated, or outside the first version. For a pilot, manual work behind the scenes can be acceptable if you tell the buyer what you are doing and protect their data.
Keep only the parts that make the promised result possible. A polished analytics page is unnecessary if the buyer's main job is getting a clean exception list. A complex permissions model may be unavoidable if sensitive data crosses teams; “small” does not mean careless.
Choose a pilot boundary
Limit the first test to a small dataset, one team, and a short duration. Decide how to handle errors, exports, and support before the pilot starts. Record one success measure tied to the job: time to produce the packet, exceptions resolved, or follow-ups completed. Avoid vanity metrics such as logins without an outcome.
Write down what you are deliberately leaving out. A pilot can be successful even when it reveals that buyers need a different integration or that the initial buyer was wrong.
Make the next decision explicit
After a week, ask whether the buyer completed the job, used the output in real work, and wants another cycle. If they will not share a second dataset or discuss a paid continuation, investigate why before adding features. The answer may be onboarding, weak pain, or the wrong buyer.
Start with a 48-hour problem test, then use the MVP week to test the solution. The order saves you from polishing software for a problem nobody owns.
