How to scope an MVP without cutting the wrong corners

A founder asks for a client portal. The proposed backlog includes a dashboard, document storage, billing, notifications, reporting, and an AI assistant. Every item has a plausible use. None explains what the first release is supposed to prove.

Start with a narrower question: will a consultant and their client move a weekly project update out of email and into a shared workspace? Now there is a behavior to observe, a user to recruit, and a reason to leave several features out.

This is an illustrative product brief. The choices below are our recommendations for scoping it, not results from a client project.

Test the assumption that could stop the product

The riskiest assumption might be demand. It might also be access to a third-party system, the quality of imported data, or whether a customer will trust the workflow. Building polished screens will not resolve every kind of uncertainty.

The UK Government Service Manual recommends using an alpha to test the riskiest assumptions with prototypes. It explicitly distinguishes this work from a public production service. That distinction is useful for startups: a throwaway prototype can answer a feasibility question before you commit to a live product. GOV.UK: how the alpha phase works.

For the portal, interview people who already exchange updates. Ask to see a recent exchange, including the follow-up questions and attachments. If the problem is that nobody writes an update in the first place, a different place to store updates may accomplish little.

Write a sentence that could turn out to be wrong: "Clients will reply to project updates in this workspace without a separate email reminder." Agree how you will observe that behavior before building notifications that could conceal the answer.

Draw the smallest complete workflow

A usable first version could let a consultant create a project, invite one client, post an update, and receive a reply. The invitation must work for someone who has never seen the product. The client must land in the correct project. Both people need to know that their messages were saved.

A dashboard containing empty charts contributes less to this experiment than a reliable invitation flow. A project marketplace contributes nothing unless discovery is the assumption being tested.

DORA identifies working in small batches as a capability that predicts software delivery and organizational performance. Its guidance favors independently testable changes and warns against regrouping them into a large release before collecting feedback. This supports the delivery approach; it does not establish a universal MVP duration or feature count. DORA: working in small batches.

For this portal, we would use a scope ledger:

Candidate work	First release	Reason
Create a project and invite a client	Include	Required to start the exchange
Post an update and receive a reply	Include	This is the behavior being tested
Restrict access to the invited project	Include	A customer must not see another customer's records
Custom branding	Defer	Does not resolve the initial workflow question
Automated billing	Handle separately during the pilot	The pilot can test collaboration before subscription operations
AI-written project summaries	Defer	Adds another behavior to evaluate before the core workflow is understood

A deferred feature needs a condition for reconsideration. "Add a reminder when users understand the workflow but forget to return" is more useful than a permanent bucket labeled phase two.

Decide what can safely remain manual

Invite the first participants yourself. Help them import an existing project. Review feedback in a spreadsheet if that is sufficient. Give each manual step an owner and a capacity limit so it does not become an invisible dependency.

Suppose onboarding needs an hour of founder time per account. That can be acceptable for a small pilot, but it changes what the experiment demonstrates. You are testing an assisted service. Do not interpret its completion rate as proof that self-service onboarding works.

Access checks, reliable saves, and recoverable records belong in the release. The implementation can be modest. An elaborate admin console can wait; an operator still needs a documented way to resolve an account problem without granting broad access or editing random production rows.

Write acceptance criteria before asking for a price

"Build invitations" leaves room for incompatible expectations. A more useful acceptance criterion is: an invited client can sign in, see only the intended project, and request a replacement when an invitation expires.

Add failure cases that would invalidate the pilot. A client who submits a reply twice after a slow connection should not create two indistinguishable messages. A failed save must not appear successful. A founder should be able to identify which release introduced a problem and restore the previous working version where it is safe to do so.

The brief should also record the supported devices, third-party accounts required, and who answers support requests. Estimate after these decisions. An integration awaiting vendor access remains a scheduling risk even if the implementation looks small.

Choose evidence that will change the next release

A signup records interest. For the portal, stronger evidence is a complete exchange followed by another update the following week. Watch where participants switch back to email and ask why. Count founder interventions separately from independent completions.

Set the review criteria before the pilot. With a small group, the findings are directional, not a reliable market-wide conversion estimate. You can still learn that clients cannot find attachments, that consultants need a draft state, or that the proposed workflow solves a problem nobody considers urgent.

If participants succeed only after repeated assistance, improve the failed step before expanding the product. If the original assumption fails, revise it. More features will make the next test harder to interpret.

When AI belongs in the first version

Include AI when its performance is part of the product's central promise. A document extraction product cannot postpone testing extraction quality. A collaboration portal can usually test its core exchange before adding generated summaries.

For an AI-dependent MVP, include representative test cases, an acceptable failure behavior, and the cost of reviewing outputs in the scope. Our production AI integration checklist details those requirements.

Before the next estimating meeting, prepare a one-page brief containing the user, current workaround, assumption, complete workflow, exclusions, acceptance criteria, and review date. Ask each proposed feature which part of that brief it serves.