"If you are not embarrassed by the first version of your product, you've launched too late." Reid Hoffman's line is quoted everywhere. It is also widely misunderstood.
Many teams hear it as permission to ship something buggy and half-finished. That is not what a Minimum Viable Product is. An MVP is not a quality level. It is a learning strategy: the smallest thing you can put in front of real users to test whether your most important assumption is true.
Before you cut scope, write the one sentence your business depends on. For example:
Market traders in Onitsha will pay a monthly fee to see which of their customers owe them money.
Everything in the MVP should exist to prove or disprove that sentence. A login system, a dashboard of charts and a referral scheme do not test it. A simple list of debtors that a trader can update in under a minute does.
Some of the best-known MVPs barely involved code:
A WhatsApp group run by hand, a Google Form and a spreadsheet, or a person doing manually what the software will later automate are all legitimate MVPs if they answer the key question.
The most common failure is adding "just one more feature" because the team is nervous the core idea is not enough on its own. Every extra feature delays launch, muddies the result, and makes it harder to tell why users stayed or left.
A useful test: for each feature, ask "If we removed this, could we still learn whether our main assumption is true?" If yes, cut it.
An elegant solution to a mild inconvenience will get compliments and no usage. Before building, confirm the problem costs your users time, money or customers, and that they have already tried to fix it some other way. (Our post on user interviews covers how to find that out.)
An MVP that nobody sees teaches you nothing. Plan how the first 50 users will find it before you write code, whether that is a market association, a WhatsApp community or ten businesses you visit in person. Launch day is day zero of the experiment, not the end of the project.
It should feel slightly uncomfortable to show people because it is so stripped down. But it should be sharp enough to get a clear reaction: "Yes, I need this" or "No, this doesn't solve my problem." A vague "it's nice" means the test was not sharp enough.
One of the hardest moments in our cohorts is scope-cutting: participants start with a long backlog and must reduce it to the one thing that tests one real user problem. Letting go of good ideas for now is a skill, and it improves with practice.
Want to learn to scope an MVP under real constraints? See when the next Culmino Labs cohort opens.
Next read: The Anatomy of a PRD Engineers Will Actually Read.
