How to Improve Product Team Alignment with One Simple Tool
--
Chaos. Our product grew so quickly we added two more product managers and split into three teams. Engineers on one team were blocking development of another. A third team was building a feature that had already been partially created by another. Product managers were saving tons of customer information in places no one knew and in ways no one would understand. We were all working on the same project, yet we were completely siloed from each other. Are you feeling the anxiety yet? Me too.
On a train following the blues and greens of the Burrard Inlet, I’m listening to an episode of Build by Maggie Crowley, called “What’s a One Pager?”. I highly encourage you to listen to it for more context, tips, and story. If you want to skip straight to the Spark Notes, read on.
The one pager seemed like a godsend, and like a super obvious solution to our problem we should have implemented ages ago. But when you’re knee deep in deadlines and legacy code, sometimes it’s hard to see what’s right in front of you.
Using a one pager to define a customer problem helped us focus on our users, increase alignment among PMs, and increase engagement and ideation across the entire team, not to mention simply deliver a better product. And the greatest thing — its free, easy to implement, and completely adaptable!
Below I describe the one pager, however, the key to this process is that you must meet with your team to tell this story and collaborate on understanding and solving the problem together.
What’s a One Pager?
A one pager is the first step when starting a new project to help you (the PM) define and scope a customer problem.
It is a well researched story used as a tool to arm your team with information that will help them understand the problem and come up with a solution.
Tell your audience a story.
The audience for this story is your team (engineers, designers, other PMs), and stakeholders. Write this document for your readers and in a way a person without context or technical knowledge can understand it.
Show, don’t tell — the more pictures, direct quotes, examples, graphs, the better.
⚠️ A one pager is not a description of what you’re building, a list of requirements, or a list of features.
Start with the Story
The story is the most important. To start out with, describe who your customer is and what this experience or problem means to them. Zoom out from your product — what is the customers ultimate goal? Write this story in a way that is compelling and succinct.
Try using Jobs To Be Done as a tool to convey what the customer is trying to accomplish. A very simple format would be “When __, I want ___, so that I _____.”, but please read more about the goal and theory behind JTBD.
Tips
👉 Don’t rush this part!
👉 If you need multiple paragraphs to explain this, you probably don’t have enough of a grasp on what it is yet.
👉 You may have a few revisions on this as you learn more.
⚠️ If you’re trying to write the story in a way that it fits into some bucket or under some goal, that’s a warning sign.
Background
Expand on the story and why your audience should care. Add any lessons you’ve learned and why this problem is relevant to your business.
Add any direct quotes from your customers, insights, screenshots etc.
Goals
Add numbers based goal(s) and the impact it’s going to have on your product.
For a whole other post on goal-based product planning, check below.
Requirements & Constraints
⚠️ This section is not what you should build.
This section helps scope the problem (e.g. cannot impact x other product; do in scope of these parameters). Help your team narrow the focus.
List any risks or dependencies, and capture any open questions from you or your team, and anything that you already know might be a roadblock or risk.
Timebox
This is where we understand how long this should take to build and help you and your team prioritize. Devote a reasonable amount of time to solve this problem depending on how important you think it is (e.g. a quarter, sprint, week, day). Communicate when you expect to hope to accomplish this project.
Concepts & References
For this section, list and link all the research you’ve done so others can use these resources to learn more. Literally every single piece of useful information (e.g. who’s already built a feature like this, any additional quotes etc). It’s also helpful to add any design concepts to this section once you’ve taken a stab at concepts and iterations.
To go along with this post, I created a template document containing an outline and description of the One Pager.
Back at the office
Now can you see how the one pager would unite our team, help us put our customer problems first, and streamline the sharing of information, cross functional skills, and ideation to solve a problem as a team?
Adoption of the one pager was easy and painless, as none of us were afraid to admit that we had a problem, and it was just so simple to start implementing. The meetings invited the engineering and design team to be much more involved in the product process, and in turn the customer empathy and cross board ideas elevated the quality of our work and our product.
👏 Yay happy ending.
Have a similar process or a way you’re improved or adapted this tool? Let me know in the comments.
