Design Thinking & Experimentation

Every product you've ever shipped started as a guess. Someone decided what to build, the team built it, and only after launch did anyone find out whether real people wanted it.

Sometimes that guess pays off. It happens. Plenty of products shipped on pure instinct and won. But that's a bet with the odds against you, and the odds don't have to be against you. The whole job of discovery is to move that "find out" earlier, before the money's spent. It doesn't guarantee you a winner. It makes one a lot more likely, because now you're building on evidence instead of hope. Design thinking is the method for doing it.

Here's the simplest definition. Design thinking is a problem-solving methodology. That's it. It's a mindset and a method, built on empathy, experimentation, and iteration. The mindset says you start with the person who has the problem, not the solution you're excited about. The method gives you a repeatable way to get from "we think there's a problem here" to "we know what's worth building."

It's not linear. You don't march through it once and graduate. It's cyclical. You learn something, it sends you back a step, you go forward again. That feels messy the first time you do it. It's supposed to.

Yes, it can be sticky-note theater

Let me name the eye-roll, because I know some of you are already doing it.

You've sat in the workshop. A facilitator, a wall of sticky notes, everyone votes with little colored dots, somebody takes a photo for the company newsletter, and three weeks later nothing has changed. If that's what "design thinking" means to you, I get it. I've sat in that room too.

And here's the part most people defending design thinking won't admit: sometimes it really is theater. The activities can be exactly that, a fun afternoon that makes everyone feel creative and produces a wall of paper nobody reads again.

So whether it's theater or not doesn't come down to the sticky notes. It comes down to what you do after.

Did the workshop change what you build next? Did one of those clustered notes turn into an interview you actually ran, an experiment you actually scoped, a problem you decided to chase or kill? Or did the photo go in the newsletter and the team go back to building exactly what it was already going to build?

That's the only question that matters. The exercise is never the point. Acting on what the exercise surfaced is the point. A wall of sticky notes you do nothing with is theater. The same wall, used to decide your next move, is discovery.

The five phases

The lineage here runs through the design firm IDEO and Stanford's design school, which everyone calls the d.school. They popularized the five phases, and they're worth knowing by name: empathize, define, ideate, prototype, test.

Empathize: sit with the people who have the problem until you actually understand it from their side.

Define: pin down what the problem actually is, in their terms, not yours.

Ideate: generate options. Lots of them, before you fall in love with one.

Prototype: build something small enough to put in front of someone this week. A sketch, a clickable mockup, a fake landing page. Not the real thing, just enough of it to react to.

Test: put it in front of real people and watch what they do, not what they say they'd do.

And remember it's cyclical, not a one-way street. A test sends you back to redefine the problem. A prototype sparks an idea you didn't have when you started. You're not failing when it loops. The loop is the method working.

I teach this in a couple of courses at the University of Illinois, through the Siebel Center for Design, and I'll pull a few moments from those classrooms through this page, because students hit the same walls you will.

If you don't know it, the Siebel Center for Design is worth a look. It opened in 2021, built on a $25 million gift from Thomas Siebel, an Illinois alum who founded Siebel Systems and later C3.ai. Its whole mission is to make design accessible to everyone, not just designers, and it's open to students from any major with no design background required. The idea it's built on is the same one this page is built on. You design with people, not for them. It exists to push human-centered design out into the world one student at a time, whatever they go on to do for a living.

But don't file design thinking under "academic exercise." I'm convinced it's the single most useful problem-solving tool any person can carry into any job, on any problem. The classroom is just where I get to watch it click.

Don't assume you're the user

Empathy is what keeps you from designing for the wrong person. And sometimes the wrong person is you.

Not always. Sometimes you've lived the exact problem you're solving, and that's a real advantage. But you can't assume it. The fastest way to build the wrong thing is to design from your own feelings without ever checking whether they're actually your user's.

One of the groups in my Illinois class wanted to build something to help people feel safer walking home alone at night. Good problem. So I used myself to show them what empathy actually asks of you.

I'm 6'4", 300 pounds, built like a linebacker. When I walk home at night, nobody I pass is thinking "let me go mess with that guy." They'd pick someone smaller. So the fear this whole project is about is barely on my radar. It isn't my emotion. If I were on that team and built from my own gut, I'd get it completely wrong, because my gut was calibrated by a life that mostly doesn't carry that fear.

So my first move couldn't be to sketch a solution. It would have to be to go talk to a lot of people who actually live with that fear, and learn the emotion from them instead of inventing it from myself. That's the whole point. Figure out whether you're the user. And when you're not, go get the real feelings from the people who are.

