A Customer Development Plan You'll Actually Run

Most founders read The Four Steps to the Epiphany, nod vigorously, and then go build the thing anyway. Steve Blank's customer development framework is one of the most cited ideas in startupland and one of the most consistently ignored. The reason isn't laziness — it's that the gap between "talk to customers" and an actual customer development plan you can run on a Tuesday morning is enormous, and nobody hands you a bridge.

This article is the bridge. Or at least the blueprint for one.

Why Customer Development Dies in the Abstract

The principle is simple enough: before you build, get out of the building and test whether your problem hypothesis is real. But "test your hypothesis" is not a plan. It's a sentiment.

What kills customer development in practice isn't scepticism — most founders intellectually buy in. What kills it is the absence of structure. Without a week-by-week skeleton, interviews become sporadic. Without a script, conversations drift toward pitching. Without disqualifying criteria defined in advance, you unconsciously cherry-pick the responses that confirm what you already believe.

Confirmation bias is pernicious precisely because it feels like evidence-gathering. You walk out of five conversations thinking "people love this idea" when what actually happened is you steered every conversation away from the moment someone hesitated.

A proper customer development plan forces you to design the disconfirmation before you start.

What the Plan Actually Contains

A runnable customer development plan has five components. Not fifty slides — five things: Problem hypotheses — specific, falsifiable statements about who suffers from what and why existing solutions fail them. Customer segments — narrow enough to be meaningful. "SMEs" is not a segment. "Operations managers at UK logistics firms with 20–100 staff" is a segment. Interview script — structured enough to be consistent across conversations, loose enough to follow genuine threads. Disqualifying evidence — defined in advance: what responses or patterns would tell you the hypothesis is wrong? A week-by-week schedule — who you're speaking to, when, and what you're deciding at the end of each sprint.

The last one is where most plans collapse. A list of questions is not a plan. A calendar with decision gates is.

Hypothesis First, Always

Before you write a single interview question, write your hypotheses down in plain language. Not "people want a better project management tool." Something like: "Operations managers at mid-sized logistics firms spend more than three hours per week manually reconciling delivery exceptions, and their current tools require too much IT involvement to configure."

That statement is falsifiable. You can go find out whether three hours is right, whether IT involvement is the actual friction, and whether operations managers are even the ones feeling the pain (rather than, say, their coordinators).

Each hypothesis should have a corresponding signal you're looking for in interviews — and a counter-signal that would kill it. If five of your first eight conversations reveal that IT involvement isn't the bottleneck at all, the hypothesis is dead. That's not failure; that's the plan working.

Building an Interview Script That Doesn't Pitch

The classic mistake: your "interview" is actually a demo with a question tacked on the end. People are polite. They will not tell you your idea is rubbish to your face.

A good script follows a rough chronology: • Open with their world, not yours. "Walk me through how you currently handle X" gets you behaviour. "What do you think of the idea of a tool that does Y" gets you politeness. • Probe for frequency and cost. How often does this happen? What does it cost you — in time, money, stress, political capital? Vague answers ("it's a bit of a pain") are not validation. • Dig into workarounds. If someone has built a spreadsheet, hired a workaround employee, or switched tools three times, that's signal. If they'v