Don’t Validate Solutions, Disconfirm Needs
My favorite professor in graduate school once said (I’m paraphrasing): “Whenever you analyze data and are happy with the results, dig deeper until you’re no longer happy — then you’re probably actually right”. Coming from this intellectual tradition, the number of people who walk around every day, happy with their thoughts and ideas, is appalling. In the context of product design, the same is true of the number of products that sound great on paper but don’t actually do anything.
I think the main reason this happens is that people spend too much time validating the fact that they’re right, rather than looking for ways that they’re wrong (i.e., the confirmation bias).
While developing products, this can take place on multiple levels. Not only is it extremely easy to cherry pick metrics that support your belief that what you want to build, or what you just built, actually works, it’s equally easy to create a culture where the purpose of thinking is simply to confirm that you’re building what you need to build.
Look, I think we all know why this happens — it’s just not cool to go to your boss, or to the CEO, or to the board and be like: “Remember this idea that I came up with last week the one that we really, really liked? Well, I was thinking more about the problem we’re actually solving… and I don’t think there is one.”
It’s much easier to just make sh*t up. And it’s easy to do that at every level: From the most minute technical detail, to your entire roadmap — all of it could be a giant fecal Jackson Pollock, if you let it happen. By doing things that look good instead of do good, you can polish that metaphorical turd to a shine. I’m talking about the cool high-fidelity prototypes, the deck you paid someone else to make, etc. You know, the stuff we do to get “buy in”.
To be clear: I don’t think this is a conscious act of deception (or self-deception, if you will). I don’t think people wake up and think: “You know what? I’m going to go to work today and make decisions that will blow up on me in the next six months”. I just think that most people are wired to be happy most of the time, and their brains have a friendly but ultimately unhelpful way of finding ways to see the present moment as rosy, while being oblivious to the potential sh*tshow that is months away.
Needless to say, there are consequences to this. The first week you sub-consciously choose metrics that look good, things will probably be fine. But the nice thing (for someone like me) about working in industry, and in tech in particular, is that the truth has a nasty way of catching up to you. At the end of the day, only two metrics matter: How much money you’re making, and how many people are using your product. And a few months down the road, when everything is swirling down the toilet, it’s going to be harder and harder to fool yourself into thinking that it’s all going according to plan.
I, who will regularly eat ice cream for breakfast, do not claim to be a bastion of good decision making. However, I think one helpful principle, is, at every level, to set yourself up to disconfirm needs, not confirm solutions.
To demonstrate what I’m talking about, let’s look at an example for a cooking app:
In this small example, I’ve decided that I want to build an app to store recipes, and have listed why, as well as a set of needs that users using the app would have. If you were to actually build this, you’d obviously have more depth and detail.
There are two things to note here:
First, presented in this manner, solutions become subservient to problems. The only reason something is being done is because it’s needed to solve a problem that needs to be solved.
Most importantly, however, this way of thinking ensures that problems are easily disconfirmed. Specifically, in this example, everything is only worth doing because “People need an easy way to figure out what to cook, and how.”
As someone who doesn’t cook, I don’t know if this is true (although I don’t think “figuring out what to cook, and how” will entice me to whip out the pots and pans). However, by formulating your thoughts this way, you inoculate (at least partially) yourself to your own bullsh*t: Solutions can be made to look sexy; problems are either important and worth solving, or not.
I say “partially” because I think human beings are amazing at deceiving ourselves. Someone might read “People need an easy way to figure out what to cook, and how”, and believe it’s the biggest problem in the world. Or they might justify pursuing it by qualifying with: “It’s a problem for some people.”
However, I also believe that by communicating the problem you’re solving rather than the solution you have, you make it easier for others to communicate why they think your idea is bad — for instance, they might agree that some people face that problem, but that the market is too small to justify going after. That way, you might save yourself the trouble of developing the next Pono Player.
So, what’s the point of doing all of this?
- Do this regularly enough, and you’ll be able to quickly contextualize any decision — know why it needs to be discussed, know how important it is, as well as who or what it might potentially impact. You’ll be able to make decisions more easily because you’ll know what you need to think about.
- You’ll be able to spend less time being frustrated over being lost in a cacophony of decisions-to-be-made, and instead be able to spend that effort actually making good decisions on things that matter. You’ll have to make fewer decisions, because you’ll know which ones matter.
- You’ll also be much more motivated to ensure that whatever you’re doing actually solves a concrete problem that, without any further information, at least sounds important, and with more research, is of verifiable importance. You’ll be able to make better decisions, because you’ll know when you’re wrong.