Marketplace MVP Scope for a Complete First Transaction
Define marketplace MVP scope around a complete transaction. Separate essential features from manual pilot work with a role-by-role worksheet.
Luka Abramovic3 min read
Marketplace MVP scope should cover one complete transaction between the first buyer and provider. A searchable directory can be technically finished while nobody can request, accept or complete work. Define the event that means both sides received the promised outcome, then work backwards.
For a domain expert with access to a professional community, a narrow first market makes the workflow easier to observe. Choose one service category, one type of request and a group you can recruit. Treat that boundary as a pilot decision, not evidence of demand.
Walk one request through both accounts
Use separate buyer and provider accounts and a realistic request. Write each change in state on a card. A starting sequence is draft, submitted, offered, accepted, delivered and closed. Add declined and cancelled where those outcomes can occur. Agree who can move the request and what the other person sees.
At each transition, ask which information must exist. A provider cannot make a meaningful offer if the request omits the deliverable. A buyer cannot accept confidently if the offer lacks the terms the product is meant to capture. Fix those inputs before polishing the directory.
Use a transaction scope worksheet
| Transition | Evidence needed | Pilot implementation | Failure route |
|---|---|---|---|
| Request submitted | Brief and contact route | Product form | Return incomplete brief |
| Provider selected | Category and availability | Founder routes manually | No suitable provider message |
| Offer accepted | Specific offer version | Recorded confirmation | Offer expired or changed |
| Work closed | Delivery and buyer response | Product status plus review | Disagreement sent to operator |
Put a named operator beside every manual row and specify where they record the result. A manual match can be a deliberate scope choice. A match made in a private message that never updates the request leaves the product with a false state.
Run the cases the happy path hides
Submit a request when no provider is eligible. Leave an offer unanswered. Cancel after acceptance. For each case, check what the waiting person sees and who has the next action. Do not substitute a generic error for an operational decision.
Retain the accepted offer version. If the provider edits the offer afterwards and the screen shows only the latest text, the product can no longer show what the buyer accepted. A version reference solves a different problem from a confirmation button.
Measure completion and waiting separately
In an illustrative pilot, 12 requests produce eight offers and five completed exchanges. Report all three counts. If the founder spends 15 minutes routing each request, handling consumes 180 minutes. A two-day wait for providers is additional elapsed time, not 48 hours of founder labour.
Inspect every request that stopped. Separate missing supply, unusable briefs, unanswered offers and product defects. Each calls for a different change. Before adding a feature, name the failed transition it should improve and the evidence you would expect to see afterwards. A payment integration, for example, cannot fix the absence of a provider willing to fulfil the request.
Bring a sample request and the two user roles. We can map which transitions need software and which can stay manual during the pilot. Discuss the first release with Adamant Code.