The Problem Statement Before the Solution

Most brand engagements begin with a solution already half-chosen — a new visual identity, a fresh tagline, a rebrand — before anyone has written down, precisely and specifically, what problem that solution is meant to fix. This ordering feels efficient and is almost always the reason the eventual output doesn’t hold up: a solution chosen before the problem is precisely stated is really a guess dressed as a plan, and it’s frequently the wrong solution for a problem nobody actually examined closely enough to name.

Why “the brand feels dated” isn’t a problem statement

A phrase like “our brand feels dated” or “we need to look more modern” describes a feeling, not a problem — and feelings don’t reliably point to the right fix. A dated feeling might trace back to an actual competitive disadvantage, a genuinely stale position, or it might trace back to something a new visual identity can’t touch at all: a sales process that’s slow, a product genuinely behind the market, an internal culture problem showing up in every customer interaction regardless of what the website looks like. Treating a feeling as if it were a diagnosed problem skips the step that would have revealed which of these is actually true.

What a genuine problem statement requires

A real problem statement is specific enough to be wrong — it makes a claim precise enough that evidence could contradict it, rather than a vague feeling everyone can nod along to without anyone actually checking whether it’s accurate. “We’re losing deals to competitors who position more clearly, evidenced by sales team feedback and lost-deal interviews” is a problem statement. “Our brand feels old” is not — it can’t be checked, and because it can’t be checked, no one can tell afterward whether the eventual solution actually addressed it.

Why skipping this step is so tempting

A precise problem statement often requires uncomfortable admissions — that the sales team has been quietly working around an unclear position for years, that a “modern” competitor is actually winning on substance rather than aesthetics, that the company’s internal story about itself doesn’t match how the market actually experiences it. A vague feeling avoids all of this friction; it lets everyone agree something should change without anyone having to specify, and defend, exactly what and why. The cost of that comfort shows up later, when the finished solution doesn’t move the numbers the vague feeling was supposedly about.

What changes once the problem is actually stated precisely

A precise problem statement does something a vague one can’t: it disqualifies wrong solutions early, before money is spent on them. If the stated problem is “sales cycles are too long because buyers can’t quickly understand our differentiation,” a new logo is visibly not an adequate response to that specific claim — the mismatch is obvious once the problem is stated this precisely, in a way it never was when the problem was just “we need to look better.” This is the actual value of doing this work first: not academic rigor for its own sake, but a much shorter path to a solution that actually fits the problem, because badly-fitting solutions get ruled out immediately instead of being discovered as failures months later.

Inceptik deliberately withholds the solution at this stage. Symptoms first have to become a testable question: Who misunderstands what, in which situation, and with what commercial consequence? Customer research provides stronger evidence than internal confidence. Only when the problem is precise enough does the actual positioning decision begin.

Continue with related topics

• Ground Truth Over Internal Confidence
• What Brand Positioning Actually Means (And What It Doesn’t)
• Why Inceptik Does Not Run Brand Strategy Workshops

FAQ

How long should writing a proper problem statement actually take? Less time than most people fear, once the discipline is applied — often a matter of days of focused work: interviews, evidence gathering, and specifically pressure-testing the initial vague version until it becomes checkable. What takes longer is the reluctance to do it, not the mechanics of the work itself.

What if different stakeholders disagree about what the problem actually is? That disagreement is valuable information, not an obstacle — it usually means the organization has multiple, only partially overlapping theories about what’s actually wrong, and surfacing that disagreement early is far cheaper than discovering it after a solution has already been built around only one of those theories.

Isn’t this just adding a bureaucratic step before the real work starts? A precise problem statement can narrow the solution space considerably. It takes time at the start, but reduces the risk of building an expensive answer to the wrong question.

---