Building

Build Around the Problem, Not the Solution

Build Around the Problem, Not the Solution

Your product should be built around the problem you want to solve, never the solution. The problem is your north star. The solution can, and usually will, change.

When you create a product, start from the problem, and build the product around the solution to that problem. But be careful with that sentence, because the important half is often missed. The product must always be built around the experience you want to change, which is to say around the problem. The product's north star, the star you steer by, must always be what you set out to solve, not how you solve it. The solution can change. The problem should not.

Let me use the clearest example there is. Uber. When Uber was founded, people already knew they needed a faster way to get around by taxi. They wanted that experience. Their desire, their instinct, their intuition said so. They wanted the experience, they just did not have the structure to make it happen. And someone came along and gave them the structure, through an app suited to the context of the time. So they said yes. Because having that thing, that product, that platform, carried all the principles and rules of operation that people wanted to experience. It solved a big problem of theirs, the problem of time.

Now notice what Uber did with its solution. At the start, Uber was a luxury taxi service. Then they realized it could become something far more useful to people. The solution shifted, but the problem they solved stayed exactly the same, time, the lack of time, and efficiency from that point of view. That is the whole lesson in one company. Concentrating on the problem let them change the solution freely, and changing the solution is exactly what made them enormous. If they had married the solution, luxury taxis, they would have been trapped. Because they married the problem, they were free to pivot the how while keeping the why.

This is why building around the solution is a trap. If you fixate on the solution, you will get stuck, because the solution you first imagined may not be the best one for changing the experience you want to change and replacing it with a new one. Focus on the problem, and the solution becomes something you are allowed to iterate. Focus on the solution, and you will defend it long after the market has told you to change it.

The reason founders marry the solution instead of the problem is that the solution is the fun part. The solution is the clever app, the elegant design, the thing you are proud of building. The problem is boring by comparison, it is just someone's frustration. So we fall in love with our answer and forget the question, and then when the market rejects the answer, we take it personally and defend it, because it is ours. But the market never cared about your answer. It cared about its problem. The moment you can hold your solution loosely, as one disposable attempt at the problem rather than a piece of your identity, you become able to change it as fast as the feedback demands, which is the only way to survive.

There is a subtler version of this, and it is worth understanding, because it is where some of the biggest things come from. Sometimes a product solves a problem people are not even aware they have. It is genuinely interesting when it happens, when you build something that solves a problem people do not consciously know they have. But in general it is fair to say they do have it, even if they are not conscious of it. In one way or another, they want to create or feel that experience. Uber again: people knew, somewhere, that they wanted a faster way to move. It was latent, but it was there.

And sometimes it is not even a problem in the strict sense, but a shortcoming, a gap in an experience people want to change. Take SpaceX and the rocket industry. SpaceX created something that maybe was not a problem for humanity, or maybe humanity could not see it as one. Maybe it was a problem, but for many people it was not. And yet many were drawn to it, because it addressed a shortcoming, the human desire to explore, to expand. We are beings who expand. So even when there is no obvious problem, there is often a shortcoming in an experience, a latent desire, and a product can be built around that just as it is built around a problem. The north star, again, is the thing you are trying to change in people's experience, not the particular machine you first imagine to do it.

So how do you find the people who have the problem, especially the ones who feel it most sharply? You know your product cold, what it is, what it offers, and then you go into the communities that discuss that thing, and discuss it in the most dedicated, most passionate way. Start with the passionate ones, then move to the less passionate, because there is a funnel here. Picture an axis from zero, the point where a customer is not interested at all in your product but could be, up to ten, the point of purchase, with seven being the point where the customer is very interested but needs a bit more information to feel comfortable buying. You want to target the people at seven first. Ideally nine, but you will find those harder, so you contact the sevens, because you know you will spend far less effort convincing them. And you look for them where people talk passionately about the thing. If you sell a collar for animals, you go to a Reddit thread where that collar is discussed extensively. Or you go where the need is greatest.

