Single one pagers have been touted as the only documentation needed to kickstart product development teams at Facebook. The rationale is that this forces the team to engage in continual dialogue as the feature is being built. My belief is that this is erroneous and lazy, that any project should start with a succinct TLDR of the goals and objectives of the feature, followed by the continual documentation of the PRD until completion. The exercise of writing a thorough PRD exposes holes in logic & reasoning that are caught and addressed early on.
It wasn’t long ago when I was working at a high-growth startup. We had a large volume of users driven primarily from our brand marketing and we wanted to capitalize on some form of natural growth levers to continue the momentum. I had produced an exhaustive list of methods in which we could achieve this — 55 to be exact.
However leadership felt it was worth bringing in a Product consultant — one with a very impressive background (he’s easily one of the top serial entrepreneurs out there). When speaking with him, he produced a PRD he used while at Facebook, and it was essentially 2 pages of content that conveyed nothing. It gave the high level of what was to be achieved, but none of the specifics. We asked the consultant if the PRD was complete and he said that it was — this was how Facebook does it.
Facebook’s reasoning is fair — they want to keep PRDs light in order to encourage the teams to be in constant communication as the project takes form, but I disagree with this approach.
A PRD should not be an exhaustive document just for the sake of it, there needs to some flow to it. The top section should act as a memo, distilling the basics of what is being built, why, the problem it is solving, the impact, and the expected resourcing & timeline. This is to be circulated to all key stakeholders in order to align on the general approach of the product before moving forward.
It is at this point that the PM should begin writing the rest of the PRD, keeping it light for now until they meet with their core design/development team to brainstorm on potential approaches. It is important to include the stakeholders in this process, or you’ll get subpar work from a team that feels they had no buy-in. As designs get kickstarted, the rest of the PRD should be filled out with more succinct requirements.
Up until the PRD and the designs are ready for engineering handoff, the PRD should contain particulars around how we plan to rollout, how we scale back the feature in the event something is buggy or fails, details around event/property instrumentation, testing plan, and more. There shouldn’t be many surprises in producing this thorough documentation, good and consistent communication with the team would have already covered these areas in discussion — but having it documented in this way is great as a form of knowledge transfer, as an artifact for the customer support or sales teams to use, and just a great way to clarify your thoughts.
The more thorough the PRD, the more you can ensure every edge case was accounted for and all surprises are laid to rest. This is the product of clear thinking and it would be a disservice to right an awfully short PRD for the team.