03 Messaging & Positioning
What Problem Are You
Actually Solving?
People buy problems solved, not product complexity.
The problem-first messaging chain
Problem
The specific pain the customer experiences
Value
What changes when the problem is solved
Explanation
Messaging built around the problem, not the product
Trust
Recognition — 'they understand what I'm dealing with'
Customers don't buy products. They buy relief from problems. Messaging built around the problem creates recognition. Messaging built around the product creates confusion.
Why this matters
Weak messaging almost always begins when companies explain technology instead of customer problems.
When founders build a product, they live with the technology. The architecture decisions, the feature set, the technical differentiation — these are the things that occupied months of thinking and building. It is completely natural to explain the product through those things.
The customer hasn't lived with the technology. They've lived with a problem. An operational frustration, a risk they can't quantify, a process that takes longer than it should, a decision they have to make without enough information. What they're looking for is relief from that specific experience — and they'll buy from whoever demonstrates they understand it most clearly.
The gap between product-centric messaging and problem-centric messaging is the gap between explaining what a product does and explaining what a customer gets. The first requires the customer to do the translation themselves. The second does the translation for them. Most customers won't do the translation. They'll move on.
Founder reality
Find the real problem before building the messaging:
What do customers say when asked what their life was like before finding the product — and does that language appear anywhere in the current messaging?
When a customer refers the product to a colleague, how do they describe it — in terms of the product's features or in terms of the problem it solved for them?
What specific frustration, risk, or inefficiency does the product remove — and is that stated in the first sentence of the homepage?
Are there multiple customer segments using the product for different reasons — and does the messaging reflect the most important one or try to cover all of them?
What would a satisfied customer say the product has changed about their work or their world — and is that outcome the focus of the current explanation?
The customer referral description is the most reliable indicator of what problem the product actually solves in customers' minds. It's usually significantly simpler and more human than any internally-generated problem statement.
The system
Four steps from product explanation to problem explanation
Apply in sequence. Each step moves the explanation closer to the customer's experience.
01
Problem identification — what specific experience does the product resolve
Start with customer interviews, support tickets, and sales call recordings. Look for the language customers use to describe the situation before finding the product: the frustration, the inefficiency, the risk, the decision-making difficulty. This language is the raw material of problem-centric messaging. Internal team language about the product is not.
02
Problem hierarchy — the most important problem, not all of them
Products often solve multiple problems for multiple customer types. Problem-centric messaging requires choosing a hierarchy: which problem is most important to the most valuable customer segment. Messaging that tries to cover all problems for all segments covers nothing deeply enough to create resonance. One problem, stated clearly, for the right audience.
03
Before-and-after framing — what changes when the problem is solved
The most effective problem-centric messaging describes the contrast between the before-state and the after-state. Not the product that produces the change — the change itself. 'Before: your team spends 3 hours per week manually reconciling deployment logs. After: the problem surfaces automatically, in real time, before it becomes an incident.' The product is implicit. The value is explicit.
04
Language adoption — using the customer's words, not the team's
Customer language is almost always simpler, more specific, and more emotionally resonant than internally-generated language. 'We help engineering teams achieve infrastructure observability' (internal language). 'We help you know when something is wrong before your customers do' (customer language). The test: would the customer say this sentence to describe their own problem? If yes, it's customer language. If no, it's product language.
Common mistakes
01
Describing the solution before the problem
Messaging that leads with what the product does assumes the customer already understands why they need it. Most customers haven't made that connection yet. Lead with the problem. Let the product be the obvious answer to a question the customer already has.
02
Generating problem statements internally rather than from customers
Problem statements written by the team reflect the team's understanding of the customer's experience — which is almost always less accurate than the customer's own description. Interview first. Write second.
03
Listing every problem the product solves
A problem list is not a problem statement. Every additional problem listed dilutes the clarity of the primary one. The primary problem should be unmissable in the messaging. Secondary problems can be addressed later in the explanation.
04
Using a pain point the customer doesn't recognise as theirs
Sometimes the problem the team believes the product solves is not the problem customers experience it as solving. When the pain point in the messaging doesn't produce recognition in the target audience, it may be a real problem but not the customer's most urgent one. The problem that resonates is the problem the customer is already trying to solve.
Example scenario
A cybersecurity company. Product: detects insider threat patterns in cloud infrastructure. Messaging: 'Advanced behavioural analytics for enterprise security teams'. Conversion: low. Sales: founder-dependent.
The problem discovery
8 customer interviews conducted. Question: 'What were you trying to solve when you found us?'
Common theme across 6 of 8: 'We had an incident and didn't know about it until a customer told us. We needed to know earlier.'
Not one customer mentioned 'behavioural analytics'. All mentioned some version of 'knowing before it's too late'.
The problem in customer language: 'Security incidents you find out about from customers, not your own systems.'
The messaging redesign
Homepage hero rewritten: 'Know about security incidents before your customers do.'
Product description rewritten: before-and-after format. Before: reactive, customer-reported. After: proactive, system-detected.
Sales materials: problem-first structure. Customer language throughout.
The outcome
First sales call post-redesign: prospect opened with 'That headline — that's exactly what happened to us last quarter.' Sales cycle: shortened by 3 weeks in the following cohort. The product hadn't changed. The problem statement had changed from the team's description to the customer's description. The difference was total recognition versus mild interest.
Takeaway
Lead with the problem. Let the product be the answer.
Find the problem in customer language. Choose the primary one. Frame the before and after. Use their words. The customer who reads their own problem in your messaging has already started trusting you.
Related thinking
Messaging & Positioning
Messaging Before Marketing
Good messaging makes marketing easier.
Messaging & Positioning
Founder Language vs Marketing Language
Founders often explain differently than customers understand.
Messaging & Positioning
Positioning Without Buzzwords
Clarity beats clever language.
Continue reading
Why Technical Products Feel Hard To Explain