Before you run these exercises
Chapter 4 is about the ways founders systematically fool themselves — and the specific moments when it happens. There's a story in this chapter about a company that did something most founders would consider absurd before writing a single line of code. It worked. The principle behind it is one of the most practically useful ideas in the book.
The chapter also has a section on the people charging founders for advice and connections — what Charlie calls the "venture vultures" — and a framework for telling them apart from the real thing. If you have advisors or are thinking about adding them, read this chapter before you sign anything.
The chapter's point about friend feedback is precise: people in your network see their role as supportive, not critical. They give you schmuck insurance. What you need instead is someone who will say "I already use X for this and I'm perfectly happy with it" or "I'd pay for it if it did Y, but not as described."
Before you go out to real customers — where bad first impressions are hard to recover from — use Claude to simulate the skeptical version of your target buyer. It will surface objections you haven't thought of, expose assumptions you're taking for granted, and give you the experience of being challenged before the stakes are real.
The chapter is direct about what real competitive research looks like: sign up for their product, go through onboarding, analyze customer reviews and Reddit threads, contact former employees. Not click around their homepage. Not read their about page. Actually use the thing and talk to people who've been inside it.
But understanding the competition is only half the job. The other half — the one most founders skip — is getting your idea in front of real potential customers before you've built anything serious. Not AI simulations, not supportive friends. The actual humans who would pay for this. AI can help you identify exactly who they are and reach them at scale.
Part 1 — Competitive Research
Part 2 — Find and Reach Real Customers at Scale
The competitive research tells you what's broken. But the real test is whether real humans — not AI, not friends — respond to what you're building. Use Claude to figure out exactly who your ideal early tester is, where they congregate, and how to reach enough of them to get signal.
The housekeeper example in the chapter makes a sharp point: "What do you think?" is a useless question. What founders need instead are specific hypotheses tested with specific questions — "What if I told you everyone was background checked? What if you could see ratings?"
Most founders are swimming in assumptions that have never been written down, let alone tested. Turning those assumptions into explicit hypotheses — each with a clear test and a clear success criterion — is the difference between learning and just gathering opinions.
The chapter ends with one of the sharpest frameworks in the book: the chapter puts a specific dollar value on founder time that reframes how you should be thinking about every hour you spend. The number is in the book. Most founders spend a significant portion of it on $20/hour work — admin, formatting, research tasks, things that feel productive but aren't creating enterprise value.
AI is the single most powerful lever for reclaiming that time. Not because it replaces you — but because it handles the $20/hour work so you can spend more hours doing the $1,000/hour work: customer conversations, strategic decisions, recruiting relationships, and building the things only you can build.
The "venture vultures" section of this chapter is one of the most useful and underappreciated parts of the book. The book gives three clear tests for anyone giving you advice: did they personally do the specific thing you're trying to do? Do they work from your goals, not generic frameworks? And are they being clear about what their incentives are?
Most founders are taking advice from people who have failed the first test — they're adjacent to success, not the source of it. The advisor page being "a list of rich people who know enough not to invest" is one of the sharpest lines in the book. Use Claude to apply this rigorously to who you're currently listening to.
The book names Lovable directly in this chapter, in the context of testing ideas before committing to building them. The Aardvark story is the principle: do the thing manually first, prove the demand is real, then build the software. A landing page with a waitlist is the modern version of that. It tells you whether people care enough to give you their email before you've written a line of real product code.
This is the Lovable use case the book is actually describing. Not a full product — a signal-gathering machine. Build it in 20 minutes, put it in front of real potential customers, and find out if the problem resonates.
- Go to lovable.dev and start a new project.
- Paste this prompt, customized for your product:
- Share it with 20–30 people who match your target customer profile — not your friends, your actual potential customers.
- Track who signs up and who doesn't. The conversion rate is your first real data point. Follow up with everyone who signed up and ask them one question: "What made you interested enough to sign up?" Their answer is your messaging.
The chapter is blunt about what "feedback" usually means: people being supportive, not honest. The friends who say "that's amazing." The beta users who say "I'd definitely use that." The chapter tells you what real signal looks like — but even when you get it, the problem is that most founders process customer calls through memory, and memory is selective. You remember what confirmed your hypothesis. You forget or minimize what didn't.
Transcription tools like Granola (granola.so) change this. Granola runs in the background during calls and produces a clean, structured summary with the actual language your customers used — not your interpretation of it. When you feed those transcripts to Claude, you can analyze patterns across calls that you'd never catch in the moment: the objections that keep coming up in different words, the features people ask about that aren't in your deck, the problem framing that resonates versus the one you've been using.
This is the Aardvark principle applied to discovery calls: do the thing first, learn from what actually happens, then build.
Chapter 4 is asking one question in a dozen different ways: are you finding out what's actually true, or are you collecting evidence that confirms what you already want to believe?
Before you move on, you should have run at least one skeptical customer simulation, done real competitive research on your top competitor (reviews, former employees, Reddit — not their homepage), and mapped your untested assumptions against what you've actually proven.
And if you haven't done the founder time audit: do it before Chapter 5. Every hour you spend on $20 work is borrowed against the hours that could get you funded.