Communication is key to being a great product manager, and one of the most common questions we get is, “What are you working on next?”
A one-pager is a great way to align the various departments in your business and ensure that your products have the support they need to be successful.
Table of contents
- What is a one-pager?
- How are one-pagers used in product management?
- What a one-pager isn’t
- One-pager examples
- 4 rules for creating one-pagers
- One-pager template
- One-pager example
What is a one-pager?
A one-pager is a succinct and strategic document, typically restricted to a single page, designed to provide a comprehensive overview of a product, project, or idea to foster alignment and clarity among stakeholders.
Unlike lengthy traditional business documents, a one-pager distills the essence of the matter in a clear, concise manner, making it an essential tool for efficient communication and decision-making in fast-paced business environments.
Presenting key details, objectives, and the value proposition in a condensed format enables stakeholders from various departments to swiftly grasp the essence of the initiative and rally behind it.
How are one-pagers used in product management?
Put yourself in the shoes of a head of sales: a product manager comes up to you and says, “Oh, by the way, we’re launching this big new feature tomorrow. Just thought I’d let you know.”
Your first reaction would probably be to express frustration; only finding out about a new feature the day before release means that you’re now pressured to come up with all of the documentation and training for the team to support this new feature in one day. Have we got the right marketing materials? How do we sell this thing? What does it even do?
There are still so many unanswered questions that it’s unlikely this feature will get the support it needs to succeed. This is a surefire way to frustrate everyone involved in building your product.
As a product manager, there are many different departments that you have to interact with — engineering, sales, customer support, implementation, marketing, etc. — and you need a way to quickly get all of these disparate departments aligned on what you’re doing so they can support the product development process effectively.
A one-pager enables you to distribute a single, concise document that everyone can read and understand to know what’s being worked on. If anyone has a question about the new feature, they can just quickly and easily refer to this document to understand exactly what you’re delivering and why.
What a one-pager isn’t
To better understand what a one-pager is, it’s good to review what it isn’t.
Learn more →A one-pager is not a:
Project plan
Project plans are a relic of the old waterfall way of working — that is, having a specific project plan created by a project manager, with timelines and Gantt charts to show what specific deliverables will be completed and when. These tend to be very static documents and don’t mesh well with the modern way of product development.
Product requirements document (PRD)
Product requirements documents (PRDs) tend to follow a priority system, such as MoSCoW, detailing the specifics of both the feature and functionality. These can be many pages long and are generally used word-for-word as a guide for the engineering team to deliver a new solution.
PRDs are often fairly immutable. They are written upfront and then pushed into the delivery cycle. This is essentially a rebranded version of a project plan.
Business case
A business case generally is a larger, more formal document that outlines financial investment and returns for a product as well as target markets, competition, financial projections, and marketing strategies for a feature. Generally, this type of document is used to get buy-in from an executive team for a long-term project that’s delivered using waterfall.
All of these forms of documentation are outdated and don’t work well in conjunction with modern software development practices. They’re all too slow and cumbersome to be useful, and they tend to be extremely prescriptive with their descriptions. That’s where the idea of the one-pager comes in.
Popular one-pager models
There are a few different ways you can frame a one-pager. One traditional way is to create a succinct PRD, but as we discussed earlier, this type of documentation is outmoded. Even the mere mention of the word “requirements” can be enough to set a poor precedent for the business (think “customer requirements” for a contract deal).
So what are some alternative, more modern models we can turn to?
The Amazon press release
According to Ian McAllister, a Director at Amazon, they use the idea of ‘working backwards’ and start with an internal press release announcing the product. This document gives a high-level view of what the new product will do and how it’s better than previous or alternative solutions. He also mentions that there should be no technical speak or specifications as this is a document that should be targeted at the customers who will use the product, and not just to engineers who might be building it.
Some of the benefits of the press release are that it’s easy to manipulate, understandable by a wide range of audiences, and forces the Product Manager to articulate the benefits and customer problems in a very narrow scope. The fact that this is designed to be a short document also means that it’s easily editable before any technical work gets completed, to make sure that the end result will actually deliver the right level of value to customers that the PM expects.
As with anything, there are also downsides to this approach, one of which is that the press release might corner the engineering team into trying to solve a problem that is technically extremely complex, I’ve seen this happen when someone comes up with a fantastic idea and everyone agrees that it would be a game-changer only to get to the engineering team and find out that you’d have to invent completely new technology to enable it – this could be either complex or even impossible depending on the situation.
The Shape Up pitch document
The Shape Up methodology calls for using a pitch document to present at the betting table for assessment. They describe the pitch as follows:
The purpose of the pitch is to present a good potential bet. It’s basically a presentation. The ingredients are all the things that we need to both capture the work done so far and present it in a form that will enable the people who schedule projects to make an informed bet.
Here is an example of what a pitch document looks like:
The key elements inside the pitch document are:
- Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this
- Appetite — How much time we want to spend and how that constrains the solution
- Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand
- Rabbit holes — Details about the solution worth calling out to avoid problems
- No-go — Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable
Again, there are positives and negatives to this type of one-pager. It is a clear and succinct document that can be shared among the team to gain alignment quickly. It also helps you consider the potential pitfalls of the project and set limits on what you’re going to work on (using the “no-go” section).
The negatives are that this type of document might not have enough of the business side of the proposition to convince other departments of the relevance of the problem to the overall business objectives.
The Lean Canvas
A Lean Canvas is a single, visual document that outlines all the critical aspects you need to consider when moving from a potential idea to a mature business:
The Lean Canvas has become quite synonymous with one-pagers. It sounds great on paper (pun intended), but it’s showing its age a bit when compared to the slightly more modern alternatives listed above.
There is also the obvious fact that a lean canvas tends to be landscape on an A3 page, which is stretching the whole concept of a one-pager in general.
There are also some superfluous sections in the Lean Canvas that can be removed to make it more streamlined, specifically the “unfair advantage,” “early adopters,” “cost structure,” and “revenue streams” information. Those are more business-specific and don’t need to be part of a product development one-pager.
4 rules for creating one-pagers
From the examples above, there are many different ways to approach the one-pager, but it’s important to follow a few key rules:
- Keep it to one page! If you find yourself spilling onto page two, then you need to spend more time understanding the problem so you can articulate it more concisely
- Make sure it includes the core elements:
- What is the customer’s problem?
- How is this problem related to our business objectives?
- What are our solution options?
- How will we measure success?
- The one-pager is a living document. Always be looking to make it more effective.
- Share this document early and often within your business to make sure all departments get a chance to add their input, as well as to maintain strong alignment between all your teams
How to create a one-pager (3 steps)
So the question you’re probably asking is: ‘What’s the best one-pager for me?’
As with everything, it depends. Whichever model you decide to use as a template, it’s important to follow some simple rules when creating a one-pager for your business. It’s likely that the one-pager you developed for a business that you worked at previously can’t be used exactly the same way at the next business, which is where the idea of a living document comes into play.
Being able to use some core ideas and guiding principles means you can create a new one-pager that fits in wherever you end up working, no matter the structure. The steps below serve as a good starting point and template when creating your own one-pagers:
1. Answer key questions
- What is the customer problem we’re trying to solve?
- What’s the current solution (if any)?
- How does this relate to our business objectives (for the quarter/OKRs)?
- What are our solution ideas? (do we need links to tech docs)?
- How will we measure success?
- How do we market this?
2. Share early and often
There’s no point in developing a streamlined one-pager that is still only siloed within the product management team. It’s important that as soon as there’s enough content in the document, it gets shared amongst all the different departments so that they can comment and add their feedback and knowledge before it gets to any prioritization meetings.
3. Create a living document
There’s nothing worse than putting something into practice with the idea that this is the final answer and never evolving it. This is the pitfall that companies have fallen into over the last 30 years with software development, so it’s important to not let that type of thinking seep into other areas of the business, such as when we document problems to be solved by our business.
One-pager template
Use the following template should help you get started building a one-pager:
- Customer problem
- Write a concise description of the problem that the customer is facing here.
- Are there any existing alternatives?
- Are customers using a workaround? Can you manually do this in the background for them? Are there any third party apps that they are using to get around this right now?
- How does this relate to our business objectives?
- Why is solving this problem right now important for our business? What objective are we looking to hit by solving this problem?
- What’s our solution idea?
- Describe a basic solution idea, maybe a wireframe or fat marker sketch. If you need more detail you can link out to a technical document done by an engineer.
- How will we market this?
- What marketing materials will we need to launch this? E.g. FAQ, how-to, pricing, marketing site updates, updated sales decks, etc.
- How do we measure success?
- What metrics will we use to measure whether or not we’ve successfully solved this problem for our customers?
You can access this one-pager template as a Google Doc here (to use the template, first select File > Make a copy from the main menu).
One-pager example
The following is an example of what a one-pager might look like for a new product feature:
- Customer problem
- Many users struggle with organizing their saved content, leading to inefficiency and frustration.
- Existing alternatives
- Users currently use third-party bookmarking tools or manual folder systems, which do not integrate well with our platform.
- Relation to business objectives
- By addressing this problem, we aim to increase user engagement on our platform by 20 percent and reduce the churn rate by 5 percent within the next quarter.
- Our solution idea
- Introduce a “Smart Organizer” feature that automatically categorizes saved content based on keywords, source, and user preferences. [Link to wireframe]
- Marketing strategy
- Launch a teaser campaign on social media highlighting the benefits of “Smart Organizer”
- Host webinars to demonstrate the feature and gather initial feedback
- Update our FAQ section, create how-to guides, and integrate the feature’s details into our marketing materials and sales decks
- Measuring success
- 25 percent increase in saved content within the first month
- 15 percent reduction in third-party bookmarking tool mentions in our feedback system
- 10 percent increase in user satisfaction regarding content organization
Key takeaways
For product managers, a one-pager is one of the most effective ways to achieve alignment between different areas of your business and rally teams around a singular customer problem that the business wants to solve. It is a modern form of internal communication that is much more concise and effective than old methods such as PRDs and project plans.
When coming up with your one-pager template, there are quite a few examples out there with different structures, from Amazon’s “press release” approach to the Shape Up “pitch document” method. But what’s more important than using a template is that the content works for your specific business situation.
LogRocket generates product insights that lead to meaningful action
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
