The Customer Problem Isn’t That Deep
hear me out...
I think we often exaggerate the problem we think the customer has, and that leads us to exaggerate the solution we build for them.
A founder might say, “Our product helps creators save time, save money, organise their workflow, collaborate better, automate repetitive tasks, improve productivity and manage their business from one place.” In theory, that sounds impressive. It also sounds like a lot. Somewhere underneath all of that, the customer might simply be saying, “I need an easier way to plan my content.”
One of the easiest mistakes to make when building a product is confusing a problem that logically exists with a problem people care enough about to solve.
There are probably hundreds of things in my life that could technically be easier. That does not mean I am actively looking for software to fix all of them, and it definitely does not mean I am willing to change my behaviour, learn a new product, move my data, convince my team and pay every month to make them slightly easier.
We spend so much time around a product that eventually everything it can do starts sounding important and we start finding reasons why customers should want it. A product that originally solved one clear problem slowly becomes a system for doing nine adjacent things.
Meanwhile, the customer who usually arrives with a much simpler problem, like needing to send €200 to their mother is wondering why sending €200 has become more complicated than it needs to be.
More capability does not always mean more value. Sometimes it just means you have built more things.
Product Marketing should be one of the functions willing to ask whether we are genuinely solving a larger customer problem or simply describing the problem in a larger way because the product itself has become larger. Are all of these things actually reasons someone would choose the product, or are they simply things the product can do?
Is simplicity the same as sameness?
There is an obvious weakness in this argument if you take it too far. If every money-transfer product simply says, “We help you send money home,” why would anyone choose one over another? If every project-management platform simply helps teams track tasks, why should a customer choose one specific product?
I think about this through primary solutions and secondary value.
If I want to send money home, that is the primary problem. One product might let me do it cheaper, another might do it faster, another might give me a better exchange rate, another might make the recipient experience easier, and another might simply have an interface I understand immediately. Those are meaningful differences, but the primary problem has not changed. You are still helping me send money home. The differentiation sits around the quality, speed, experience, price, trust or convenience of solving that problem.
That is very different from saying, “People want to send money home, so let’s also build budgeting, crypto, insurance, investment tools and six other things,” especially when the money-transfer experience itself is still mediocre. Those extra features might eventually make strategic sense. A company can absolutely expand its product, build an ecosystem around it and create more reasons for customers to stay. The order in which we do it matters.
If the customer came to send money and your money-transfer experience is still mediocre, giving them six other things to do does not make the original experience better.
The way I think about it comes down to three things.
1. Solve the hero problem first
Most products need what I would call a hero problem: the problem you want to be ridiculously good at solving. It should be the thing a customer can explain to another person in one sentence, the thing that makes them open the product and the thing they would immediately notice if you stopped solving it well.
If someone comes to you because they want to send money home, be ridiculously good at helping them send money home. If they come because they want to know what their team is working on, make that ridiculously easy.
You can absolutely build an ecosystem around that problem. In fact, some of the strongest companies do exactly that. But the ecosystem works because there is something strong at the centre.
Startups sometimes get ahead of themselves. They want the moat, multiple use cases, expansion revenue, a platform story, five personas and twelve industries before they have become truly excellent at the original thing. All of those ambitions can be reasonable, but complexity has to be earned. You earn it by first making something simple incredibly valuable.
2. Challenge the exaggeration
This is one of the responsibilities Product Marketing can easily lose. We are often brought into a company and handed a story: here is the customer, here is the problem, here is why the problem is urgent, here is why our product solves it. Now go write the messaging.
Product Marketing should not simply inherit that story. We should interrogate it.
Is this actually a painful problem? How often does it happen? What do customers do today instead? Does that workaround bother them enough to change? When customers say they want something, what happens when we ask them to pay for it? Which parts of our value proposition do they mention without being prompted, and which parts sound impressive internally but barely register externally?
We also need to be honest about the kind of problem we are solving. Not every product is a painkiller. Some are vitamins. Some solve emotional problems. Some solve convenience problems. Some make an existing process slightly nicer. That does not automatically make them bad products, and we do not need to pretend every product is saving enormous amounts of time, money or operational pain to make it valuable.
Sometimes the product just makes something easier. That can be enough.
A useful question to ask is: are we making the customer’s problem sound more complicated because it makes our solution sound more important?
That question can be uncomfortable, especially when the product already exists and a lot of people are emotionally or financially invested in the current story. But it can also save a company years of building and marketing around the wrong assumption.
3. Focus on the language customers actually use
One thing I keep coming back to is how ordinary customer problems sound when customers describe them themselves.
They rarely speak like our positioning documents. A customer probably is not going to say, “I need an end-to-end workflow orchestration solution that improves cross-functional visibility and drives operational efficiency.” They are much more likely to say, “I just want to know what everyone is working on.”
That sentence is already incredibly useful. From there, you can investigate what they need to see, when they need to see it, who needs access, what happens when they do not have that visibility, what they use today, why the current solution is failing them and how important solving this problem actually is to them.
The research and thinking underneath the problem can be extremely sophisticated without the problem itself becoming complicated.
We sometimes confuse doing sophisticated work with arriving at a sophisticated-sounding answer. A Product Marketer can do weeks of customer interviews, competitive research and analysis and still arrive at a simple sentence: “I just want to know what everyone is working on.”
And that is evidence that you did the work properly.
Summary: Maybe the job is to simplify relentlessly
The longer I work in Product Marketing, the more I find myself wanting to remove things: assumptions, inflated language, unnecessary features from the centre of the story, problems customers do not care enough about and the temptation to make every product sound transformational when being genuinely useful would be enough.
I want to be able to look at a product and ask: What is the main thing this customer is trying to get done? Can we solve that extremely well? And once we can, what can we build around it that makes our way of solving it meaningfully better than the alternatives?
That is the order that matters.
Ridiculously simplify the problem. Ridiculously simplify the solution. Solve it all the way through. Then expand.
We do not always need to find a bigger problem to build a better product. We just need to understand the simple problem more deeply than everyone else does.