Discovery & Experimentation

The most expensive thing you can build is the wrong thing, built well.

Sit with that for a second. Not the buggy thing. Not the late thing. The thing you scoped tight, staffed with good people, shipped clean, and shipped on time. The wrong thing, built well, with everyone proud of the craft.

That's the bill discovery exists to keep you from paying.

What discovery actually is

Discovery is the cheap version of the expensive mistake you're about to make.

You spend a little to learn before you spend a lot to build. You put the smallest possible thing in front of a real person and watch what happens, so you're not guessing your way through a six-month build and calling the post-mortem "learnings."

The whole job underneath it is one line. Solving problems for your users. Nothing more, nothing less. Discovery is how you find out which problem is real, who actually has it, and whether your idea touches it at all, before you've bet the quarter on the answer.

And it runs on one rule. You go look. You run the small thing, and you let what real people actually do pick your next move, instead of letting the loudest opinion in the room pick it for you. There's a name for that, empiricism, but the name doesn't matter. The going-and-looking is the whole game.

"We don't have time for research"

I've heard this one more times than I can count. It's the reflex. Discovery shows up, and someone says we don't have time, we already know what to build, let's just go.

It's almost never a time problem. It's a perception-of-time problem. And underneath that perception are usually two real causes, both fixable.

The first: there's no system for research. So the first time a team does it, they're building the system at the same time they're doing the work. They're figuring out who to talk to, what to ask, where to write it down, and how to make a call, all while the clock is running. Of course it feels slow. You're paying the setup cost and the work cost at the same time. That's not research being slow. That's research being new. Build the system once, and the next round is a fraction of the time.

The second: the team is overcomplicating it. This is the one I run into most. People take an academic approach, trying to validate every last thing because "the research has to be done right," running every step exactly the way they learned it in a class or a workshop or a book. Most of the time, that's unnecessary. It's usually the tell of someone who knows the steps but doesn't really understand the research, so they can't tell which steps matter here and which ones they could drop. Take the Design Sprint. It's written as a five-day process, and teams treat the five days as the rule. But it's been run well in three days, or two, trimmed to fit the question in front of them, by people who understood what each part was actually for. Done by the book without that judgment, research drags and teaches you little, and then it gets blamed for being slow. The research wasn't the problem. The craft was.

That's most of this section. The system, and the craft. Get both right and "we don't have time" stops being true.

Getting started beats being right

There's no perfect first answer waiting for you to think hard enough to find it. It doesn't exist. The first version is wrong, the second is less wrong, and you only get to the second by shipping the first to someone real.

So the posture here isn't "get it right." It's "get started." Run the small thing, learn, adjust, run it again.

There's a line I borrow from futurist Jim Carroll. Think big, start small, scale fast. Have the giant ambition, then make your first move small enough to test this week. The ambition is free. The learning is what costs, so you buy it in the cheapest chunks you can.

What does embarrassingly small look like? A landing page for a product that doesn't exist, to see if anyone clicks. A signup form behind a button you haven't built yet. One real customer you walk through the thing by hand, instead of writing the software to do it. I'll show you more of these, and what happens when you skip them, later in this section. The short version. Limited scope wins, and scope creep is what kills the good idea. We'll take that one apart in full when we get to the experiment itself.

What's in this section

This is the craft that sits underneath your opportunity backlog, the ranked list of real user problems worth solving that you built in Part 04. That same part gave you the loop, the six steps you run to take one of those problems from "someone mentioned it" to "validated and ready to build." If you skipped straight here, you don't need all six in your head. You need this. Discovery is the work inside that loop where you go figure out what's actually true. This section is how you run the hard parts of it well.

A few of these will fight your instincts. You'll learn to trust what a customer has already done over what they tell you they'll do, because past behavior beats stated intention every time. You'll learn to talk to people so you hear the truth instead of a compliment, which is harder than it sounds when you're proud of the thing. And you'll learn to define the smallest experiment that teaches you something, instead of a small product you're then stuck maintaining for years.

The rest fills in around those. Where the discovery mindset came from and how to keep it a habit instead of a phase you finish and forget. How to turn a wall of messy notes into one clear insight. How to find the riskiest assumption your idea is riding on and test that one first. How to pick the one segment worth serving before you try to serve the world. The nav on the side lists every page. Take them in order, or jump to the one you came for.

Each is a skill. Together they're the difference between learning cheap and failing expensive.

When you need the actual recipe for a given exercise, the named tools and how to run them step by step live in the Toolbox, which is Part 06 of this playbook. This section is the why and the when. The Toolbox is the how.

You don't have to read it in order. If you came here for one specific skill, go straight to it. But if you're here because something you built well turned out to be the wrong thing, start at the top. That's the bill we're here to stop paying.