Customer Development: Get Out of the Building
Here is the most common way technical founders fail. They have an idea. They love it. They sit at their desk for six months and build it. They launch. And nobody comes. The product works perfectly. It just solves a problem that no one will pay to fix.
This chapter is the cure. It teaches you a simple, proven way to find out whether your idea is real before you waste months building the wrong thing. The method is called Customer Development. The slogan you must tattoo on your brain is "Get out of the building."
Where this idea comes from (the real people and books)
You do not have to invent this. Two famous thinkers already mapped it out, and their work is now the standard playbook in Silicon Valley.
- Steve Blank is a serial entrepreneur and Stanford/Berkeley teacher. In his book The Four Steps to the Epiphany (2005) he created Customer Development and the phrase "get out of the building." His big point: building a product is a known engineering process, but finding customers is a process of discovery that has to happen face-to-face, outside.
- Eric Ries was a startup founder who studied under Blank. His book The Lean Startup (2011) turned these ideas into a loop any founder can run. He gave us two terms we will use constantly: Build-Measure-Learn and validated learning.
Let me define those two Ries terms in plain words right now, because we use them throughout.
- Build-Measure-Learn
- A repeating cycle. You build the smallest thing that tests an idea, you measure how real customers react, and you learn whether your guess was right. Then you go around again.
- Validated learning
- Progress measured not by "we wrote more code" but by "we learned something true about customers, proven by their actual behavior." Writing 5,000 lines of code that nobody wants is zero progress. Learning that nobody wants it (after one week of conversations) is real progress.
The four steps (a beginner's overview)
Blank splits the early life of a company into four steps. As a solo founder you mostly live in step one for a long time. But it helps to see the whole map.
- Customer Discovery — Go find out if the problem you imagine is a problem real people actually have, and badly enough to want a fix. This is where you spend almost all your early time. This chapter is mostly about this step.
- Customer Validation — Prove people will actually pay, and find a repeatable way to sell. (Can you get a few real customers using a sales process you could do again?)
- Customer Creation — Now that selling works, spend money to create demand and bring in more customers (marketing, ads, growth).
- Company Building — Switch from "search mode" to "run a company mode": hire teams, build departments, scale up.
Blank's deep insight: steps 1 and 2 are a search for a business model. Steps 3 and 4 are execution of one you've already found. Most startups die because they jump straight to execution (hiring, spending, scaling) before they've actually found something that works. And the model expects you to loop back: you will go around discovery and validation several times before it clicks. As Blank puts it, it's okay to mess up — as long as you plan to learn from it.
Two finish lines: problem/solution fit, then product/market fit
You will hear two phrases everywhere. They are simply two milestones, in order.
- Problem/Solution Fit (the first milestone)
- You have proof that a real, painful problem exists and that your proposed solution would plausibly fix it. You go from hoping people want this to having evidence they do — before building the full thing.
- Product/Market Fit (the bigger, later milestone)
- Your actual, built product satisfies a real market so well that demand pulls you forward — people keep buying, keep using, and tell others. This is the famous moment a startup is "working."
You cannot skip to the second. Problem/solution fit is the foundation product/market fit is built on. Customer Discovery is how you reach the first milestone cheaply, mostly through conversations.
TALK to customers ── reach ──> PROBLEM/SOLUTION FIT
(cheap, fast) "Yes, real pain. Fix makes sense."
│
then BUILD
│
v
USE real product ── reach ──> PRODUCT/MARKET FIT
(the built thing) "The market pulls; demand is real."
Turn your idea into testable guesses (hypotheses)
A hypothesis is just a fancy word for a specific guess you can check. Right now your idea is a big fuzzy belief. The first move is to break it into small, sharp guesses, each one you can test by talking to people.
Don't write: "Print shops need better software." That's too vague to test. Instead break it down:
- Who exactly has the problem? ("Owners of small print shops with 2–10 staff.")
- What painful thing happens today? ("They re-key online orders into their machines by hand and make costly mistakes.")
- How much does it hurt? ("They lose time and money on reprints every week.")
- What do they do about it now? ("They use spreadsheets and sticky notes.")
Why this happens BEFORE and ALONGSIDE building — not after
Here is the trap technical founders fall into: "I'll just build it, then ask people." By then you've spent your scarcest resource (months of your life) betting on an untested guess. Customer Development flips the order. You test the riskiest guesses with cheap conversations first. Then you keep talking to customers while you build, so every feature is steered by real feedback. Talking to customers is never a one-time phase you finish. It runs forever, beside the code.
How this is different from a market research survey
You might think: "I'll just send out a survey." Be careful. Surveys and Customer Development are not the same thing, and surveys are weaker for an early idea.
| Market research survey | Customer Development conversation |
|---|---|
| Many people, shallow, fixed questions | Few people (10–15), deep, follow-up questions |
| Asks for opinions and "would you?" | Asks about real past behavior |
| You can't dig into a surprising answer | You ask "why?" and discover things you never expected |
| People say what sounds nice | You hunt for facts that can't be faked |
This connects to the single most useful book on customer conversations: The Mom Test by Rob Fitzpatrick. The title comes from this: even your mom will lie to you about your idea, to protect your feelings. So you must ask questions even your mom couldn't lie about. Fitzpatrick gives three rules:
- Talk about their life, not your idea. (The moment you pitch, they start being polite.)
- Ask about specifics in the past, not opinions about the future. ("Would you use this?" is worthless. "When did you last hit this problem, and what did you do?" is gold.)
- Talk less, listen more.
A concrete example: testing one assumption with 12 people
Say you're building software for small print shops (sound familiar?). Your riskiest guess is: "Shop owners lose real money re-typing online orders by hand." Here's how you test it without writing code.
You find 12 print shop owners (call, email, visit, ask for intros). You meet each for 20 minutes. You do not pitch. You ask Mom-Test questions:
You: "Walk me through what happens when an order comes in from your website."
Owner: "Oh, it's a nightmare. I print the email, then type it all into our machine software again."
You: "When was the last time that went wrong?"
Owner: "Last Tuesday. I fat-fingered a quantity, printed 500 instead of 50. Ate the cost myself."
You: "Wow. How often does something like that happen?"
Owner: "Couple times a month, honestly."
You: "What have you tried to fix it?"
Owner: "I made a checklist. Doesn't really help."
You: "Have you ever paid for anything to solve this?"
Owner: "I looked at a tool once but it was built for big factories. Too expensive, too complex."
Notice what you got: a real story, a recent date, a dollar cost, a current workaround, and proof they already tried (and failed) to solve it. That's validated learning. After 12 of these, you'll see a pattern. Maybe 9 of 12 describe the same painful re-typing. Now your guess is validated — and you also learned the magic words real owners use ("nightmare," "fat-fingered," "built for big factories"), which become your marketing copy later.
"Do things that don't scale" — getting your first users by hand
Paul Graham (co-founder of startup accelerator Y Combinator) wrote a famous 2013 essay, Do Things That Don't Scale. His advice pairs perfectly with Customer Development. At the start you should recruit users manually, one by one, and delight them by hand — even in ways you could never repeat for a million users.
His favorite example: the Airbnb founders flew to New York and went door-to-door, signing up hosts and even taking professional photos of their apartments themselves. Totally unscalable. Exactly right for the start. Y Combinator boils its whole philosophy down to two jobs for an early founder: "Write code and talk to users." For you, the introvert technical founder, the uncomfortable half of that sentence is the more important one.
┌──────────── THE LOOP (repeat forever) ───────────┐
│ │
WRITE a guess ──> GET OUT, talk to 10–15 people ──> LEARN
(hypothesis) (Mom-Test questions) (true/false?)
^ │
└────────── refine the guess, go again <───────────┘
Key takeaways
- Get out of the building. The facts that decide your fate live in customers' heads, not at your desk. Talk to real people before and while you build.
- Customer Development (Steve Blank) has four steps — Discovery, Validation, Creation, Company Building — but as a solo founder you live mostly in Discovery for a long time.
- Aim for problem/solution fit first (cheap, via conversations), then product/market fit later (with the built product). Don't skip the first.
- Turn your fuzzy idea into specific, testable guesses (hypotheses) you can mark true or false after about a dozen conversations.
- Use The Mom Test: ask about their real past behavior, not opinions about your idea. Opinions are worthless; behavior is everything.
- Surveys give you shallow opinions; deep conversations give you facts, stories, and the customer's own words.
- Follow Paul Graham: do things that don't scale and remember the two jobs of an early founder — write code and talk to users.