“My father was very sure about certain matters pertaining to the universe. To him all good things-trout as well as eternal salvation-come by grace and grace comes by art and art does not come easy.” ― Norman Maclean, A River Runs Through it and Other Stories

Like many things Bezos, one pagers found their way into the press. Often the titles suggest if you just do this one thing you’ll be able to get out of powerpoint hell, make products faster or fix insert_traditional_orginizational_challenge_here. Trying to find out how to harness these benefits is less easy. There are some articles out there about what it means to write one, what the format is, how to avoid wimpy words etc.. but like any practice, and it is a practice, this doesn’t really help you truly understand them. Working with a bunch of ex-amazon leaders has been helpful so here’s a story about my first one-pager.

To start with, I was given a short example and an article. This included such helpful tips as what font to use (10pt courier) and how to shrink the margins a bit in case you needed to include more information. I love learning new techniques so I dove in straight away and started writing about a new product we were going to build. The product included non-trivial software and hardware elements so it really could use some clarity. In one page I sought to define the thing that we would build in a way that all the members of the team would understand. I wrote several sections that provided business context, user context, basic assumptions, features and integrations. By the time I was done it was three pages long but it described something and I thought it was a lovely document.

Then I had a first review with the product team. At this table sat the UX researchers, designers, TPMs and other PMs on our team and at the head of the table was our fearless leader, who introduced us to one pagers in the first place. We printed out copies for everyone, put a bunch of red pens in the middle of the table, shut down our devices and read/took notes for at least 20 minutes. This meant the room was quiet. It was almost like church. It was also the first time I read a printed out copy of my work even after at least five drafts and I found several errors or needed clarifications in this new found quiet space. That was eye opening by itself. How many times in the past had I written something online, drafted and redrafted, only to miss something? For important documents, I now make it a habit to print them out and red pen them at least once or twice. As a creature of muscle memory something wakes up in my subconscious when I have a physical piece of paper and a pen.

What happened next was the relentless shredding of my work. We went section by section through the document and my teammates would ask questions or point out improvements in my thinking. By the time that first review was done I knew there were large chunks to be rewritten. Those pieces had to become more clear and where there were questions remaining, they either needed to be called out as outstanding or answered before the review with engineering. The entire process was a bit embarrassing in some respects. This was a business line I’d had experience in for nearly five years, I knew it soup to nuts and I thought I was pretty good at describing what we should do. I was a senior member of this product team and saw myself as a leader and someone who delivered good work products yet here we were taking one that I’d crafted patiently apart. The thing that made this one of my fondest memories is our team had a lot of trust in each other and everyone was there to help me succeed. When I reflected on that fact, and the other things I’d learned, I was pretty humbled and grateful. No matter how senior you are or how experienced you are you can always get better and I couldn’t have done it alone.

The next review was with the engineering teams, four drafts later. Once again there were hard questions, things that a new perspective might think through and improvements to be made. As the builders of the product they were even more pointed at times, seasoning the narrative with elements of technical feasibility or offering suggestions on how better to frame the features so that they would meet the business or user needs. Again there were red pens and silence but after we negotiated what would be in and out of scope we had a written record to what was agreed. It was also an opportunity for everyone working on the product to have a voice in what it would be. That paid huge dividends when we started the nitty gritty of building it.

When I recall that first one pager, I think of a friend of mine who joined Amazon. He told me one day about a document he was writing, “I’m on review 26!”. I had lunch with him after he’d been there a while longer and he kept talking about how it’s made him “such a better writer!” and I think that’s really the key to these things. Writing well is art. When my kid plays her trumpet every day it’s to practice her technique. When she is on stage and performing, that too is practice as performance. Both are doing the work and being mindful about doing it better or doing it well. That’s really the only true secret to a one pager. You write them thoughtfully after learning as much as you can about the topic and synthesize them over and over again into something that will speak to your team. Then you sit and review it together until finally everyone hears the same music.

Since that first one pager I’ve written at least a score more. I’ve also written a few six pagers, the difference being that a six pager is used to flesh out a buy vs build or other more complex decision. Over time, teams change and leaders change. I now work with as many leaders who came from Microsoft or elsewhere as Amazon so we talk about PRDs and our documents have flexed and changed with that. One pagers now exist in our wiki although I still reserve the use of Word Online for Six Pagers and their ilk so that we can print them out. The reviews are still brutal and help us refine our thinking. They also give us a place to debate in a public setting and allow folks to disagree and commit if need be. Basically we continue to fiddle with their format, storage and processes but this is in service to making them work for our org. We’re not Amazon but it doesn’t matter. What matters is that we never stop improving our practice because that’s really what these documents are all about.

PRACTICE!