Empathy is where it lives or dies

If you skip one phase, you'll skip empathize. It feels the softest, the least like real work, the easiest to assume you already did. And it's the one that decides everything downstream.

There's a TED talk by Doug Dietz I point students to. He designed MRI machines, and they were technically excellent, until he watched a terrified child get sedated just to make it through a scan. An MRI is a loud, narrow tube you have to lie dead still inside, and to a kid it looks like a machine that's going to swallow them. The machine worked. The experience was a nightmare for the person inside it. He'd never have learned that from a spec sheet. He learned it by watching a real person meet his product. That gap between "the thing works" and "the thing works for this human" is exactly what empathy closes.

Let me give you one from my own classroom. I had a student group researching how students engage with campus healthcare. They went in assuming the problem was something like wait times or scheduling. What they found surprised them. Most students didn't know the campus health service existed. Didn't know they had insurance through the university. Didn't know what they could even do with it.

Here's why it surprised this particular group. Their own parents had sat them down in high school and walked them through all of it, how insurance works, when to see a doctor, why you go to the dentist before something hurts. They showed up to the project assuming everyone arrived at college knowing those things, because they did. The research broke that assumption. The gap they'd never have guessed from their own experience was the whole problem.

That's empathy doing its job. Not "imagine how the user feels." Actual research that kills an assumption you didn't even know you were carrying. The students walked in to fix scheduling and walked out understanding the real problem was awareness. That redefinition only happens if you sit with the people who have the problem instead of the version of them in your head.

Dig below the surface

The trap in empathize is stopping at the first answer. People hand you the surface, and the surface is almost never the real thing.

I run an exercise with students on improving campus life. Early on, a group will say students are lonely, so let's build something for loneliness. Good instinct. Now dig.

What is loneliness, here, for this person? Is it that they don't know anyone? Or that they know people but never see them? Or that they see people constantly and still feel like nobody actually knows them? Those are three completely different problems wearing the same word, and they lead to three completely different solutions. Build for the wrong one and you've solved a problem nobody had.

The word "lonely" is the start of the conversation, not the end of it. Most teams treat it as the end, because the end is comfortable and the digging is awkward. Stay in the awkward part longer than feels natural. That's where the real problem is hiding.

The frame I keep coming back to is from the show Ted Lasso: be curious, not judgmental. When someone does something that makes no sense to you, the judgmental move is to decide they're wrong. The curious move is to ask why, and actually want the answer. In discovery, curious beats judgmental every single time, because the thing you'd have judged as irrational is usually a clue to a problem you didn't know existed.

Four lenses on every idea: DFVE

Empathy tells you the problem is real. Before you commit to a solution, you need a second filter. Is this thing worth building at all?

If you've been through the Opportunity Backlog, you've already met these four lenses, so I won't make you re-read it. Here's the quick refresher in case this is where you're starting. I run every idea through four lenses. Desirability, Feasibility, Viability, Ethicality. DFVE. The acronym isn't decoration. It's how I force myself to ask all four when an idea is exciting and I'm tempted to skip the unglamorous ones.

Desirability: does anyone actually want this? If no one wants it, you're dead in the water before you start.

Feasibility: can you actually build it, with the technology and the people you have, in the time you have? Wanting it doesn't make it buildable.

I've watched this one up close with voice assistants. More than once, leadership at a company I worked for wanted a voice assistant built into an app I managed. People liked the idea. The trouble was never desire. It was whether the thing could actually be built into something that worked and was worth the cost. The whole industry learned that lesson the expensive way. Amazon's Alexa group reportedly lost around $10 billion in 2022. Alexa was handling a billion interactions a week, and most of them were people setting timers and playing music, the kind of request Amazon could never turn into a business. A former employee called it "a colossal failure of imagination." In early 2024, Google quietly cut 17 Assistant features it labeled underutilized and let go of the teams behind them. People genuinely wanted voice to be the next big interface. It mostly couldn't be built into something that both worked and paid for itself. Desirability was never the problem. Feasibility was.

Viability: can you make money doing it, or at least sustain it? And money isn't always money. If you're running a volunteer program, your currency might be people's time. Either way, if nothing comes back in, it can't keep going.

Ethicality: should this thing exist at all? Not "can we get away with it legally," that's a different and lower bar. Should we build it, knowing what it might do to people five or ten years out.

