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.
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.
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.
To better understand what a one-pager is, it’s good to review what it isn’t.
A one-pager is not a:
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 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.
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.
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?
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 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:
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.
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.
From the examples above, there are many different ways to approach the one-pager, but it’s important to follow a few key rules:
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:
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.
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.
Use the following template should help you get started building a one-pager:
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).
The following is an example of what a one-pager might look like for a new product feature:
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 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, Product, UX, 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.
Learn how to use Fibonacci story points for Agile estimation, avoid pitfalls, and explore alternatives like T-shirt sizing and #NoEstimates.
Randolph D’Souza talks about how he works to align different teams together, such as product, OEM engineering, and sales.
Understanding the root causes of project bloat is essential for aiming to improve productivity and streamline workflows.
Mahesh Guruswamy shares experiences learning from and coaching others on how to have tough conversations and how this inspired his book.
Learn more →
