Write one product promise
Complete this sentence without mentioning a feature: For this primary user, the product turns this repeated input or problem into this useful result. If the sentence needs three users and five outcomes, the scope is already hiding multiple products.
The promise should be narrow enough to observe. It does not need a hypothetical revenue forecast; it needs an identifiable user, repeated job, result, and reason to return.
Map one end-to-end workflow
Start at the moment the user arrives with intent and finish when the useful result is available and recoverable. Include onboarding, the core job, confirmation, error recovery, and the next repeat visit. Screens that do not advance or support that path are candidates for later.
- Entry: invitation, signup, import, or setup.
- Core job: the repeated input, decision, and output.
- Trust: validation, review, source, status, or audit evidence.
- Recovery: correction, retry, cancellation, and support.
- Return: saved state, notification, history, or next action.
Define users, tenants, and permissions early
Authentication is not the same as authorization, and a workspace label is not tenant isolation. Name each actor, what they may read or change, who can invite or remove them, and what happens to their data when access changes.
If multi-tenancy is part of the product promise, test tenant boundaries at the data and API layers. Do not postpone isolation as interface polish.
Treat billing as an operating system
Billing affects account state, entitlements, taxes, invoices, retries, cancellation, access, and support. A checkout button is only the beginning. If payment is not needed to test the first product promise, a controlled manual enrollment may be the better MVP choice.
Include the internal surfaces needed to support the promise
A public dashboard can look complete while the team has no way to diagnose a failed job, correct account state, inspect an audit event, or respond to a support request. Admin and observability are part of the product when people depend on the result.
- Account and entitlement lookup.
- Job, event, or transaction history.
- Safe retry, correction, or cancellation tools.
- Audit fields for consequential changes.
- Error reporting that includes enough context to act.
Build the expensive uncertainty first
The riskiest assumption may be a data source, third-party API, model behavior, permission boundary, or workflow nobody will repeat. Prove that before spending the schedule on polished settings pages.
Use fixtures and narrow vertical slices to show the complete path. A thin slice through the real risk is more informative than a broad interface backed by placeholders.
Define release evidence before development starts
Write the acceptance matrix with the scope. Include the core workflow, permissions, data integrity, responsive behavior, keyboard access, error recovery, security-sensitive paths, deployment, monitoring, and known limitations.
The MVP succeeds when it produces evidence for the next decision. That might be repeated use, completion quality, willingness to pay, lower correction effort, or a disproved assumption. Implementation alone cannot guarantee any of those outcomes.