📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
The single best thing ever written on customer conversations. It teaches you to ask about the customer's life and past behaviour, not your idea, so you can't be lied to. If a founder reads one thing before talking to a single customer, it's this.
From
momtestbook.com
by Rob Fitzpatrick
~130 pages
- Talk about their life, not your idea.
- Ask about specifics in the past, not opinions about the future.
- 'That's so cool, I'd totally buy it' is a compliment, not data, dig for commitment and evidence.
Open
momtestbook.com →
📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
The origin text for the modern MVP and validated-learning vocabulary every founder now uses. Read it for the mental model that a startup is a series of experiments, not a single bet.
From
theleanstartup.com
by Eric Ries
~330 pages
- Progress = validated learning, not features shipped.
- Run the Build-Measure-Learn loop as fast as you can.
- An MVP is a learning tool, not a cheap product.
Open
theleanstartup.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
A short, free primer straight from the person who coined the term, useful when someone on your team thinks an MVP just means a cheap version of the full product. It clarifies that an MVP can be as small as a landing page or a manual service as long as it produces real learning. Read it to reset the definition before you scope anything.
From
Lean Startup Co.
by Eric Ries
~8 min read
- An MVP is about learning, not about a smaller product
- It can be a page, a video, or a manual service
- Customers must take a real action for the test to count
Open
leanstartup.co →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Blank, who built customer development, uses a real founder story to show how a team defaulted to 'build a smaller product' when the right move was a test that cost almost nothing. The piece pushes you to name your riskiest assumption and design the cheapest possible experiment against it. It is a direct match for the idea that your MVP might be a conversation or a fake feature, not code.
From
steveblank.com
by Steve Blank
7 min read
- Start from the assumption that could kill you, then test only that
- The cheapest experiment that answers the question beats a small polished build
- You are selling the vision but delivering the minimum feature set
Open
steveblank.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
The canonical fake-door test, told by the founder who ran it. Buffer started as a two-page site: one page pitched the tool, a pricing button led to an email capture, and every signup got a personal note. Real demand, real conversations, a paying customer in weeks, and not a line of product code.
From
Buffer
by Joel Gascoigne
~10 min read
- Test willingness to pay with a pricing page before you build.
- Email every signup by hand and start a conversation.
- A landing page measures behaviour, not opinions.
Open
buffer.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
The two ways to fake a product while you test real demand. Do the work by hand in the open (concierge), or hide the manual work behind a front so users think it is automated (Wizard of Oz, the way Zappos started). Clear examples of when each one fits.
From
LogRocket
~12 min read
- Concierge is transparent, Wizard of Oz is hidden.
- Both let you sell before you build.
- Match the method to what you are unsure about.
Open
blog.logrocket.com →
✍️ Essay
✓ Link checked
Free
Beginner
Why we picked it
This is the canonical source of the ship-ugly-first idea, the LinkedIn co-founder's own essay behind the line about being embarrassed by your first version. For a solo dev deciding how much to build into a referral program before shipping, this is the judgment call at the heart of the question, launch the rough version and let real usage tell you what to add. Hoffman also draws the line on where ship-fast should not apply, which keeps it honest rather than a slogan.
From
LinkedIn
by Reid Hoffman
About a 6 minute read
- Ship the version you are slightly embarrassed by, because real user behavior teaches you what to build far faster than internal guessing
- Embarrassing is not the same as harmful: launching fast does not excuse things that alienate users or create real risk
- Speed compounds: earlier feedback means earlier iteration, which matters more than polishing features nobody has asked for yet
Open
linkedin.com →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
Cagan draws a sharp line that saves founders real pain: the thing you use to test a hypothesis is an experiment, not a product you ship to everyone. He argues for calling it an MVP test so you do not confuse a throwaway prototype with something customers must be able to rely on. This keeps you from over-building a 'real' product when a rough test is all you need.
From
Silicon Valley Product Group
by Marty Cagan
6 min read
- Separate the MVP test (an experiment) from a product you would ship broadly
- A prototype that proves usable is not proof people will choose to use it
- Keep experiments cheap and disposable, do not gold plate them
Open
svpg.com →
📖 Book
✓ Link checked
Paid
Intermediate
Why we picked it
This is the practical, step-by-step manual for the Lean Startup ideas, built around the one-page Lean Canvas and a system for ranking your riskiest assumptions. It gives you a repeatable way to decide what to test next instead of guessing, which is exactly the 'what must I learn next' question at the heart of a good MVP. Use it when you want a process rather than inspiration.
From
LeanFoundry
by Ash Maurya
240 pages
- Map your whole idea on one page, then attack the riskiest box first
- Prioritise experiments by risk, not by what is easiest or most fun to build
- Talk to customers on a schedule, treating each conversation as data
Open
leanfoundry.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Turns the vague feeling of product-market fit into a number you can move. Ask users how they would feel if they could no longer use the product, then track the share who say 'very disappointed'. Under 40 percent means keep working. A test you can run on an idea long before you scale it.
From
First Round Review
by Rahul Vohra
~20 min read
- The 40 percent 'very disappointed' benchmark for product-market fit.
- Segment to your high-expectation customers and build for them.
- Make the fit score a metric you improve quarter by quarter.
Open
review.firstround.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
CB Insights read hundreds of real startup postmortems and found that poor product-market fit (around 43 percent) is the single biggest root cause of failure, ahead of running out of money. If you want to spot the warning signs early, start with the patterns of founders who already hit them: a market too small, a problem not painful enough, a product nobody urgently wanted. Treat it as a checklist of ways an idea can quietly go nowhere for a year.
From
CB Insights
by CB Insights
~15 min read
- The top root cause of failure is building something with no real market need, not running out of cash (cash is usually where the story ends, not why).
- Weak demand often hides behind early traction, so polite interest and a few friendly users can mask an idea that never widens into a market.
- The list doubles as an early-warning checklist: if your idea already leans on bad timing, thin unit economics, or a problem people can live with, take that seriously now.
Open
cbinsights.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
A clear, jargon-free explainer that corrects the most common misuse of the term, where teams ship a broken product and call it 'minimum viable.' It stresses that viable means it still has to deliver real value, even while being small. A good grounding read if you are unsure where the line sits between too little and just enough.
From
Nielsen Norman Group
by Sara Paul
8 min read
- Minimum and viable both matter, so it must still deliver real value
- An MVP is for learning, not for shipping a knowingly broken experience
- Scope down features, not the quality of the core value you promise
Open
nngroup.com →
Why we picked it
The permission slip to recruit users by hand, do things manually, and deliver 'insanely great' experiences to your first few customers. The cheapest, most honest way to validate demand is to go get it one person at a time.
From
paulgraham.com
by Paul Graham
~15 min read
- Recruit your first users manually, don't wait for them to come.
- A tiny group of users who love you beats a big group who like you.
- Manual, unscalable effort early is a feature, not a failure.
Open
paulgraham.com →
Why we picked it
This is the founder essay that made the case for validating before you build, from the person who did it with Buffer. Gascoigne frames the no-code or landing page MVP not as a shortcut to a product, but as a way to learn whether anyone actually wants the thing, which is exactly the stance this question takes. His honest point is that 120 signups plus real conversations taught him more than any polished build would have.
From
Medium (Joel Gascoigne, co-founder of Buffer)
by Joel Gascoigne
- The goal of a no-code or landing page MVP is validated learning, not vanity signups: talk to the people who respond, do not just count emails.
- Anything can be your MVP as long as you are genuinely testing demand before committing to a full build.
- Buffer got only 120 signups in seven weeks, but the direct conversations proved real interest and led to paying customers at launch.
Open
medium.com →
