The Product Discovery Document We Use For Every New Feature

Hello!

Last week, my mind was mostly on building products. In case you missed it, here are the essays:

1. Building a Product You Want Is the Best Way to Build a Great Product (for paying subscribers only)
2. Latest Acquisition Strategy: Letting People Get Value Before Signing Up

Continuing with the theme, I'm going to share the document we use at Buffer for every new feature we consider.

Product discovery vs Product design

Tom Redman (product manager), James Morris (product designer), and I (product marketer) are constantly refining the way we develop our product. We recently added a new product discovery document to our planning process.

We call it the Discovery Brief.

While this is a new document we are using in our product planning process, it is more of an additional step to make our process better. The document works as a checklist to ensure we thoroughly think through any new feature.

We have already seen some successes:

• We realized a feature we want to build should be built in another part of Buffer, which is own by another team. This led to a discussion with the other team and a different prioritization because that feature is a nice-to-have in the new context.
• We dropped a feature from our pipeline because, after the discovery process, it doesn't feel like as big a problem for our customers as we had thought. This saved us time from designing and building a feature few people would use.
• James has more clarity for his design work and is able to only create detailed designs when we have properly defined the problem and scope (i.e. what should be included and not included).

A big part of product development is prioritization. This document has helped us make better prioritization decisions and provide the team, especially James and the engineers, more clarity.

Before I share the template, I want to share our product planning process because the template works well for us, given how we work. It may or may not work as well for you.

For a few years, our product planning process for new features has two steps:

1. Select
2. Design

The select step is essentially Tom deciding what features we should build next.

A lot more goes into the second step. We define the problem to solve, do research, explore designs, and spec up the design for engineering. This was working well for us until we realized we were building new features without a clear understanding of the problem we want to solve. This issue because clear to me when we shipped our Shopify integration. We had a general idea; we wanted to help customers measure their sales. But without a clear understanding of the problem our customers are facing, we shipped a feature that wasn't valuable.

I felt we need to spend more time defining the problem first. Inspired by Ryan Singer's Shape Up, I created a new document for each feature in the pipeline with research about the problem space. I originally called it "Research Brief" but it was confusing because we continue to do research when we design, build, and market new features. James suggested "Discovery Brief", and it just felt right.

Now our product planning process looks like this:

1. Discovery
2. Design

We spend more time on the first step now. The additional investment is worthwhile because it prevents poorly-defined ideas from reaching the design step and being built.

The end goal of the discovery step is to have a well-defined problem and scope. If we can't get to that, we haven't understood the problem well enough and should not spend time designing and building. If we have, we create a detailed design and specification in the design step.

If you want to grab a template of our Discovery Brief, you can find it here.

Buffer's product discovery brief template

We use Dropbox Paper for our documents. If you are using other tools like Notion, there might be features that could replace or enhance the template. I'd encourage you to make those adjustments.

Current status A checklist and progress indicator

This is right at the top of our document to give whoever reading it an indication of the progress. For Tom, James, and I, it serves as a checklist so that we don't miss anything important.

Problem area General problem area we’re addressing, and why it’s important that we solve it now

We used to think we had identified our customers' problems. But they were actually problem areas because we didn't have an understanding of the specific problem. The goal of the discovery process is to narrow down a problem area to a problem statement.

• Problem area: Customers cannot measure the ROI of social media
• Problem statement: Customers cannot measure the number of clicks from Instagram

Another key part of this section is to encourage us to think through why we should solve this now. There are a billion things every software can try to solve but how we prioritize what to solve is important. There is an opportunity cost for every feature we build. If we choose to build this feature, that other feature has to wait. I don't think we get the prioritization right all the time but we at least think through it now.

Customer and market research What customers have told us, and what options do customers have in the market

To narrow down the problem area, we first look at what our customers have told us. There are three sources of information:

1. Feature requests
2. Support emails
3. Our Advocacy team

Our Advocacy team works with our customers every day and has a good sense of how painful a problem is for them. This information generally helps us narrow down to one or a few problem statements.

We also look at how our competitors are solving this problem. This is not about copying what our competitors are doing but learning what options our customers have at the moment.

Prototype exploration Sketches and wireframes, not actual engineering-ready designs

Once we pick one problem statement, we start exploring possible solutions.

Instead of detailed designs, this section encourages James to create sketches and low-fidelity prototypes first. It's likely James already does this previously but it helps to make it explicit in the process.

Engineering input What do engineers think about the possible solutions, and what does the API allow

We also consult our engineers during the discovery process. This serves two purposes:

1. To get more ideas. Sometimes we (the product people) don't know what's possible. Engineers help us realize there's more we can do.
2. To make sure our ideas are feasible. Other times, the ideas we dreamed up aren't technically feasible (e.g. API restrictions). We want to know this as soon as possible before we create detailed designs and definitely before we start building.

I personally like this also because our engineers are involved early in the product planning process rather than simply being given designs to build. The best product engineers also want to help shape the product and often have better ideas.

Problem and scope Defined problem and scope (Who, What, Where, Why and How) to be used for the design brief

Finally, we define the problem statement and scope so that James has the clarity to explore and design solutions to be built.

I have explained the importance of having a problem statement and not just a problem area. The scope is just as important because we want to build something valuable but also doesn't take us months or years to build. The problem statement helps with the scope because it helps us focus on the exact problem our customers are facing.

Coming back to the example I shared above:

• Problem area: Customers cannot measure the ROI of social media
• Problem statement: Customers cannot measure the number of clicks from Instagram

With the first statement, we could maybe build a company to solve that. With the second statement, it gives us something very specific to solve. We could maybe build something in three weeks.

Also, as important as what to build is what not to build. We explicitly define things we will not include in our solution.

If you see any issues or areas for improvement in our Discovery Brief, I'd love to hear from you. Again, you can grab a copy of the template here.

Thank you!