Writing effective One Pagers

When building a product or a feature for an existing product - an important aspect of this is execution i.e. working with your teams to build this and get this out in front of a paying customer. Most organizations today rely on what is called a Product Requirements Document (aka PRD) which contains a whole bunch of things about the product (or feature), right form what problem the product will solve, how it should solve, etc.

Writing a PRD is a long and arduous process. There is a lot of research, planning, analyzing and discussion involving multiple stakeholders. Organizations that follow a PRD consider this document to be one of the most important document when it comes to building a product/feature. Depending on the organization, the PRD template will contain several items or requirements that should be captured making way to PRD templates that one must use. There are many people (including me) who believe that using templates are akin to being punished.

According to Marty Cagan:

I think the source of the issue is that so many product people have been led to believe (and wish to believe) that there’s a framework or template for everything. But product is very much about judgement.

Before I digress, let me continue talking about PRD. In general, PRD’s are great, they can be a good document when you are trying to build a new product. The PRD should focus on things like problem you are trying to solve, or an innovative tech that you are looking to commercialize, marketing segmentation, beachhead strategy, personas, high-level specs, value proposition, competitive landscape, DMU, business model, pricing framework, assumptions, and finally an MVP.

In my opinion, these documents are not great when it comes to product execution. Also, if you boast about being agile, writing a PRD before any work can begin is an indication of a waterfall (water-gile) model. You cannot expect the engineering team to read 30-40 pages of PRD and churn out a MVP.

Introducing the One Pager

I prefer writing one-pagers when it comes to execution. A one-pager is a document that allows you to share the problem that exists for your customers and why its important to solve it. The idea is to communicate the idea, goal and feature in a single page. This allows you to create a shared understanding with your team. When it comes to execution, this shared understanding is the most important aspect of creating good product.

I have followed Jeff Patton through out my product management career and as you can say I’m a big fan of User Story Mapping. In his book about User Story mapping, he talks about the concepts of one pagers. According to him:

The goal is not to manufacture certainty or pitch what you think is the right solution. But a good one-pager takes a data informed perspective on risk and return.

You know your one-pager is working when it sparks a conversation and interaction within the team. These conversation help create shared understanding around values, outcomes, impact, opportunity, viability and risk. As they are short, they are easy to consume, and most importantly the teams remains focused on the task.

Another aspect of one-pagers is that they make your teams self-organize; which is an important aspect of agile product management (more on this later).

A good one pager should have the following covered:

1. The problem: These one or two lines that describe the problem of your customer is probably the hardest part of your job. Nailing this down is half the battle won.
2. Background information (context): The fact that writing problem statements is hard is because when you discuss them with your team, they have very little context. Stating problem statements on their own. Giving them context about the customer, their business, the way they work makes it very easy for your team to understand why the problem exists.
3. Success criteria: Define these very clearly. Use numbers if you need to. Your team needs to know what will be considered a success i.e. the customer should be able to do at least task a & b.
4. Requirements & Constraints: These are helpful as the team needs to be aware of any constraints. These could be hardware, software or even environment constraints.
5. Timebox: You don’t want to be building a feature or product for 6 months to a year. Customers expect results and remember you told them you are an agile company. A good rule of thumb is to limit your scope to about 4 weeks of work. If your problem statement scope is too large, write a different one-pager.

Again, do not use the above as a template; rather treat it as a starting point. Over the years depending on the team you work with or the feature you are building, your one-pager will take a different shape. Use your judgement and don’t punish yourself by using templates.