TL;DR: Customer problem identification means finding the real issue, not just the one described. Most briefs are symptoms. Slow down, ask better questions, and you will solve the right problem the first time.
Most businesses get this wrong in the same direction: they solve the problem the customer describes rather than the problem the customer actually has. Customer problem identification is the discipline of closing that gap, and it matters far more than most product teams, consultants, or founders want to admit.
The described problem is almost always a symptom. Someone says they need a faster checkout process. What they mean is that their conversion rate is falling and they have run out of other explanations. Someone says they need better internal communication. What they actually have is a management structure that actively discourages people from raising problems early. Solve the symptom and you will be back in six months, slightly embarrassed, doing it again.
There is a structural pressure in almost every client-facing relationship to move fast. Clients are paying. They want to see progress. Spending three meetings asking questions before proposing anything feels, to them, like stalling. To you, it might feel like burning goodwill.
So you take the brief at face value. You build the thing they asked for. And somewhere around the fourth week of a six-week project, you both realise the brief was wrong, the assumptions were untested, and the thing being built solves the wrong problem with considerable precision.
I have done this. A client once asked me to help them improve their onboarding documentation. We spent weeks refining it, and usage barely moved. The real issue was that their sales team was setting expectations the product could not meet, so new users arrived already disappointed. No amount of well-written documentation fixes that.
These three things are not interchangeable, and treating them as though they are is where most discovery processes fall apart. A symptom is what the customer observes and complains about. A problem is the functional or structural cause of that symptom. A root cause is the underlying reason the problem exists at all.
Take a retail business seeing declining repeat purchases. The symptom is the drop in return customers. The problem might be poor post-purchase communication or a weak loyalty incentive. The root cause could be a broader shift in how the business acquires customers in the first place, attracting discount-seekers rather than brand loyalists. Solving for any one of these in isolation produces limited results.
Good customer problem identification works backwards from the symptom through the problem to the root cause, and only then asks what intervention makes sense.
The most reliable method is structured questioning, but the structure needs to be in your head rather than in a visible framework. The moment a client feels like they are filling in a template, they start giving template answers.
There is a well-worn distinction between what customers say, what they do, and what they actually need. It is well-worn because it is persistently true. Customers describe their needs in terms of the solutions they can already imagine. They cannot reliably articulate needs that fall outside their current frame of reference.
This means that interviews and surveys, while useful, are not sufficient on their own for understanding customer needs at a deeper level. You need to observe behaviour where possible. You need to look at what customers do when they think no one is watching, not what they say they do when asked directly. Support tickets, session recordings, churn interviews and repeat complaint patterns all carry signal that self-reported data tends to obscure.
The other thing worth watching is where customers use workarounds. A workaround is a customer solving your problem before you do. It means the need is real, the pain is real, and the gap in your offering is real. That is a better starting point than almost any research brief.
This is uncomfortable. Clients write briefs. Clients brief agencies and consultants and freelancers. The brief represents work, which represents revenue. Questioning the brief can feel like questioning the relationship.
But customer-centric problem solving, done properly, means being willing to say: ‘I think the problem you have described is real, but I do not think solving it will get you to the outcome you want’. That is a harder conversation than nodding and getting started. It is also, usually, the conversation that builds the most durable professional relationships.
You are not doing anyone a favour by delivering a technically correct solution to the wrong problem. The client will be disappointed. You will be frustrated. And the next brief will carry the weight of that unspoken failure.
These are not always the same, and the distinction matters practically, not just philosophically. A customer might want a bespoke reporting dashboard. What they need is to stop making decisions based on data they do not trust. Building the dashboard without fixing the data quality problem means building something impressive that will be abandoned within a quarter.
Discovering what customers want is relatively easy: ask them, read their requests, look at what they purchase. Discovering what they need requires understanding their actual context, including the pressures they are under, the constraints they are not mentioning, and the internal politics shaping the brief you received.
The fastest route to that understanding is usually asking who in their organisation this decision is most connected to, and why now. Timing is a clue. Problems that have existed for years but are suddenly urgent have usually become politically visible. That context changes what a good solution looks like.
A useful test is whether the problem statement still holds when you ask ‘why’ three or four times in sequence. If each ‘why’ leads to a deeper and still-plausible explanation, you are working at the right level. If the chain collapses quickly or produces something implausible, the original problem statement was probably a surface description rather than a real diagnosis.
You do not need to win that argument. You need to understand the context well enough to determine whether their framing is workable. In some cases, the customer’s framing is close enough to accurate that building to it makes sense. In others, you can solve for their stated problem while also addressing what you believe is the deeper issue, and let results make the argument for you.
It depends on the complexity and stakes involved. For a short-term project, one or two focused conversations before scoping work is often sufficient. For longer engagements, discovery should be treated as a formal phase with a defined output, typically a problem statement that both parties have signed off on. Rushing this phase does not save time overall. It redistributes the time into rework.
Sometimes. Behavioural data, support logs, and churn patterns can reveal a great deal without a single interview. But indirect data always has gaps, and the gaps tend to be exactly where the most important context lives. If you cannot speak directly to customers, speak to the people who do: account managers, support staff, and sales teams often carry detailed knowledge that never makes it into a formal research process.
A clear, shared problem statement. Not a brief, not a list of requirements, not a scope of work. A single, specific statement of the problem being solved, agreed by everyone involved, with enough context attached that someone who was not in the room could understand why this problem matters and how you will know when it is solved.
That statement becomes the filter for every subsequent decision. Should this feature be included? Does it address the problem statement? Should this deliverable be prioritised? Does it move the needle on the identified root cause? Without the statement, you are making those decisions based on preference, habit, or whoever happens to speak most confidently in the room.
If you have delivered a technically solid piece of work that still left the client quietly unsatisfied, there is a reasonable chance the real problem was never properly identified. The question worth asking is not ‘what did we miss in the build?’ but ‘what did we accept too quickly in the brief? ‘
If you would like any guidence on how to move your business forward, G&G has the necessary skillset to help you manage your business more efficiently and more profitably. if you would like some assistance, please dont hesitate to contact us.
From business planning or Business Administration to assisting with your organisations growth, we are happy to advise and help where we can. Get in touch to start your no-obligation consultation!
Share this article:
Essential cookies required for the site to function. Cannot be disabled.
Cookies that help us understand how visitors use the site.
Cookies used to deliver relevant advertisements.
Privacy Policy Terms of Service
