The power of one-pagers
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
I confess I was major 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.
Alice: Would you tell me, please, which way I ought to go from here? The Cheshire Cat: That depends a good deal on where you want to get to. Alice: I don't much care where. The Cheshire Cat: Then it doesn't much matter which way you go. Alice: ...So long as I get somewhere. The Cheshire Cat: Oh, you're sure to do that, if only you walk long enough. —Lewis Carrol, Alice in Wonderland
1. improves decision quality and outcomes
Naturally, this is not something that will happen immediately. Instead, this improvement comes over time when you are persistent and genuine with the process.
But how this happens exactly? It's simple. When you start creating one-pagers to obtain these benefits for your team and your company, you'll have several one-pagers for different problems you want to solve after just a couple of months (this depends on how prolific you are). As they all are evident and similar in structure, it's easy to compare them, which results in a more explicit way of prioritizing your initiatives, improving your decision quality. Your decision quality won't be better in your first attempt, but by understanding how you prioritized and the mistakes you made, you'll learn better what works and what doesn't, hence improving your decisions. The better quality of outcomes comes from the same place. Once you improve your decision quality, outcomes will become better because they are a function of your decisions and execution. The bonus point here is that you'll be able to run faster experiments and accelerate your learning curve, improving decision quality and outcomes as well.
2 . de-risk bets
As a PM, part of your job is to figure out what your team should focus their energy on, what problems to solve, and what not to. The one-pagers are excellent for that because not only you'll be able to prioritize better, you have the opportunity to articulate small tests that will help you understand if you are striking gold.
Jim Collins refers to this as "Fire Bullets, Then Cannonballs."
you fire bullets (low-cost, low-risk, low-distraction experiments) to figure out what will work—calibrating your line of sight by taking small shots. Then, once you have empirical validation, you fire a cannonball (concentrating resources into a big bet) on the calibrated line of sight.
Not a new concept. Jim Collins wrote that in 2011. In our day-to-day activities, it's easy and common to get distracted with the sexier thing to build or get pulled by our own biases on what will work. One-pagers are a "simple" way to come up with several practical things to test and measure to see what sticks so you can double down on it.
Your one-pager helps you iterate on the cheaper part of the process, the planning phase. It's much better to rewrite your one-pager 100x until you have clarity on what problem to solve, with a straightforward way to test and measure its results, than build something that won't prove anything, and you have to fix it in prod.
3. encourage better communication and cross-functional collaboration
I have seen many people who tend to think that the Product Manager is some manifestation of an idea genie. It's probably true that in time, you as a PM will get to know your customers and their problems so well that many ideas on how to solve those problems will pop up in your head. However, that doesn't mean they are good. Not even close. Sometimes we get so close to those customers' problems that we become blind to new solutions and stuck with old ideas.
Truly great PMs understand that their superpower lies in harvesting ideas that can come from anywhere and anyone.
When you start writing your one-pager, it's paramount that you bring your team together to get their inputs and feedbacks. More often than not, you'll change your mind on something that you were thinking about or get a new perspective on the problem you were trying to solve. Everybody can have good ideas and insights. We tend to get in love with our solutions, and we know that it doesn't work. So bring everybody together to challenge your assumptions.
Through this document, you have an easy way to show your ideas around, collect feedback, and report results when you are already testing the solution. It's a living document. This way, you have little resistance to share your thoughts, breakthroughs, and failures. Everybody can learn faster from your failures. And this now goes full circle because as you learn and share, the entire company's decision quality improves. Your reports to stakeholders became much faster and transparent, as does your reliability and trustworthiness.
Your job is to reduce the uncertainty in this chaotic mess; solving customers' problems through technology products and services is not an easy job. This way everybody can help.
The bottom line is: there is no right or wrong way to do this. What's important is that you do it. Just start working with this kind of documentation and iterate it until you get a better version that suits your company's style and needs. Then, you'll figure out the best way to do it with your teams.