What to prepare before briefing an MVP
A practical checklist that makes your first conversation with a development team dramatically more useful.
Why thin briefs stall delivery
An MVP brief does not need a 40-page specification. It does need enough truth that a technical team can challenge scope instead of guessing. When the brief is only a feature wishlist, every estimate becomes theatre and every sprint renegotiates the product.
The goal of a brief is shared risk: you reveal constraints early; the team reveals what will be expensive, fragile or unnecessary. That conversation cannot happen if the only input is “build an app like X.”
Write the risky assumptions on the same page as the feature list. Assumptions are not weakness; they are the list of things that would force a re-estimate if they turn out wrong.
Ask your partner to restate this section in their own words at the end of discovery. Misalignment here shows up later as change orders, not as polite disagreement.
Make this explicit in writing before build accelerates. Verbal alignment dissolves the first time a deadline tightens or a vendor slips.
Name the primary user and the job
Write down the primary user and the job they must complete in the first release. Secondary personas can wait. If you cannot name who succeeds on day one, you do not have an MVP — you have a catalogue of possible products.
Describe the job in verbs: approve a claim, place an order, book a visit, reconcile a ledger. Screens follow jobs; jobs do not follow screens.
Ask your partner to restate this section in their own words at the end of discovery. Misalignment here shows up later as change orders, not as polite disagreement.
Write the risky assumptions on the same page as the feature list. Assumptions are not weakness; they are the list of things that would force a re-estimate if they turn out wrong.
Ask how your partner will prove progress on this topic in staging demos, not only in status reports. Evidence beats adjectives in software delivery.
Systems, data and what already exists
List the systems the product must connect to, and whether those connections are read-only, write-back or both. Say what already exists: spreadsheets, a legacy portal, a third-party SaaS, or nothing.
Integrations dominate early risk. A clean UI on top of an unreliable vendor API still fails in production. Call out authentication, rate limits and who owns the vendor relationship.
Write the risky assumptions on the same page as the feature list. Assumptions are not weakness; they are the list of things that would force a re-estimate if they turn out wrong.
Ask your partner to restate this section in their own words at the end of discovery. Misalignment here shows up later as change orders, not as polite disagreement.
If internal bandwidth is thin, name a single owner on your side who can answer questions within a business day. External capacity without decisions still drifts.
Must ship versus nice to have
Separate “must ship” from “nice if we have time.” If everything is must, nothing is. Rank outcomes, not screens: what would make the release a success even if half the wishlist is deferred?
Bring the deadline and what is driving it — a sales cycle, a regulation date, a funding milestone. Artificial dates without consequences waste discovery; real dates with trade-offs focus it.
Ask your partner to restate this section in their own words at the end of discovery. Misalignment here shows up later as change orders, not as polite disagreement.
Write the risky assumptions on the same page as the feature list. Assumptions are not weakness; they are the list of things that would force a re-estimate if they turn out wrong.
Make this explicit in writing before build accelerates. Verbal alignment dissolves the first time a deadline tightens or a vendor slips.
Constraints that change architecture
Bring compliance, data residency, who will maintain the software, and whether you need a disposable prototype or a foundation you will keep. Those answers change architecture more than colour preferences do.
Also name who decides: product owner, security, finance. Ambiguous authority is how MVPs accumulate unowned decisions until launch week.
Write the risky assumptions on the same page as the feature list. Assumptions are not weakness; they are the list of things that would force a re-estimate if they turn out wrong.
Ask your partner to restate this section in their own words at the end of discovery. Misalignment here shows up later as change orders, not as polite disagreement.
Ask how your partner will prove progress on this topic in staging demos, not only in status reports. Evidence beats adjectives in software delivery.
Acceptance and how you will know it works
Define how you will accept the MVP: a demo script, a staging checklist, or a pilot with a real cohort. Vague “looks good” acceptance invites endless polish.
Include what “done” means for data: seed data, migration, empty-state behaviour. Empty products often fail reviews because nobody prepared realistic content.
Ask your partner to restate this section in their own words at the end of discovery. Misalignment here shows up later as change orders, not as polite disagreement.
Write the risky assumptions on the same page as the feature list. Assumptions are not weakness; they are the list of things that would force a re-estimate if they turn out wrong.
If internal bandwidth is thin, name a single owner on your side who can answer questions within a business day. External capacity without decisions still drifts.
What to bring to the first call
Arrive with the user/job, integrations list, must/nice split, constraints and acceptance sketch. Leave brand moodboards for later unless brand is the product.
When you are ready, send the brief. If you are building a multi-tenant product, our SaaS development page describes how we approach that shape of work.
Write the risky assumptions on the same page as the feature list. Assumptions are not weakness; they are the list of things that would force a re-estimate if they turn out wrong.
Ask your partner to restate this section in their own words at the end of discovery. Misalignment here shows up later as change orders, not as polite disagreement.
Make this explicit in writing before build accelerates. Verbal alignment dissolves the first time a deadline tightens or a vendor slips.
A note on Three Index
We staff MVP conversations with people who will touch the build, not only with sales. Expect pushback on scope that will not survive contact with users or integrations.
That pushback is the point of a good brief: fewer surprises after the contract is signed.
Ask your partner to restate this section in their own words at the end of discovery. Misalignment here shows up later as change orders, not as polite disagreement.
Write the risky assumptions on the same page as the feature list. Assumptions are not weakness; they are the list of things that would force a re-estimate if they turn out wrong.
Ask how your partner will prove progress on this topic in staging demos, not only in status reports. Evidence beats adjectives in software delivery.
Next step
FAQ
Short answers related to this article.
What should I bring to a first MVP briefing call?
Name the primary user and the job they must complete, systems and data that already exist, must-ship versus nice-to-have, hard constraints, and how you will accept done.
Why do thin MVP briefs stall delivery?
Teams guess at users, integrations and success criteria, then rebuild after the first demo. A short, concrete brief turns the first conversation into scope instead of discovery theatre.
How detailed does an MVP brief need to be before talking to Three Index?
Enough to decide architecture and sequencing — not a full specification. User, outcome, constraints and acceptance beat long feature lists with no decision owner.
Why Three Index
Founded in 2020 in Ahmedabad, Gujarat. Fifty-plus IT professionals. More than five hundred projects shipped across product and enterprise work.
We are large enough to staff serious products and small enough that the people who wrote a module can still explain it. See how we operate, browse case studies, or join the team.
Tell us what you are trying to build.
Send a short description of the project. You will get a reply from someone technical — with questions worth answering, not a brochure.