What It Is
The Minimum Viable Business Product (MVBP) is Bill Aulet's refinement of the Minimum Viable Product concept from Disciplined Entrepreneurship. Where a traditional MVP often means the smallest thing you can build to test a hypothesis (which may be a landing page or a non-functional prototype), the MVBP is the smallest product that a customer in your beachhead market will actually pay money for. It bridges the gap between learning experiments and a real business.
When to Use It
- After you have validated the problem and selected a beachhead market, and you need to define what to build first.
- When the team is debating feature scope for the first release and needs a clear decision framework.
- When MVP thinking has led to products that generate "interesting feedback" but no revenue.
- When you need to prove the business model, not just the technology.
How It Works
Step 1: Define the Core Use Case
Identify the single most important workflow or job-to-be-done for your beachhead customer. Strip away everything that is not essential to completing that workflow successfully.
Step 2: Apply the Three MVBP Conditions
The product must satisfy all three:
-
The customer gets standalone value. They can use it without needing features that do not exist yet. It is not a demo or a teaser — it solves a real problem end-to-end for one use case.
-
The customer pays for it. Real money changes hands. This is the critical distinction from a traditional MVP. Free usage teaches you about usability but not about willingness to pay, pricing, or purchase process.
-
It creates a feedback loop. The product is real enough that customers use it in their actual workflow, generating usage data and organic feedback that guides what to build next.
Step 3: Identify the Whole Product Elements
The MVBP is not just the core feature. Ask what else the customer needs to actually use and pay for it:
- Onboarding — Can they get started without your personal help?
- Documentation — Do they know how to use it?
- Support — What happens when something breaks?
- Billing — Can they actually pay you?
- Data handling — Is their data safe enough for them to trust you?
You do not need perfect versions of all of these, but you need functional-enough versions that do not block the sale.
Step 4: Scope Ruthlessly
For every feature beyond the core use case, ask: "Will a beachhead customer refuse to pay if this is missing?" If the answer is no, cut it. You can add it later.
Key Principles
- Revenue is the test. Signups, usage, and compliments are weak signals. A customer paying money is the strongest possible validation that you have built something valuable.
- Whole product thinking from day one. A brilliant algorithm with no onboarding flow is not a product. Customers buy complete solutions, not components.
- Beachhead-specific. The MVBP is designed for your beachhead market specifically. What counts as "minimum" depends entirely on what that specific customer segment needs and expects.
- It is still minimum. The "business product" framing does not mean building a full-featured product. It means building the smallest thing a customer will pay for — not the smallest thing you can test for free.
Common Mistakes
- Confusing MVBP with "launch everything." The point is not to build a complete product. It is to build the smallest complete-enough product that clears the payment bar.
- Building an MVP and calling it an MVBP. If no one is paying, it is an MVP at best. The payment requirement is the defining characteristic.
- Ignoring the surrounding experience. A feature-complete core with a broken signup flow is not a viable business product. Customers evaluate the entire experience, not just the core feature.
Source
Bill Aulet, Disciplined Entrepreneurship (2013), Step 14. The MVBP is positioned as the bridge between customer validation and initial product-market fit, building directly on the beachhead market selection from earlier steps.
