Problem Framing: Define the Problem Before the Solution

Think about the last proposal you lost to a competitor whose offer looked weaker than yours. Chances are you did not lose it on product, and you probably did not lose it on price either. You lost it because they understood the customer’s problem better than you did, or at least they made the customer feel that they did.

Every day, account teams present solutions to problems they have never properly defined. Then they wonder why the proposal falls flat, and watch someone else win with what looked like an inferior offer. Problem framing is the discipline that stops this happening, and it is the first thing we teach when we talk about offer development and innovation.

Where problem framing sits in value-based KAM

In our Value-Based KAM Framework there are seven steps, grouped into three phases: offer development and innovation, agreement, and value capture. Step one is customer needs analysis. Everything else, the ideas, the customer value proposition, the pitch, the value you eventually capture, rests on it.

The Value-Based KAM Framework. Problem framing lives inside step one.

I break customer needs analysis into two activities: framing the problem, and then writing it down as a clear problem statement. Neither is complicated. Both get skipped constantly, because the pull to start talking about your solution is so strong.

The book designer Chip Kidd put it neatly: “If you can properly define the problem, then you’ve already defined the solution as well.” He was talking about book covers. It is just as true of a supply contract.

What problem framing actually means

Problem framing is the work of analysing, understanding and defining a customer’s challenge (or opportunity) well enough to design something that genuinely solves it. For a key account manager, that means going past what the customer tells you they need, and finding out why they need it, what is causing it, and what solving it would do for their business.

Three things matter most.

Context. A procurement team asking for “cost reduction” might be under pressure from private equity owners, from a price war in their own market, or from margin squeezed by their supply chain. Each of those is a different problem, and each needs a different answer. The request sounds identical in all three cases.

Stakeholders. The finance director experiences the problem as a budget line. The operations director experiences it as missed schedules and tired people. They may be describing the same underlying issue in completely different language, and if you only hear one of them, you will build for half the problem. This is why mapping the decision-making unit is part of the job, not an optional extra.

Root cause. When a customer asks for “better reporting”, the real issue might be no real-time view of operations, systems that do not talk to each other, or a decision process nobody trusts. Reporting is the symptom. Solve the symptom and you get a polite thank you. Solve the cause and you get a relationship.

What goes wrong when you skip it

The most common failure is what I call the feature-function trap. Without a framed problem, your proposal describes what your product does rather than why it matters to this customer. The customer cannot connect your offer to their real challenge, so they compare you on the only thing left: price. That is the fast road into the commodity trap, where you become interchangeable with every other supplier and your margin goes with it.

The second failure is quieter. Different people in the customer think you are solving different things. The IT director believes you are fixing integration; the business lead believes you are fixing process efficiency. Nobody notices until the decision meeting, when the disagreement surfaces and the deal stalls.

Then there is solution overkill, or underkill. Get the problem wrong and you either build something expensive for issues that do not exist, or something too thin because you missed half the real challenge. Either way, you will struggle to show a return, and your credibility takes the hit.

And in accounts you already hold, poor framing means you fix the presenting issue and miss the bigger one sitting behind it. The account stays transactional. You never earn the right to the larger conversation, and your share of wallet stays where it was.

The D.E.E.P. problem framing model

To make this practical, I use a simple four-step model. It is deliberately easy to remember, because you need to be able to use it in a corridor, not just in a workshop.

Discover the context

Start by mapping the customer’s world. What pressures is their industry under? What are their strategic priorities this year? Who are the stakeholders, and what does each of them worry about? Use conversations, published results, annual reports and whatever account intelligence you have. Three questions I always ask: what is happening in their industry right now, what are their top three priorities this year, and who gets promoted or fired depending on whether this gets solved?

Explore the root causes

Now move past the symptoms. The five whys, the technique Toyota made famous, works well here, and so does an Ishikawa or fishbone diagram if the problem has several tangled causes. What customers ask for (faster processes, better data, lower cost) is very often a symptom of something organisational, strategic or operational underneath. Ask yourself why this problem is showing up now, and what would happen if you fixed the symptom and left the cause alone.

Empathise with the impact

Understand how the problem lands on people, personally and professionally. How does it affect their daily work, their department’s results, their career, their company’s position against competitors? Who is hurting most? What does success look like to each of them? This is the step most account managers rush, and it is the one that makes the eventual proposal feel as if it was written for the reader.

Prioritise and frame

Finally, pull it together into a single frame that all the key stakeholders would recognise as their problem. Then, and this is the part people forget, take it back to them and check it. Your understanding is a hypothesis until the customer confirms it.

Writing the problem statement

A problem statement turns all of that into something you can put in front of a customer and a colleague. It becomes the foundation for the proposal, the solution design and every conversation that follows. A good one names the customer and the context, describes what is happening now, sets out the future state the customer wants, says what happens if nothing changes, and shows how you will both know the problem has been solved.

The structure I use runs like this: [this department or function] is experiencing [this specific challenge], which is causing [this quantified impact] and preventing them from [this strategic objective]. It could be solved by [these approaches], to avoid [this consequence] and achieve [this desired outcome].

Compare “the customer needs better technology” with something like “the procurement team is taking almost a quarter longer than it should to select vendors because of manual approvals, which is delaying project launches and costing them ground in their core markets.” The second one gives you something to solve. The first gives you something to sell, which is not the same thing.

Here is a fuller worked example, using a private hospital group.

A problem statement worked through in full. Notice how little of it is about the supplier.

Look at what the table does. The presenting problem is staff turnover. But the impact runs all the way to insurer confidence, referrals and the hospital’s brand, and the desired outcome is a reputation for care that lets them win business and grow. A supplier who walks in talking about recruitment software is selling. A supplier who walks in talking about the hospital’s reputation with insurers is solving. Guess which one the operations director wants to keep talking to.

Putting it to work

You do not need a programme to start. Pick one key account where there is a live opportunity. Have structured conversations with three to five stakeholders using D.E.E.P. Get your own account team in a room to pull out the patterns. Draft two or three alternative problem statements and test them on a friendly contact inside the customer. Then play the framing back to the customer before you design anything.

If you want a sharper test of whether you need this, look back at your last three major proposals or account plans. How much of each one explained the customer’s problem before it explained your solution? Do the customer’s decision-makers all describe the problem you are solving in the same way? When you compete, do conversations turn to strategic fit, or to feature lists and discounts? When your customers describe you to others, do they talk about how well you understand their business, or about your products and your prices?

If those answers make you uncomfortable, that is useful. It tells you where to start. A key customer deep dive is essentially this process run hard on a single account, and the One Page Proposition is where a well-framed problem ends up once you have a proposition worth writing down.

The customer who says “yes, that’s it”

There is a moment I have seen many times, and it never gets old. You finish playing back the problem, and the customer leans back and says, “Yes. That’s exactly it. Nobody has put it like that before.” Sometimes they ask if they can borrow your wording for their own board.

At that point you have not proposed anything. You have not mentioned a product or a price. And yet the conversation has already changed, because you have shown that you understand their problem as well as they do, and occasionally a little better. That moment is worth more than any slide in your deck.