📖 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 →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
Cohen, who bootstrapped two unicorns, argues that every line of code is a liability you will have to maintain and change, which is exactly the code you do not want stranded with an agency. It sharpens the instinct to build as little as possible for a validation stage. A strong reminder that owning code you cannot change is a trap.
From
A Smart Bear
by Jason Cohen
medium read
- Every line of code is future maintenance you must own
- Build less now so you have less you cannot change later
- Code you cannot modify yourself is a liability, not an asset
Open
longform.asmartbear.com →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
Cohen bootstrapped two companies past a hundred million in revenue, and he is blunt that a typical launch converts around one percent of traffic, so a burst of attention rarely becomes real customers. He shows why founders hide in features and launches because sales feels hard and out of their control. A sobering counterweight if a launch feels like the easy answer.
From
A Smart Bear (Jason Cohen)
by Jason Cohen
15 min read
- A typical launch converts roughly one percent of traffic to buyers
- Founders retreat to features because sales feels hard and uncontrollable
- Validate a real problem with real people before betting on reach
Open
longform.asmartbear.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Des Traynor makes the case that "no" is the product strategy, and that adding a feature for one loud customer quietly costs every other user. It gives you language to defend a tight v1 against constant requests. Short, sharp, and directly about the discipline of cutting.
From
Intercom (Des Traynor)
by Des Traynor
~8 min read
- A cohesive product with clear boundaries beats a pile of tangential features.
- Every feature you add has an ongoing cost, not just a one-time build cost.
- No single customer request is worth more than a coherent product.
Open
intercom.com →
📖 Book
✓ Link checked
Free
Beginner
Why we picked it
Free to read online, with chapters like "Build Less" and "Half, Not Half-Assed" that name your exact trap. It argues that cutting scope is a feature, and that the version with fewer things done well beats the bloated one. A fast, opinionated read you can skim straight to the chapters that sting.
From
Basecamp / 37signals
by Jason Fried, David Heinemeier Hansson (37signals)
Free online, ~4 hr
- Build half a product, not a half-built product.
- Every feature you add is one more thing to maintain and explain.
- Deliberately underdo the competition on scope.
Open
basecamp.com →
📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
A punchy, contrarian classic on building a lean, sane, profitable company from the founders of Basecamp. It's the antidote to hustle-culture folklore about how startups must operate.
From
37signals
by Jason Fried & David Heinemeier Hansson
~288 pages
- Small teams, less process, and shipping beat planning theatre
- Say no to most things and protect focus
- You can build a great company without following the standard playbook
Open
amazon.com →
📖 Book
✓ Link checked
Paid
Intermediate
Why we picked it
The full book behind the essay, for when you want the system and not just the idea. It gives you the language of outcomes over outputs so you can defend a no to your team and your customers with something concrete. Worth it if requests are piling up faster than you can reason about them.
From
Melissa Perri (O'Reilly)
by Melissa Perri
200 pages
- Tie every build decision to a measurable customer or business outcome
- Say no to work that only adds output without moving an outcome
- Set up the org so outcomes, not feature counts, decide priority
Open
amazon.com →
📖 Book
✓ Link checked
Free
Intermediate
Why we picked it
Basecamp's battle-tested, opinionated system for shipping meaningful work in fixed cycles without endless backlogs, a primary source, free in full. The antidote to over-planning your roadmap.
From
Basecamp / 37signals
by Ryan Singer
free online book
- Work in short cycles with a cool-down between them.
- Fix time, vary scope, use 'appetites,' not estimates.
- Make bets, not plans; no runaway backlog.
Open
basecamp.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
Freemium
Intermediate
Why we picked it
Once you are testing an idea, this piece gives you concrete signals that tell you whether it is actually working, from retention curves to organic word of mouth. It collects how experienced founders and investors describe the moment an idea starts to land. Read it so you know what evidence to look for instead of guessing whether the idea is good.
From
Lenny's Newsletter
by Lenny Rachitsky
about 15 min read
- Retention that flattens rather than falling to zero is the clearest signal
- Organic growth and referrals show the problem was real
- If people would be very disappointed to lose it, you are onto something
Open
lennysnewsletter.com →
📄 Article
✓ Link checked
Free
Advanced
Why we picked it
Cagan draws the line between discovery (figuring out what is worth building) and delivery (building it), and argues most waste comes from skipping the first. Reading this gives you a vocabulary for pausing before you build and testing whether the feature is valuable and usable at all. It is the disciplined version of your rule to write down who asked and what happens if you skip it.
From
Silicon Valley Product Group
by Marty Cagan
~12 min read
- Separate deciding what to build from building it
- Most features fail on value or usability, not engineering
- Test the risky assumptions cheaply before you write the code
Open
svpg.com →
🧵 Thread
✓ Link checked
Free
Beginner
Why we picked it
A raw, honest founder account of using building as a way to avoid the scarier work of selling and talking to strangers. It puts words to the exact addiction in your question: configuring a deploy pipeline feels safe, cold emailing ten customers does not. Reading someone name it in themselves makes it easier to catch yourself doing the same.
From
Indie Hackers
~8 min read
- Building can be a sophisticated form of procrastination
- We choose code because it is psychologically safe, not because it matters most
- The nervous system resists customer exposure, so name it and push through
Open
indiehackers.com →
✍️ Essay
✓ Link checked
Free
Beginner
Why we picked it
The definitive essay on where good ideas come from: notice problems you personally have, don't force it. Use it as the lens for judging whether your idea is a real problem or a solution in search of one.
From
paulgraham.com
by Paul Graham
~20 min read
- Live in the future and build what's missing.
- The best ideas look like bad ideas at first (schleps and hard-to-explain).
- Start with problems you have, in a domain you actually know.
Open
paulgraham.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 →