The funnel insight saves you from the most common early mistake, which is trying to convince the zeros. Founders love the challenge of converting a skeptic, of taking someone with no interest and winning them over, because it feels like proof the product is good. But converting a zero costs enormous energy for one sale, and at the start you do not have that energy to spare. The sevens and nines are already most of the way there. They feel the problem, they want the experience, they just need a little information and a little comfort. Spending your scarce early energy on the people who are almost sold, rather than the people who are not sold at all, is not lowering your ambition. It is refusing to waste yourself proving a point.

That last point matters, because people forget it. The greatest need is not always online. It might be offline. You might make a deal with animal shelters, because that is where many people come to get animals, and your product becomes a kind of upsell. People adopt an animal, and the owner asks whether they would also like a collar for it, and you know those people would be interested, because that is where the need is. People search everywhere online because it is easier and they know it scales, and yes, online is scalable, but to gather your first real information about the market, you can go offline, make partnerships in places where you know your potential customers sit at point seven of the funnel, and with each sale run a tiny study, two or three questions asked after they buy, not before. That gives you data that later tells you exactly whom to target in similar communities online.

Notice the sequence there, because it is smarter than pure online scaling. You go offline first, not because offline is better, but because offline is where you can talk to people directly and learn. Each offline sale comes with a two- or three-question study, asked after the purchase, when the person is relaxed and honest, and those answers teach you who your customer actually is. Then you take that hard-won understanding back online, where it scales, and you target the right communities with the right message because you learned it from real humans first. The founders who skip the offline learning and go straight to online scale are scaling a guess. The ones who learn offline first are scaling knowledge.

Which brings me to the habit that keeps the whole thing honest, staying close to the customer. There is a moment when a product's life cycle ends, and your customers will usually tell you, if you are listening. Ideally you can even predict it, sense where the market is heading, and instead of clinging to the old thing, build alongside it, a new product or a new version. Maybe you will need to solve a different problem, or maybe you already solved this one and it is no longer needed. You will only know if you stay informed and stay close to the people who buy from you, and by close I mean you talk to them directly, not through intermediaries, not through surveys, not through statistics you pulled off a site. You, personally, understanding their nature, their state, their needs.

So the discipline is a loop anchored to a problem. Define the problem, or the shortcoming, or the latent desire, and make it your north star. Build a solution around it, cheaply, and treat the solution as disposable, something you will iterate or replace as you learn. Go find the people who feel the problem most, the sevens and nines, in the communities and places where the need is sharpest, online or off. Sell to them, ask them a couple of questions afterward, and let their answers tell you where to go next. And when the market shifts, change the solution without hesitation, because you were never attached to it, only to the problem.

There is a diagnostic you can run on yourself to check whether you are married to the problem or the solution, and it is simple. Imagine someone shows you a completely different way to solve the same problem, one that makes your current approach obsolete. If your first reaction is excitement, you are anchored to the problem, and you are safe, because you will happily trade a worse solution for a better one. If your first reaction is defensiveness, a search for reasons the new way is inferior, you are anchored to the solution, and you are in danger, because you will defend your approach past the point where the market has moved on. The emotion you feel in that thought experiment tells you which star you are actually steering by.

The same logic explains why solving a problem people are not yet aware of works at all. You are not inventing a desire, you are giving structure to one that already exists in latent form. People wanted faster movement long before Uber, they wanted to explore long before rockets. The desire was there, waiting, without a vehicle. When you build around that latent problem, adoption feels almost effortless, because you are not convincing anyone to want something new, you are handing them the structure for something they already wanted and could not reach. That is the difference between pushing a product uphill and releasing one downhill, and it comes entirely from having anchored to the real underlying desire rather than to your clever expression of it.

Build around the problem, not the solution. The problem is the star you steer by. The solution is just the boat you happen to be in, and you should always be willing to trade the boat for a faster one, as long as you keep sailing toward the same star.

← Back to the articles

Newsletter

What we shipped, what broke,
and what we learned