Mapping Problems to Solutions
- Chris Burgess
- 24 minutes ago
- 5 min read
How to make assumptions explicit and shared so that validation, market exploration, and strategy are easier
By Chris Burgess
You hear a lot about building products by solving problems. But what happens when the product already exists and you now need to validate it? This is the situation many companies find themselves in, especially those moving from projects to products.
Products are always built in response to a perceived problem, whether that problem has been made explicit or not. The challenge is that the problem may never have been validated beyond the team that built the solution. At that point, the work is no longer about inventing a better feature set. It’s about unpicking what already exists and mapping it back to the problems you believe you are solving.
Only then can you clearly communicate what those problems are, why they matter, and whether the solution genuinely holds up in the real world.
I was working with a startup where multiple solutions existed, each created to solve a problem. The issue was that the relationship between problems and solutions had never been clearly articulated, let alone shared with the outside world. No one had documented the problems the business was trying to solve, the solutions that had been created, or how those pieces related to each other.
The result was predictable. Strategy discussions drifted. Tactical decisions contradicted each other. Execution felt riskier than it needed to be. No one was wrong, but also no one was fully right. Everything needed validation, but that wasn’t possible until we aligned on what had already been built and why.
Without a shared understanding of what problems a solution is meant to address, it’s impossible to validate its value with anyone outside the company.
Creating alignment without disrupting existing ways of working
Creating strategy relies on a stable foundation which includes a broad agreement on which problems matter, how they relate to each other, and what capabilities already exist. Without that shared understanding, strategy becomes a negotiation between interpretation and subjectivity, rather than a plan grounded in reality.
This is especially common in teams that have grown quickly through projects, bespoke work, or exploration. Capabilities accumulate faster than shared understanding, and decisions made in isolation start to interact in unexpected ways.
What looks like a prioritisation problem is often a framing problem. Until underlying assumptions are surfaced and normalised, every downstream activity carries unnecessary risk and potentially wasted effort.
The exercise I carried out was designed to slow things down long enough to surface the assumptions already shaping decisions, putting us in a better position to decide what should come next. I didn’t ask anyone to change how they worked or adopt a new model.
Alignment didn’t come from agreement up front. It came from making disagreements visible inside a shared structure, where they could be discussed without becoming political. I used a simple exercise to make existing assumptions visible, allowing alignment to emerge without disruption.
How to map problems to solutions and make sense of complexity
I started by treating my lack of context as an asset rather than something to overcome. Because I was coming into the company fresh, I could ask questions that people inside the team no longer had the distance to ask.
I spent time speaking with everyone involved on the solution side to understand their version of what had been built and why. I also spoke with leadership to understand how they thought the pieces fit together. I documented this carefully, but with one deliberate constraint. I separated problems from solutions. Every problem and every solution had to be described in the same way, which removed storytelling and made inconsistencies surface naturally.
Problems were described in plain language, independent of any existing product. Solutions were documented as they actually existed, not as they were intended to be used. Coming in without deep attachment to their original creation made that separation easier.
Once both sides were visible, the work shifted from opinion to structure. The confusion became obvious when we laid the problems out side by side. To make sense of the sprawl, I arranged the problems along a user journey. Each problem either caused the next, or only existed because a preceding one hadn’t been addressed. They weren’t prioritised or scored, just described in plain terms to reduce bias.
The company talked about solving a long list of issues, some in detail, others in passing. I heard different versions of the problem story depending on who I spoke to, and new ones emerged when people spoke to the outside world.
I used a simple framework to structure my own thinking, populate it with other people’s answers, and reflect it back so alignment could emerge from visibility rather than enforcement.
How to try it for yourself
Start by documenting problems and solutions separately.
Give each problem a clear name and a short summary. Capture the operational realities around it, the technical constraints that shape it, and any market forces that influence it. Most importantly, describe the impact in human terms. Who feels this problem, and what does it stop them from doing? I like to capture this information in a table, with each problem side by side, making it easier to make apples to apples comparisons, whilst ensuring you capture the same information for each problem.
For solutions, describe what actually exists today. Explain what each solution is, the role it plays in the wider system, and how it is meant to help. Be honest about design trade-offs and constraints. Document where existing solutions fall short and where assumptions still need validation through real conversations with people outside the company. Again, capturing each solution side by side in a table makes it easier to compare and contrast, whilst ensuring you capture the same information for each solution.
The final step is mapping problems to solutions, clarifying what problems are truly being solved and how existing solutions relate to them. This is where gaps, overlaps, and misunderstandings surface naturally. The output enables a shared understanding of what the user needs the company is actually trying to meet, and what it has already built to solve that.
How this work unlocks design, marketing, and sales
Once the chaos has been reduced and assumptions have been written down, downstream work accelerates naturally.
Design becomes easier because teams are clear on which problems matter and can ask better questions as they dig into the details. Marketing improves because messaging is anchored in real problems rather than surface-level features. Sales conversations become more credible because solutions are positioned honestly within the system they operate in, not as isolated answers to everything.
Even market research changes. Instead of broad or unfocused discovery, teams know exactly which assumptions need validation and why those questions matter.
This exercise creates a shared understanding of reality.
The lesson I keep coming back to
What tends to cause problems in products that have grown organically is not technical complexity, but a lack of shared, articulated intent. Decisions are usually reasonable at the time they are made, but as those decisions accumulate, the reasoning behind them fades. People understand how the system works, yet struggle to explain why it exists in its current shape.
This work is about making that reasoning visible again. Not to impose a rigid direction, but to shift from accidental progress to deliberate choice. Strategy only becomes meaningful once teams can see the structure of what they have already built and agree on the problems it is meant to address.
If you are leading a startup or scaling a product team and want to reduce strategic noise, align your organisation around real problems, and create a stable foundation for growth, let’s talk. I help founders and product leaders bring clarity to complex systems so strategy can actually stick. Reach out at info@crwburgess.com.
Comments