The power of one-pagers
By: Paulo Sigaud Séllos
Tags: Product Development, Documentation, One Pager, Product Management

You are probably familiar with the one-pager concept, but after all, why is this necessary in your product organization and career?

We can read the Google definition of a one-pager above, and it’s something very applicable throughout many different fields. This concept is not something new. We used to work around the PRD (Product Requirements Document), which was a very extensive and detailed document on what to build. Thankfully that evolved into many different things. Many product-oriented (or conscious) organizations have their kind of “one-pagers,” like Amazon, with their “Working Backwards documentation” and the “Press Releases” as well. This kind of document is super necessary mainly for three reasons:

improves decision quality and outcomes de-risks bets encourage better communication and cross-functional collaboration

Would you bet $5,000 of your own money on the success of this effort? Why? Why not? On what terms? For what return? How would we know whether you had won/lost the bet? What might we learn early on that would encourage you to increase your bet to $10,000? Or decrease your bet to $1,000 or $0?

When I joined Nubank back in 2018, the scale of things was very different. We had around 5 million customers, reaching one thousand employees, approximately 200 developers, just about 5 or 6 product designers, and I was the 11th or 12th pm to join the team.

We had no default way around documenting things. If you asked any developer back then where was the documentation for that change or feature, they would reply to you, “the code is the documentation.” This scenario is both good and bad: the good part is we had clean code, which made everybody understand what was happening; the bad, by looking at the code, we couldn’t know why people made those decisions and what was happening at that time. This knowledge remained inside people’s heads. And don’t get me wrong, I’m not criticizing how we used to work there back then; it’s just that we struggled to develop a unified way to use the power of good documentation. It’s also not that we didn’t have any documentation. The problem was that we had several different forms of documentation, sometimes even for the same problem! The main document that I came across was an RFC or a Request For Comments. It was a good way to share knowledge and get feedback, but the problem was that, usually, the documents ended up with 20+ pages, and just a few people read it. In addition, we usually took several meetings with different teams and stakeholders, paralleled chatting in slack, to finally reach a conclusion that was not easy to share around with everyone, again.

But why is this important? What I’m most interested in on this kind of documentation is not the document, the artifact itself but the process. But, of course, the document becomes extremely important in many many ways in the future (gives context for new hires, explains the decision, shows learnings, failures, and successes, keeps a database on tests and ideas, and so on).

The two core activities of a Product Manager and a product team are Discovery and Delivery. I’m not going to argue about which framework is better if it’s dual-track agile, triple-track agile, or any other framework that you care about and find awesome. The point here is that one-pagers are so powerful that they will help you and your team in both the discovery and delivery phases.

Ultimately our job in product discovery is not just to validate the problem, but to come up with a solution that customers love, yet works for our business. What this means specifically is to come up with a solution that is valuable, usable, feasible and viable. — Cagan, Marty

Marty Cagan’s conceptual model showing these two activities happening in parallel

I confess I was majorly influenced by John Cutler on how to think about one-pagers and how to write them. You should definitely check his article here. I won’t go deep into the process of creating the document (I’ll do another post entirely dedicated to explaining that). What I’ll go deeper into is, in fact, the benefits of doing so.