At work, I’ve been reading the Basecamp book Getting Real, I just read this blog post by Paul Graham on solving the right problem, and I also read this memo from a turbulent period in Yahoo!’s history. And all three are the same thing. Design thinking.

Several years ago, I took a course at Stanford’s graduate school of business (how do you know that I have taken a course at Stanford’s graduate school of business? talk to me for 10 minutes) called The Emerging COO. A core principal, truly a third of the curriculum, is design thinking.

Design thinking in this context is a process that encourages knowing the problem deeply, testing the lowest lift version of the possible solution against real humans to get it to break, and iterating extremely fast. The five phases are: empathy (you need to truly understand the person you’re solving for and their specific gap, and this means you talk to the customer), define (actually write out the problem, and get it down to the tightest scope that still works), ideate (don’t think your first idea is the right one, go through as many as possible; the crazier, the better), prototype (make the simplest version of your solution; draw it on paper, build it from legos), test (put it in real people’s hands and see what’s right/wrong with it). Then you have to run through that process as fast as you can; sometimes you go from Test back to Empathy when you realize you didn’t actually understand the problem, but you most often are cycling between Ideate > Prototype > Test.

Design thinking is so powerful because it’s fast, it’s cheap, and it’s remarkably effective. Literally anyone can do it, at any time. It works best, however, in small groups. A large team trying to do this is going to get stuck at every phase, because of Brooks’s law re: communication in a group (for each person added to a group, the amount of potential miscommunication increases quadratically). One of the themes revisited in the Basecamp book is this idea of leaning into constraints. The design thinking process fits perfectly into this — it doesn’t need any money, only a few people, and is the fastest way to put things in front of real people. The way it was described in my class (did I mention that I took a course at Stanford? Oh I did?) is you’re trying to fail as fast as possible, because you want to spend as little time and energy as possible on an idea that will fail.

I think it’s worth thinking, too, about the part that comes after a successful Test. It’s Empathy. You still need to be talking to the people whose problem you’re trying to solve, and keep listening to them. In a design thinking environment, you’re empowered to listen and then rapidly solve the edge problems that come up, which keeps your customers loyal and keeps building trust, and also makes your product more useful and functional.

So the common thread I’m seeing pop up over and over is to lean into constraints, because it’s possible to get to the right solution extremely quickly and cheaply, but only if you care deeply about your customer.