An MVP is a learning instrument shaped like a product.

What an MVP actually is

An MVP — Minimum Viable Product — is the smallest useful version that lets you learn what to build next. It is not the final product. It is not even a draft of the final product. It is an experiment that happens to be usable.

What an MVP is NOT

• ·A finished product with fewer features
• ·An excuse for poor quality
• ·Just a prototype
• ·A way to skip validation

Common MVP mistakes

• ·Overbuilding before evidence
• ·Confusing 'minimum' with 'unusable'
• ·Building an MVP before completing validation
• ·Treating the MVP as the final product instead of a learning step
• ·Skipping a landing page or founder presence first
• ·Hiding the MVP instead of building it in public

Validation before MVP

Before writing a single line of production code, you should have evidence: real conversations, a landing page that converts, a waitlist with names you didn't beg for. Validation makes the MVP decisions obvious.

Landing pages before MVP

For most founders, a landing page is the right first investment. It costs less, ships faster, and teaches more than any early MVP. Once a landing page is converting, an MVP becomes a much safer bet.

Founder presence before MVP

Founder presence is trust infrastructure. When you launch your MVP, it will land in an audience already warmed by your story.

Build in public

An MVP that ships in public collects feedback the moment it can be useful. Hiding the MVP wastes its most valuable asset: the right to be wrong with witnesses who can help.

Iteration cycles

Decide what you'll learn before you ship. Decide how long you'll wait before deciding. Then ship, learn, and decide. Repeat in short, honest cycles.

When MVPs are premature

• You haven't completed customer interviews yet
• You haven't tested demand with a landing page or waitlist
• You can't describe the problem in your customer's words
• You don't yet know what 'success' means for this version