One of the things I’ve always found missing in product design is a decent brief. Not a set of tasks in Jira. Not a Miro board from a discovery workshop. An actual brief.
The nature of product design makes this absence somewhat understandable. It’s not advertising, where the problem is predefined and the deliverable is an asset. Products evolve. Requirements shift. Discovery shapes direction. So, the idea of writing a brief before the work starts can feel like trying to sketch a map without knowing the destination.
Yet this is precisely why we need one.
A brief is not a spec
A proper product design brief is not a requirements document. It doesn’t pretend to know all the answers. Instead, it defines the why, clarifies the who, outlines the what, and acknowledges the how is still in progress. It’s a living document written by the team together and updated as new insights emerge.
When done right, the brief becomes a shared compass. It aligns stakeholders. It focuses the team. It stops you from chasing edge cases or overengineering features no one needs. It helps product owners say no. It gives designers and developers a lens to evaluate whether what they’re building is solving the right problem.
Stop hiding strategy in Jira
Often, briefs get replaced with backlogs. The strategy disappears into epics, and the original intent dies under a pile of tickets. A task list is not a narrative. And without a narrative, teams default to delivering outputs instead of outcomes.
A good brief re-centres the work around outcomes. What are we trying to achieve? Who are we doing it for? What should they feel, understand, or be able to do after interacting with our product? These are the questions worth answering.
Consider this structure for a product design brief:
Why this project?
What problem are we solving? Why now? What will success look like?
Who is this for?
Not just demographics, but behaviours, motivations, and accessibility needs.
What are the constraints?
Time, tech stack, budget, dependencies. Be honest.
What is the narrative?
Is there a story that frames the user journey? Is the product onboarding intuitive, is there a payoff?
How should this feel?
Functional? Delightful? Invisible? Is it helping people do something better, faster, more confidently?
What do we know, and what do we need to find out?
Where do we need research? Where do we test? What do we prototype?
What principles should guide us?
Simplicity, clarity, accessibility, speed. Decide early and stick to them.
None of this is revolutionary. It just doesn’t get done. Or if it does, it’s buried in slides that no one opens after the kickoff.
Make it collaborative and living
This isn’t a document that gets handed down. It’s something the team builds together. Product, design, engineering, research, even marketing. It works best when all perspectives are present. And it doesn’t stop at the start. It evolves.
Done well, the brief becomes a source of truth you return to at every stage. It’s the reminder of why you’re here, what matters, and what doesn’t.
Product design has matured in many ways. But our approach to briefing still feels like an afterthought. Bringing it forward and treating it as a collaborative, strategic tool could be the simplest way to raise the standard of what we make.
Not everything needs to start with a brief. But everything should be able to return to one.