Building a better product brief

What’s in a product design brief? Not nearly enough. That’s according to product and design pros Mary and Dave Sherwin, co-founders of Ask the Sherwins, a consulting and training firm that helps organizations develop better product design capabilities. Folks in design circles may know them best as the authors of the books Creative Workshop and Turning People into Teams. ‍

Product briefs are complex documents and for that reason, they can be a particularly contentious topic, often mired by myths and misconceptions. 

“The brief sort of has this reputation...it's almost like the Ark of the Covenant and Raiders of the Lost Ark,” says Mary Sherwin. “People think that if they look too closely at it, it's going to melt their faces off. I think it really speaks to the way that the brief, instead of being a gate, has become a sort of gatekeeper.” 

Decades spent deeply embedded within product and design teams has taught the Sherwins that a thorough and honest brief is the best way of mitigating risk. They’ve also witnessed how the most successful teams collaborate on briefs to make sure that it has all the right starting assumptions.

“If the team’s honest about how their priorities might change, then the product brief moves further away from being a product pitch or a task list and becomes something that’s potentially much more valuable to the business and to customers,” says Mary. 

Here are some of the Sherwins’ top tips for how to artfully design product design briefs.  

You may need more than one type of brief 

David Sherwin points out that many teams assume that a product brief is, “the one document that will tell us what to build and where everything is all figured out and laid out in perfect detail.” But it’s important not to inadvertently turn your brief into a spec or a list of tasks. Mary says that the ideal brief holds space for experimentation. 

Properly identifying your goal is another important step. David says he’s seen many cases where a company may not know their audience particularly well, but they have a hunch or a hypothesis that they want to test out before they start actually investing in building anything. 

In that case, you likely need a more research-based brief that includes all the questions you have and how you’ll go about trying to find those answers. 

Generally speaking, the most effective briefs:

• Frame the challenges that teams are meant to try to solve or learn about
• Identify the data and information needed to draw a meaningful conclusion (whether that’s a mix of metrics, surveys, customer and user interviews etc.) 
• Articulates what success looks like, something David calls the “threshold of proof” 

Determine your “threshold of proof”

Another way that briefs — especially research briefs — get a bad rep is that folks may think that the insights will come too late and wind up throwing a wrench into all the work that’s in progress. So, as with any brief, it’s important to define the scope of your experiments and explorations. 

“When you're a startup, the threshold of proof is usually around things like, do people find value in this area? Are they going to use this kind of product? Would they pay for it?” says David. 

But for larger companies with products that have millions of users, the threshold of proof for releasing something new is markedly different, given the sheer number of people that the change could affect. 

“And so the brief might have a point of view about what success looks like in terms of those thresholds of proof,” says David. “So when you have stakeholders who say they don't want to hand over a blank check for you to work on this endlessly, then you can be prepared to show them what your exact end goal is and how you’re going to prove it.” 

Mitigate risks by mapping out unknowns and need-to-knows

Mary wants to let you in on a secret: “The difference between an A minus and an A brief is in acknowledging the metrics and data that you don't have yet.”

One of the key reasons why it’s important to distinguish the product design brief from, say, a feature spec is because, according to Mary, the brief is “the only place that you can outline your big unknowns and templatize that out.” (Interestingly enough, Sana Rao, VP of Product Design at Peanut, and formerly at Apple, Twitter and Deliveroo, said almost the exact same thing in our interview with her. ) 

Mary warns that if you aren’t honest about your unknowns from the outset, or at the very least curious, you may end up significantly undercutting the potential of your product. That’s a pretty huge risk to take just to save time, and maybe a little face with the higher ups. 

Collaborating on product briefs as a team

It should almost go without saying (but we’ll say it anyway for good measure) that product briefs should map back to larger company goals and objectives. In other words, if your company uses OKRs to track their success, then your briefs should be an extension of those bigger picture goals. 

But when it comes to actually compiling the brief itself; who does what and what’s the right output? We went ahead and asked the Sherwins. 

• To build a good brief, you have to have good inputs. Ideally briefs are owned by one person, but built by a cross-functional team who would all collaborate to make sure that the brief had the right starting assumptions and data points. Being a good contributor to a brief is something cross-functional members should be held accountable for as a standard part of the process. They may not own the creation of the brief itself, but they should be responsible for how the brief is used and the results that come from it. ‍
• Keep your brief front and center (sometimes literally). Mary recalls a PM who had a habit of printing out physical copies of briefs and putting it on a board in plain view of the whole team. Every time a step was complete, the brief would get updated and reposted to the board. What seemed like a tedious habit at first, later became a vital part of the team’s process. “At any point, if the work that you were putting up was deviating from that brief, you had something tangible to look at, so when you talked to another person about it, they could challenge you and objectively say: we're not working on-brief anymore,” she said.
• ‍Capture your story along the way. It’s more than likely that there are many people across the business who have a vested interest in the outcome of your work, whether because they’re revenue leaders and stakeholders or fellow design and engineering colleagues who will have to build off your brief. David says that it’s important to capture and report on your work in a way that makes it really easy to discuss what you've learned. A basic story framework to start with that he recommends is: “We wanted to do this thing and this is what we thought would happen. Then we discovered all of these consequences and unintended consequences, and this is how we’re going to use what we’ve learned to iterate on the product.” 
  

To serve users better, teams need to unbias their briefs  

Nowadays there’s a bias towards designing and building products for known audiences but, as Mary points out, “You can’t build a track record if you’ve never been on the track.” As a disabled person, Mary knows that usage metrics for this underrepresented group are practically nonexistent. “We're a huge market share, but because products aren’t being built for us, we don’t have the numbers or data, so we’re just not on people’s minds,” she adds. 

David points out that designing for accessibility all too often becomes “like the two or five percent capacity project that teams kind of shoehorn in at the end of the process.” So it’s important that the needs of multiple underrepresented audiences are factored in from the very first brief. 

A good brief gives teams the space to consider multiple viewpoints and addresses cognitive bias. Not only does that increase the product’s user pool, but it’s also a tangible step towards building products that are more inclusive of communities and provide a better user experience for people of all backgrounds and abilities. But what do you do when you don’t have the data you’d hoped for?

That’s the magic of collaborative briefs. In the wake of missing data points, teams are forced to figure out how to bring more people and voices in to add their perspectives and solve for that gap — as opposed to just ignoring or putting those needs aside altogether in favor of the data that is convenient. 

Better briefs = better products   

It’s exciting to think about briefs as an opportunity to, as David puts it, “robustly debate assumptions.” The thing is, not all teams feel comfortable taking that step with each other. But increasing our decision quality through the practice of healthy debate is something we all have to collectively work on if we’re going to build truly meaningful, safe and groundbreaking products. 

Mary’s ideas for the future of briefs is a little more immediate: “I want briefs for sunsetting features. Period.” You could think of it as a kind of post-mortem brief. Which, for Mary, is anything but a sad affair. 

“I see it as a great moment of celebration,” she says. “It’s a chance to look back at all the things we’ve learned and accomplished when we built that feature and answer questions like: Why are we sunsetting this? How are we going to do it? What's the rollout for this? What's the impact on each member of the team?” 

The Sherwins are right. Maybe it’s time that we allow ourselves to get a little more creative, maybe even a little daring, and allow ourselves to think outside the brief (as we know it). 

This post is part of an ongoing series featuring snippets from our podcast: By Design — a show about designing exceptional digital products and experiences. Each episode, our host and co-founder Josh Brewer dives deep into every stage of the product life cycle along with industry experts.