How to write a compelling product brief
Software development is an interesting beast. It’s both technical and creative, and somehow never goes as fast as you want it to (as a Product Manager at least). There’s a constant tension between process to drive efficiency and productivity, and freedom to allow for better results.
When I first started as a PM at Autodesk, we didn’t really do much in terms of formal briefs. We just sort of discussed things and jotted down notes, then invariably came unstuck months later on when we forgot why certain decisions were made. That, combined with a constant need to explain to external stakeholders at different stages of development why we were doing whatever it was we were doing, created the conditions to introduce a more formal document to adhere to.
Initially we referenced the Intercom Job Story template, which remains a superb starting point. However, what was key was that we evolve it based on needs and learnings, and also allow each team and PM to evolve it their own way. Thus, efficiency and productivity can be improved, but freedom can be maintained.
One of the challenges for me during the evolution of the product brief format was trying to keep it readable and high-level, even as there were many things that competed for a space in its pages. This often meant including sections that were simply links out to more detailed documents.
There are a few general rules I try to adhere to:
- Try to minimise the amount of technical detail. Assume non-technical people will be reading it. Use of simple imagery or diagrams can work wonders.
- Avoid describing (or even implying) particular solutions whenever possible. We were fortunate to have at least one designer on every team, and they would work much better when afforded the freedom to develop solutions holistically.
- Assume it will change over time.
The most recent iteration of my Product Brief template has the following sections (labelled with emoji to make it less of a dry read):
Summary ✨
Condense everything we are trying to accomplish with the work into a single paragraph (or ideally, sentence). I tend to phrase these in the form or a “How might we…?” question, to stimulate engagement from the get-go.
Problem 😣
This should similarly be a single paragraph. I tend to write it in the form “It’s hard to … because …”. This is probably the hardest section to write, and one that I revise over and over again before I consider the brief ready to share with anyone else. Being unable to succinctly describe the problem to solve means that you don’t yet know enough(as a PM) about what it is you’re trying to accomplish. Often I’d try and work a bit more on the following sections to try and clarify for myself, and then come back and try and express the problem as clearly as possible. It’s of course possible to come to the conclusion that maybe this isn’t a problem worth solving– which points to the need to do more research.
Why 🔍
Here’s where I would go into the detail, kind of like the sales pitch to whomever will be reading the brief. This section tends to be the longest (at least in the first draft), but needs to be edited, edited, and edited some more so that it’s a compelling read. I’ll sometimes break it down with subheadings to make it easier to read. This is also the section that can (and should) inspire the most discussion with the team.
Risks 😟
Identifying risks early on I feel helps create direction around what we need to do first, in terms of research and testing. This can take a lot of thinking about, and requires a different mindset than other parts of the document. Essentially you have to apply a critical eye to everything else in the brief, poke it for holes and then make a list of what those holes are. This is not easy to do when you are (hopefully) enthused about solving the problem you just identified and trying to get the reader excited about it too.
Job Stories 💼
In this section I’ll list out job stories in the form of “When I’m…, I want to …, so that I can…”. These can help focus designers and developers on specific aspects of the problem space.
Success 📊
Part of being a PM means being accountable. Although the work might lead us in a different direction than we might originally anticipate, it’s important to have a lens on the problem space that tells everyone when we’re done, and whether we can call it a successful endeavour. This section can have a clear “definition of done”, but should also include things like which metrics we want to monitor, whether those are qualitative or quantitative.
Audience 🍿
Here I’ll list out the personas we might be focusing on, and also any particular customers we might want to engage with for research and feedback over the course of the project.
What 💡
This section tries to capture the more practical aspects of the project. I’ll often need to revise this once designers have read through it, as inevitably I’ll have strayed too far into implying a solution, but it’s usually easy to find a good balance with some back and forth. What’s extremely important is to include anything that should be considered “out of scope”, a list that I will generally add to as I discuss the brief with the team.
Plan 🗺️
I previously used this section to capture details related to the resourcing and timeline of the project, but I found it just made the document too lengthy. So more recently I have just linked out to a dedicated document, which can be owned by a development manager or scrum master.
Guiding Principles 🧭
Something I have found useful to help people on the team be more autonomous is to describe the work in terms of principles. Often designers and developers need to make choices between two or more seemingly good options, and then we’d need to discuss and think about each of those. Having principles in place instead gives them a framework to try and make those decisions directly. My favourite way of writing principles comes from this comment by Dustin Senos: “list two positive words in opposition”.
Decisions 👍🏻
A lot of decisions get made during the lifetime of a project, and these can be easily forgotten, particularly years later when someone is trying to understand why things are the way they are. Sometimes those decisions are to make for the best possible user experience, and sometimes they are more pragmatic compromises. Either way it’s good to capture them for posterity. Because there tend to be a lot of them, and because they have utility beyond the expected lifetime of the product brief, we usually just link out to a dedicated wiki page.
References 📚
This is just a catch-all list of links to any resources for further reading.
Once the brief is written to a level I’m happy with, one of the most important things to do is invite discussion. I‘ve tended to just use the built-in commenting system for Google Docs /Microsoft Word so we can have meaningful asynchronous discussion, but it can quickly become cluttered, particularly for people catching up later on; so there’s usually a point where that conversation has to take place elsewhere.
What have I missed? Let me know in the comments about anything you make a point of capturing in your own product briefs!