Most MVP plans start with a feature list. That makes the project easy to estimate, but it can hide the question that matters: will the product's hardest workflow actually work?
Start there. Build the part with the most uncertainty before you polish the parts your team already understands.
1. Name the Risk, Not the Product
"Build a marketplace" is a product idea, not a useful scope. A workable scope names the transaction that could break.
For a services marketplace, the risk may be matching a buyer with the right provider. For an internal approval tool, it may be routing a request across three departments without losing context.
Write one sentence:
We need to learn whether [specific user] can complete [specific workflow] under [real constraint].
That sentence gives the first sprint a job. It also makes it easier to cut features that don't help answer the question.
2. Map the Full Workflow Before Cutting It
An MVP can have a narrow interface and still need a complete workflow. A request form isn't useful if nobody receives, reviews, and resolves the request.
Map the path from start to finish:
- Who begins the process
- What information they provide
- Which system stores it
- Who makes the next decision
- What happens when data is missing
- How the user learns the outcome
Tools like FigJam or Miro are enough for this step. Keep the map plain. Boxes and arrows should show where data moves and where a person must act.
3. Separate Product Logic From Manual Work
You don't need to automate every step in version one. You do need to be honest about what is manual.
Suppose a founder wants software that recommends grant opportunities. The MVP might collect a nonprofit's criteria, store opportunities in Airtable, and send a shortlist by email. A team member can review the matches before they go out.
That manual review isn't a failure. It lets you test whether the inputs, matching rules, and final format are useful. Just track the time it takes. A hidden ten-hour process is not a viable product.
4. Use Deterministic Rules Where They Work
AI is useful when the input is messy: summarizing a brief, classifying open text, or drafting a plain-language explanation. It is a poor choice for logic that must produce the same answer every time.
Use ordinary code for:
- Prices, fees, and totals
- Eligibility thresholds
- Permissions and account access
- Required fields
- Status changes and notifications
If a model supports the workflow, define its boundaries. Save the source material, log its output, and add human review where a wrong answer carries real cost. The model is one component, not the product plan.
5. Build One Thin, Complete Path
A thin path takes one real user from the first action to a useful result. It may look modest, but every necessary handoff works.
For a vendor marketplace, that path could be:
- A buyer submits a request.
- An admin reviews it.
- One suitable vendor receives it.
- The vendor accepts or declines.
- The buyer sees the status.
Skip ratings, saved searches, dashboards, and complex matching at first. They can improve a workflow later. They can't prove that the core exchange has value.
6. Define the Test Before the Demo
A polished demo often rewards smooth screens. A useful test looks for evidence.
Choose a small group of real users and give them a real task. Watch where they pause, what they misunderstand, and where your team steps in. Record a few measures before the test:
- Completion rate
- Time to complete the workflow
- Number of manual interventions
- Missing or incorrect data
- Whether the result led to the next intended action
Five observed sessions can uncover more than a long internal review. The point isn't to prove the original idea right. It's to learn what the next sprint should fix, automate, or remove.
Final Thoughts
The best MVP is not the smallest pile of features. It is the smallest working system that tests the product's hardest assumption with real people.
This is the kind of question we scope in a discovery sprint: two weeks, fixed price, and a working slice that shows what to build next.
