Market the Problem, Sell the Solution
Lead with a buyer problem people can recognise, then show how your solution addresses it. A practical guide to B2B messaging without manufactured urgency, inflated promises or unsupported claims.
By Kunal Achintya Reddy · 7 min read · 19 October 2026
A buyer should be able to recognise their situation before they have to decode your product.
That is the useful meaning of “market the problem, sell the solution.” Lead with a real difficulty the buyer wants to resolve. Explain why it happens and what it affects. Then show how your offering addresses it, with evidence and clear limits.
It does not mean making the problem sound as frightening as possible. It does not mean publishing endless commentary about pain while keeping the product vague. And it is not a rule that every message must begin with a problem. A buyer comparing products may need the integration details immediately.
The principle is about relevance: make the reason to care clear, then make the reason to choose you credible.
Start with a situation, not a category
“An integrated platform for modern finance teams” describes a category. It does not describe a moment in the buyer's working day.
“Your team is chasing invoice approvals across email, and nobody can see which decision is holding up payment” describes a situation someone can recognise, investigate and either confirm or reject.
The second statement gives the product a job to do. It also sets a standard the product must meet. If it cannot clarify approval ownership or surface the stalled decision, the message is not a clever positioning move. It is a promise the offering cannot support.
The underlying idea has a useful foundation in Clayton Christensen and his co-authors' work on why customers buy: people “hire” products to help them make progress in particular circumstances. That is a way to understand a purchase, not proof that problem-led copy will outperform every alternative.
For a B2B marketer, the practical implication is simple. Before describing what the product is, establish what the buyer is trying to get done and what is making that difficult.
Find the problem in the buyer's language
“Low productivity,” “poor visibility” and “inefficient operations” are broad enough to fit almost any software pitch. They need to be translated into something observable.
Ask about the last time the difficulty occurred:
- What was the person trying to finish?
- Where did the work slow down or break?
- What did they do instead?
- Who else had to get involved?
- What happened as a result?
A concrete account is more useful than agreement with a leading question. “Would better visibility help?” invites an easy yes. “Walk me through the last approval that missed its deadline” gives you something to examine.
Use interviews, support conversations and buying discussions to find candidate patterns. Then check them across relevant buyers. One vivid complaint is a clue, not proof that an entire market shares the problem.
Rothenhall's article on using closed-lost conversations as buyer research explores one source of that evidence. Here, the task is narrower: turn what you learn into language buyers recognise without stretching what they said.
Keep the original wording in your research notes. If buyers describe “chasing the same approval twice,” do not automatically polish that into “cross-functional orchestration friction.” The polished version may remove the detail that made the problem real.
Explain the consequence without manufacturing urgency
A problem deserves attention because of its consequences, not because the copy sounds urgent.
There is a difference between saying:
When approval ownership is unclear, invoices can wait while finance works out who needs to act.
And saying:
Every delayed invoice is destroying your supplier relationships and putting your business at risk.
The first describes a plausible mechanism a buyer can check. The second piles on consequences without establishing that they are happening.
Make three distinctions visible in your thinking, even if they do not all appear as labels in the copy:
What you know. A buyer described a recurring delay. A documented customer example showed a particular result. A product test demonstrated a capability.
What you infer. That delay may create extra follow-up work or make payment timing harder to predict. Check whether it actually does.
What remains unknown. You do not yet know the buyer's frequency, financial impact or reason for tolerating the current approach.
If you offer a cost calculator, let buyers use their own inputs and show the assumptions. Do not turn a hypothetical estimate into a headline about what every company is losing.
Nor should you assume the consequence is always financial. Bain's research on B2B value includes factors such as time savings, reduced effort and reduced anxiety alongside economic value. That supports looking beyond a generic cost-saving claim; it does not justify assigning those benefits to your product without evidence.
A credible message can acknowledge that the problem is not urgent for everyone. If a team processes only a handful of invoices and its current approach works, a new approval system may not be worth adopting. Naming that boundary makes the offer more precise.
Make the solution answer the problem you just described
Once you have established the problem, do not switch to an unrelated list of capabilities.
Continue the same line of reasoning. If the difficulty is unclear approval ownership, show how an owner is assigned. If work gets stuck without anyone noticing, show how an overdue step becomes visible. If an audit trail is missing, show what gets recorded and what does not.
Features belong in this explanation. They are the mechanism, not the opening argument.
The following is an illustrative example, not a description of an existing product or a customer result:
| Part of the message | Example |
|---|---|
| Buyer situation | Invoice approvals move through email, and finance cannot reliably identify the next decision-maker. |
| Consequence to investigate | The team spends time chasing updates, and some approvals wait unnecessarily. |
| Solution mechanism | A shared approval queue assigns an owner to each step and flags overdue decisions. |
| Evidence to show | A walkthrough using a representative invoice, including an exception and a reassignment. |
| Limit to state | The queue cannot resolve an approval policy the company has not defined. |
Notice what is missing: a guaranteed percentage improvement, an invented customer quote and a claim that one feature transforms the whole business.
The solution becomes persuasive by answering the specific problem, not by sounding bigger than it.
Let buyers inspect the claim
“Save time” is a proposition. Showing how repeated follow-up is removed makes the proposition understandable. Evidence is what helps a buyer decide whether to believe it.
Use evidence that matches the promise:
- For a claim about a capability, show the actual workflow or relevant product documentation.
- For a claim about a customer outcome, explain the customer's starting point, what changed, the period measured and important conditions.
- For an estimate, show the calculation and identify it as an estimate.
A demonstration of an approval queue does not prove that every customer will pay suppliers faster. A result from one team does not establish an average. A testimonial about convenience does not substantiate a quantified cost reduction.
Where evidence is not available, narrow the claim. “See which approval is waiting and who owns it” is a more defensible promise than “eliminate payment delays” if visibility is what the product actually provides.
This is where “sell the solution” earns its place. Buyers need to understand not only that the problem matters, but why this particular response is appropriate, what adopting it involves and where it will not help.
Keep the thread intact from first message to next step
A problem-led campaign loses coherence when the advertisement describes a familiar difficulty but the landing page opens with a generic corporate introduction.
Keep the same buyer situation visible as the conversation becomes more specific. An initial message might name the symptom. The page can explain the cause and introduce the response. A product walkthrough can show the mechanism, exceptions and limits.
The next step should help the buyer investigate the same issue. For the illustrative approval product, that might be: “See how an invoice moves from submission to an accountable approver.” It tells the buyer what they will learn, rather than asking them to accept a broad promise of transformation.
For someone already comparing approval tools, however, do not make them read a long account of a problem they understand. Give them the workflow, compatibility, implementation requirements or pricing information they came for. Leading with the problem is a useful choice when relevance needs to be established, not an obligation to delay the answer.
Before you use the message, ask five questions
- Would the intended buyer recognise a real situation here? Replace broad pain words with a concrete circumstance.
- Is the consequence supported? Remove invented losses, unsupported inevitability and false deadlines.
- Does the solution address the stated cause? Do not use a real problem as a pretext for unrelated features.
- Can the buyer inspect the evidence? Match the proof to the scope of the claim.
- Have you made the limits clear? Say what depends on the buyer's process, inputs or circumstances.
These checks will not guarantee a better commercial result. They will give you a clearer, more honest message to put in front of relevant buyers and learn from.
Market the problem so the right buyer can recognise why it matters. Sell the solution by showing how it helps, what supports the promise and where the promise stops.
The goal is not to make the buyer more afraid of their situation. It is to help them make a better decision about changing it.