Ask the next five people on your team to write down the customer problem they are solving. You will probably get five different answers. Here is how to fix that, and the canvas we use.
If you ask the next five people on your innovation team to write down the customer problem they are working on, you will probably get five different answers. I have run this exercise often enough to bet on it.
That gap, between teams who think they agree on the problem and teams who actually do, is where most innovation projects quietly die. Not in execution. Not in technology. In the unspoken misalignment about what they were trying to solve in the first place. I want to walk through why this happens, what a customer problem actually is, and a specific tool we built into the book to help teams agree on the problem before they build.
Why teams skip the problem
Almost every team I work with falls in love with their solution before they have properly understood the problem. The solution is something tangible they can rally around. There is a prototype, a feature, a roadmap. The problem is messier, slower, less satisfying. So we skip past it. We pay for it later.
The pattern is always the same. We start with a shiny idea. We build it fast, especially now with AI and tools that let us go from idea to working prototype in hours. We pitch it hard through our channels. Only then do we realise nobody was waiting for it. The build was excellent. The aim was off.
As we wrote in our new book, Augmented Collaboration, innovation begins by rigorously defining the real problem worth solving, not by generating ideas. That single shift, from solution-first to problem-first, is what separates teams that ship things people care about from teams that ship things people scroll past.
A simple example of what happens when you do this right
Imagine a team building a budgeting app. They start with the obvious framing: people want to save money. They build features that help users track expenses, set budgets, and visualise their spending. The app is beautifully made. Almost no one uses it.
Now imagine the same team starts by asking what the customer is actually feeling. Overwhelm. Shame. A sense of losing control every time they open their bank app. The real problem is not that people want to save more. The real problem is that people are tired of feeling out of control with money. A product that addresses overwhelm and restores a sense of control is a very different product from a budgeting app. Solving the real problem changes everything that comes after.
This is the move at the heart of the book's method. Get the problem right and the next thousand decisions get easier. Get it wrong and no amount of brilliant execution will save you.
The Customer Problem Canvas
This is why we built the Customer Problem Canvas. It is one of the foundational tools in Augmented Collaboration, and it is designed to do one thing well: get a team to actually agree on the problem before they touch the solution.
The canvas helps teams zoom in on a small number of questions that, in our experience, are the questions teams skip the most. What is broken or frustrating in the customer's world? What behaviour are they already showing? What is stopping them from solving it themselves? What would real value look like for them? Each section of the canvas pushes the team to be specific. Specific is where alignment lives.
Why we added the Customer Problem Statement field
Recently we added a new field to this canvas. We call it the Customer Problem Statement. The idea came directly from the 250 co-creators of the book. As they tested the canvas in their own teams, the same pattern kept showing up. Teams would walk out of the workshop with rich answers to every question on the canvas. Problem, root cause, who feels it, alternatives, disadvantages. Everything except one clean sentence that said: this is the customer problem we are committing to solve.
The co-creators flagged that the synthesis step was missing. So we added it. The Customer Problem Statement is now the field that sits between everything the team has uncovered and everything they will design next. It forces the team to crystallize one agreed sentence before anyone sketches a solution. Without that sentence, the work drifts. With it, the work has a clear target.
There is a simple test for whether the Customer Problem Statement is right. Could the next five people on your team write the same sentence? If yes, the team is aligned. If no, you have just found the most important thing to fix before building anything.
Three questions to ask before you build
Before you sketch your value proposition or design that next clever feature, three questions are worth asking yourself and asking out loud with the team.
Could the next five people on my team write the same customer problem statement? Have we actually agreed on the problem, or only on the urgency? Are we building something useful, or just something clever?
The teams who learn to start with the problem ship things people care about. The teams who skip it ship things people scroll past.
Where to find the canvas
The Customer Problem Canvas, including the new Customer Problem Statement field, is in Augmented Collaboration. Grab your copy of the #badversion, available now as a softcover and as a digital edition. The final version, with QR codes linking each tool to a live Miro template, arrives on 1 September 2026 and can be pre-ordered today.
Every tool in the book is designed to be used, not admired. The canvas is one of the simplest places to start.
0 comments