Before you chase ideas, check what you’re assuming
Most projects that fail do not start with a weak idea. They start with the wrong problem. Three simple tools to get the problem right first.
When things get busy, the urge is to get moving: book the room, start sketching, build something. That is exactly when teams skip the most important step, which is slowing down to define the challenge.
Many teams spend months solving problems that never really existed. They jump straight into building, sure they have nailed the brief, and find out too late that customers did not want it, need it or understand it. That is not a creativity issue. It is a framing issue.
The good news is that it is also the cheapest problem to fix, as long as you fix it first. Here are three tools we use at the start of every piece of work.
1. Ask what the real challenge is
Vague briefs like “improve the user experience” or “add a new feature” usually hide a deeper, messier problem. Before you book time or gather the team, ask a simple question: what is the real challenge here?
Then keep asking until it gets uncomfortable. That friction usually means you are getting close to the thing that actually matters.
2. Run an assumption audit
Behind most slow projects is an untested assumption: a guess that everyone treats as fact. A short audit brings them into the open.
- Ask the big question. What are we assuming is true, but have not tested? Write every answer down, however obvious it sounds.
- Sort by risk. Which assumptions, if wrong, would derail the whole project? Start there.
- Turn one into an experiment. A customer interview, a quick prototype or a small data check. The goal is not proof. It is learning.
3. Turn complaints into “How might we” questions
“How might we” can sound like a fluffy brainstorm exercise. In practice it is a structured way to turn problems into opportunities, and it changes the energy in the room. Blame and frustration give way to curiosity and ownership.
- Start with real observations: customer frustrations, business blockers, system limits.
- Write them down as insights, not assumptions.
- Turn each insight into a question that opens up ideas.
So “customers abandon onboarding halfway through” becomes “How might we make onboarding feel faster and less overwhelming?” And “users hate our checkout” becomes “How might we make checkout feel effortless?” The complaint is the same. The conversation it starts is completely different.
Look outward before starting from scratch
One more question worth asking early: who has already solved something like this well, and what can we learn from them? Borrowing a proven idea is usually faster than inventing a new one.
Clarity does not come from confidence. It comes from asking the right questions early.
This is why the first part of any sprint is spent on the problem, not the solution. Read more in Why the first day of a sprint is your secret weapon and What is problem framing?
