Synthesis: a simple map to find the deeper meaning before you solve
Most companies do not fail because they cannot solve problems. They fail because they solve the wrong ones, or the right ones at the wrong depth. In more than twenty years moving between product design, user experience, and commercial leadership in enterprise technology,
I have watched brilliant teams spend weeks building answers nobody needed, and I have watched modest teams outperform them simply because they asked better questions first. The difference is rarely talent. It is sequence. We solve before we define, we pitch before we analyze, and we ship before we synthesize.
That is why I keep returning to a simple map of the problem-solving journey, a map that reduces strategy to three honest questions:
- Do we know the problem?
- Do we know the reason?, and
- Do we know the meaning?
Only when you can answer yes to all three have you earned the right to solve.
The map fits on a single page, yet it encodes a discipline that takes a career to learn, and it works as well in a product review or a service redesign as it does in a multimillion-dollar technology deal.
What follows is my field guide to using it, written to be evergreen: the tools around it will change, but the discipline will not. If you are new to synthesis in problem solving, this is the shortest route I know.
The shape of the journey
Read the map from left to right, and it looks almost naive.
Start:
- Ask whether you know the problem; if not, define.
- Ask whether you know the reason the problem exists; if not, analyze.
- Ask whether you know the meaning of what you found;
- if not, synthesize.
- If yes, solve.
Three gates, three crafts, one destination.
What makes the map powerful is what it refuses to do.
It refuses to treat solving as the default activity of a business. Solving is not the default; it is the reward for passing three tests. Most organizations invert the order: they treat defining as bureaucracy, analyzing as optional, and synthesizing as a decorative slide. Then they wonder why the solution underperforms.
The map also converts confusion into instruction.
Every “no” is not a failure; it is a direction. Not knowing the problem sends you to define. Not knowing the reason sends you to analyze. Not knowing the meaning sends you to synthesize.
And each of those three words names a distinct craft with its own tools. Teams waste months precisely because they mix them up, running analysis when they need definition, or building solutions when they need synthesis.
Step 1 – define: do we know the real problem we’re solving?
Definition is the craft of making the vague specific.
The map proposes four moves, and they are deceptively simple.
- Be concrete on what is not working, not on what is annoying or abstract, but on the observable failure.
- Get specific on who it impacts, because a problem without an owner is a rumor.
- Find why it matters and how urgent it is, since plenty of real problems are simply not worth solving now. And finally,
- Compress all of that into a single problem statement that a colleague could repeat without distortion.
I have seen the cost of skipping this step more times than I can count, and nowhere is it more expensive than in enterprise technology deals. A request for proposal arrives with hundreds of requirements, and the temptation is to treat the document as the problem. It is not.
The document is a symptom of a problem that someone inside the client organization could not fully articulate. The real problem lives behind it:
- a revenue target,
- a risk exposure,
- a broken process,
- a promise made to a board.
Teams that respond to the paper win less and erode their margin doing it; teams that define the problem behind the paper write proposals that read like they were drafted by an insider.
The same discipline applies to product and experience work.
“Our app is ugly” is not a problem statement. “New users in retail banking fail to complete onboarding in the first session, and support costs rise with every cohort” is one.
If you cannot state the problem in a sentence, you cannot sell the solution, and you certainly cannot synthesize its meaning later. A good test I use with teams: if the problem statement survives being read aloud by someone outside the project without a single clarification question, the define gate is passed.
Step 2 – analyze: do we understand why this problem exists?
Analysis is the craft of causes.
Once the problem is defined, the question changes from “what is broken?” to “why does it exist at all?” The map again suggests four moves. Look at your data for trends, patterns, and anomalies, because the data knows things the organization has forgotten. Talk to customers and team members, the people who experience the problem daily and who will tell you the truth if you ask plainly.
Map behaviors, meaning what people actually do rather than what they say they do, and why they do it. And use the classic five whys to walk any answer down to its root cause, since the first reason given is seldom the real one.
Analysis rewards humility.
It asks you to suspend the story you already believe and let evidence argue with you. In commercial work, this is the stage that separates serious deal teams from tourists. The tourists recycle a generic pitch deck. The serious ones study the client: how their budget moves, which processes fail, what their customers complain about, what their people say when the formal meeting ends. In relationship-driven markets, like most of Latin America, this stage is pure gold, because the candid conversation after the meeting is often where the real cause surfaces. They analyze behaviors, not brochures.
A warning keeps this step honest
Analysis can become procrastination. Dashboards multiply, interviews extend, and the team confuses volume with understanding. The exit test for the analysis gate is simple, and it comes straight from the map: can you explain why this problem exists? Not describe it, not measure it, explain it.
If your explanation survives the fifth “why”, you are ready to move on. If it collapses at the second, you need more time with the evidence, and the map has just saved you from designing a solution on top of a guess.
Step 3 – synthesize: do we know what this data means to our business?
Synthesis is the craft of meaning, and it is the least understood of the three crafts.
Analysis takes things apart; synthesis puts them back together into a point of view. Two teams can hold the same data, and only one of them extracts the insight, because synthesis is not automatic. It is a deliberate act of interpretation aimed at a single question from the map: do we know what this data means to our business?
The map offers four aids.
Look for patterns across your data and interviews, the repetitions that cannot be coincidence. Ask what the tension or unmet need is, because value hides exactly where something pulls against something else.
Use the formula, which is worth memorizing verbatim: this key finding means we should take this action because of this reason. And finally, test whether your conclusion fully addresses the underlying problem, not just the most recent symptom.
That formula deserves more respect than it gets.
It forces three commitments at once: a finding that is actually key, an action that actually follows, and a reason that actually connects the two. Most strategy documents fail on the connective tissue. They present findings and then leap to initiatives, hoping nobody notices the missing “because”.
When I review deal strategies or product roadmaps, I literally ask for the sentence. If the team cannot produce it, the meaning gate has not been passed, whatever the volume of analysis sitting behind it.
Synthesis is also where courage appears.
A real synthesis names what must change, and that always touches someone’s budget, habit, or ego. Meaning is never neutral. If your synthesis offends nothing, it probably means nothing.
Why synthesis is the most skipped step in commercial work
Here is the uncomfortable truth about most organizations
They would rather analyze forever than synthesize once. Analysis feels safe; it is descriptive, and description rarely gets you fired. Synthesis is a claim about what things mean and what to do next, and claims can be wrong. So teams stack dashboards, commission more research, schedule one more workshop, and the decision quietly ages out while the market moves on.
The map treats this avoidance as a visible failure of the journey.
If you know the problem and the reason but not the meaning, the instruction is unambiguous: it is time to synthesize. Not more data. Meaning. I have sat in too many meetings where a junior colleague held the insight and the room lacked the sentence, the one that connects finding to action through reason.
The formula gives the room that sentence. It turns synthesis from a mystical talent into a repeatable habit, and it is the single highest-leverage habit I know in strategy, product, and sales.
Running the map on a live enterprise deal
Because my work sits at the intersection of technology revenue and complex deals, let me show the map where I live. An enterprise request for proposal lands on your desk.
- Gate one: do we know the problem? You resist the urge to start writing, and you define: behind the requirements, the client’s real problem, who it impacts inside their organization, why it matters this quarter, compressed into a statement the client would recognize as their own.
- Gate two: do we know the reason? You analyze: their market, their operations, their customers, the behaviors of their users and buyers, asking why until the root cause surfaces.
- Gate three: do we know the meaning? You synthesize, and you write the sentence: this finding about their business means we should shape the offer this way, because of this reason. Only then do you solve: architecture, pricing, timeline, proposal.
The difference in outcome is not subtle.
A proposal built after synthesis reads like insight; a proposal built before it reads like inventory. Clients can feel which one they are holding, even when they cannot name the difference. The same sequence scales down gracefully to a pricing decision, a feature priority, a service recovery, any moment where the cost of being wrong is real.
Habits that keep the map useful for years
A map only helps if it is consulted.
Three habits keep this one alive in teams I lead.
- First, name the gate in every meeting: are we defining, analyzing, synthesizing, or solving right now, and do we agree? Half of all meeting pain is two halves of the room working different gates.
- Second, keep the artefacts separate: a problem statement for define, a cause explanation for analyze, a meaning sentence for synthesize, a decision for solve. When the artefact is missing, the gate has not been passed, no matter how many hours were spent.
- Third, revisit old decisions and ask which gate was skipped; it is the fastest strategy education a team can get, and it costs nothing but pride.
Final word: slow is smooth, smooth is fast
The promise of the map is not speed in the naive sense.
It is the speed that comes from not repeating work: not rebuilding the feature, not rewriting the proposal, not relitigating the decision. Define, analyze, synthesize, solve, in that order, with synthesis as the bridge between evidence and action. Tools will change, markets will change, titles will change.
The discipline of asking the three questions before you spend money and reputation on an answer will not. That is why this post does not expire. Synthesis in problem solving is not a trend; it is the habit that turns information into judgment.
Find the deeper meaning first, and the solving takes care of itself.
