Good execution of the wrong thing is still failure.
The project that taught me this shipped on time, looked exactly like the mocks, and got approving nods in the launch review. Then almost nobody used it. Nothing was broken. The brief had simply been written months earlier, on assumptions nobody went back to check, and we’d all executed faithfully against a question that had expired.
The design was fine. The problem was wrong. Solve the Right Problem is what I’ve done about that ever since: a habit of checking that the team is pointed at the actual problem before any design work starts, not the one written down three months ago.
Why it exists
The most expensive mistake is a beautiful answer to the wrong question
You can have everything going for a project and still lose this way. The brief says build X, so everyone builds X, because X is what someone upstream thought the user needed, months ago. When I dig into a failed launch, it’s almost never one dramatic mistake. It’s one of three quiet ones, and they all live in the same picture: the brief holds still while reality keeps moving.
-
Requirements drift from reality
The brief was written months ago and the context has moved on. Nobody revalidates it, so the team ships a faithful answer to an expired question.
-
Success is undefined until it’s too late
Ask five people what success looks like and you’ll get five answers. If the team can’t agree before launch, the metric gets invented after it.
-
Disciplines work in sequence, not in parallel
Design hands to engineering, engineering discovers constraints, scope quietly changes. Nobody agreed what they were building before the work started.
The practice
Five questions I ask before I open Figma
There’s no canvas, no template, nothing to download. Just five questions a brief has to survive, and they’ve killed more bad projects than any process I’ve run.
-
What problem are we actually solving?
Not the feature request. The thing that hurts if we do nothing. If the team can’t state it without naming the solution, there’s no problem statement yet.
Skip it and you build the feature request, while the pain it stood in for ships untouched.
-
How do we know this is the right problem?
What’s under the brief: user research, support tickets, analytics? Or one loud voice in a meeting three months ago?
Skip it and the loudest voice in the room becomes the research.
-
What does success look like, and for whom?
A number, a behaviour, and a person. If the metric is missing, the first deliverable is the metric.
Skip it and the metric gets invented after launch. It always flatters.
-
What are we NOT building?
Scope creep starts when this never gets said out loud. Naming what’s out is the cheapest protection a project gets.
Skip it and scope grows one reasonable request at a time.
-
Who needs to be in the room for this to work?
If engineering and the metric owner aren’t aligned before pixels, their constraints arrive later, dressed as change requests.
Skip it and the constraints arrive anyway, six weeks late and dressed as change requests.
The key insight
Pushing back on a brief is doing the job
Early in my career I treated briefs as instructions. If the result didn’t land, I assumed I’d designed it wrong. It took a few failures to see the other possibility: sometimes the brief is wrong, and a good brief survives being asked how we know. A bad one falls apart the moment you ask. You want that collapse to happen in a review, not in production.
In practice
The brief said navigation. The problem was the homepage.
A brief landed asking us to improve Back Office navigation. Sellers were struggling to find their tools, so the ask was a cleaner layout and a better-organised menu. Reasonable, plausible, and here’s what happened when the questions got to it.
Product brief / Q3
Improve Back Office navigation (rejected)
Sellers report difficulty finding the tools they need in the Back Office. We should redesign the navigation with a cleaner layout, better visual hierarchy and a more organised menu structure.
The current menu has grown organically as features shipped and no longer reflects how sellers think about their work.
Deliverables: updated IA, revised menu component, visual refresh of the header. Success: sellers find tools faster.
Q1 / What problem are we solving?
“Redesign the navigation” is a solution, not a problem. What hurts if we do nothing?
Q2 / How do we know?
The analytics don’t show sellers lost in menus. They show sellers leaving the homepage without acting at all.
Q3 / What does success look like?
“Find tools faster” has no number, no behaviour, no owner. This gets defined before anything gets designed.
The verdict
The brief didn’t survive question two. The journey it wanted to optimise wasn’t happening, so we redesigned the homepage instead: the actions waiting for a seller the moment they log in, not a tidier menu of every tool that exists.
Why it works
Teams that skip problem definition don’t save time. They borrow it.
Asked early
Skipped
The interest gets paid in more than weeks. It’s paid in a design direction people stop trusting because it keeps changing. Asked early, the same questions cost an afternoon.
The best version of this discipline isn’t me asking the questions. It’s the team beating me to them.