The Anatomy of The Product Brief

With all of the Product Management roles I've held, it's been tough to get the Product Roadmap process just right.  Employees and clients want to see the roadmap, and once a quarter might not be enough; some people don't know what to expect with a feature that's listed on the roadmap; others don't understand what goals each of the features or themes align with.  I've tried several ways to do this in the past with no luck - and then recently, my boss and I came up with something great The Product Brief

A Product Brief is a stable, widely shared, "one-page" document describing the goals and benefits of a feature as well as the scope of a project. 

The Product Brief is broken into 6 sections. (How to write a product brief:)
  • Release Notes Summary: Describe the project as if writing release notes or a short press release. What are the key features? Why are they exciting? What is the benefit? (Like at; here's a suggestion)
  • User Problem Statement(s): What problems are we trying to solve? Be sure to define which users these problems effect as precisely as possible.
  • Project Rationale: Why should this project be a priority? How does it drive revenue, cost reductions or customer-happiness? What research have we done? How wide-spread is the problem?
  • Project Scope and Scale: What's in and what's out? 
  • Measuring Success: How do we measure success?  How will we know when we are successful?
  • Dependencies: Do customers need to upgrade?  Are other features dependent on this one?What do we need from partners? What do we need outside of engineering?
  • Key Links: Links to requirements documentation, wireframes/mock-ups, research, etc. 
What do you use to community each of the features on your roadmap?  Do you give your current customer a detailed view of what's coming?  Do you think the Product Brief could be helpful in your organization?



No comments:

Post a Comment

Note: Only a member of this blog may post a comment.