That fourth lens, the E, isn't in the classic model. The original is the three from IDEO, desirability, feasibility, viability, drawn as three overlapping circles, with the idea worth building sitting where all three overlap. I picked up the ethical lens from an article years ago and added it to how I teach and how I work, because the cost of ignoring it has gotten too high to leave it out. It's not mine. Plenty of people in design and entrepreneurship use it now.

Here's the example that sold me. The like button passed desirability, feasibility, and viability with flying colors. People wanted it, it was easy to build, and it made the platforms a fortune by juicing engagement. Nobody asked the fourth question. So it shipped, and it quietly trained a generation to check compulsively and measure their worth in other people's approval. That's the exact five-to-ten-years-out cost the E lens exists to catch. I make the deeper case for it over in Opportunity Assessment.

One thing people get wrong about the four lenses. They're not a pass-fail gate where every box has to be green. Sometimes a lens comes back weak and you run the experiment anyway, because it's a risk you're willing to take. The lenses don't make the decision for you. They make sure you know exactly which risk you're choosing. When you want to put these to work as real gates on a real backlog, that's what the Opportunity Assessment page does with them. Here, just carry the four words with you.

Be a filter, not a funnel

Once you've got a method and a set of lenses, the discipline is saying no.

A funnel takes everything in and hopes prioritization sorts it out later. Every idea, every feature request, every "wouldn't it be cool if," all of it pours in, and the team drowns trying to give a little attention to everything.

A filter says no early. It lets the few ideas worth chasing through and stops the rest at the door, on purpose, so the experiments you do run get enough attention to actually teach you something.

Three experiments that get real attention beat fifteen that get none. Be the filter. Saying no to a good idea so a great one gets oxygen is the whole job, and it's harder than it sounds, because saying no feels like leaving value on the table. It isn't. Spreading yourself across fifteen things is how you learn nothing about all fifteen.

Talk to people about their past, not your idea

All of this falls apart if you talk to customers badly. And the most natural way to talk to a customer is the worst one.

You show them your idea and ask if they like it. They say yes. People are polite, they can see the hope on your face, and now you're building on a compliment instead of the truth.

The fix has a name. It's a discipline laid out in a short book called The Mom Test, by Rob Fitzpatrick, and the core of it is this: talk about their life, not your idea. Ask about specific things they've already done, not what they think they'd do in the future. "Walk me through the last time you ran into this" beats "would you ever use something that does this." One gets you a real story you can verify. The other gets you a hypothetical, and hypotheticals are where people are most generous and least accurate.

I get deeper into the craft of the interview, the question sets, the silence, the follow-ups, on the Talking to Customers page. For now, hold onto the one rule: ask about the past, because what someone has actually done is real, and what they say they'll do is a wish.

Confidence, not correctness

Here's the mindset shift that makes the whole thing work, and it's the one people resist hardest.

There are no right answers in this work. There are only confidence levels.

I can hear the objection. "Shouldn't I get it right first? Isn't that the responsible thing, to think it all the way through before I spend anything?"

No. The 100-percent-right first answer doesn't exist, and every week you spend polishing the plan is a week of pretending it does. Discovery doesn't hand you certainty. It hands you confidence, earned one small experiment at a time. You run the cheap test, the result moves your confidence up or down, and you decide the next move from a slightly better position than before. That's the whole engine. Not "are we right," but "are we confident enough to take the next step, and what would make us more confident."

Make that concrete. Say your whole plan rides on one belief. People will pay for this. You can argue about it for a month, or you can put up a simple landing page that takes pre-orders, send a hundred of the right people to it, and watch what they do. Either the orders come in and your confidence jumps, or they don't and you just saved yourself months building the wrong thing. Same week, same cheap test, and either way you know more than the deck told you.

It's going to feel weird at first. You're used to being rewarded for having the answer, and discovery rewards you for admitting you don't have it yet and going to find out. Lean into that ambiguity instead of fighting it. The discomfort of not knowing is exactly the feeling of doing this correctly. The people who get good at design thinking are the ones who got comfortable being wrong out loud, on purpose, early, while it's still cheap to be wrong.

So start where you are. Take the riskiest assumption in whatever you're building right now, the one that quietly scares you, and go find the smallest, cheapest way to learn whether it's true. Sit with the person who has the problem. Dig past their first answer. Run the four lenses. Then run the test. The evidence picks the next move, not the deck.

That's the whole part in one move: pull the "find out" earlier, and pay for it cheap. Every page that follows is one more way to do exactly that.