By Daniel Wu – An ideal PRD discusses users, shows features in a visual prototype, and includes key hypotheses. Product Requirement Documents (PRDs) are documents product managers use to achieve several important objectives. They (1) create purpose and context for the teams they work with, allowing key stakeholders to feel heard; and (2) clearly communicate the vision.
Experts in the industry, however, believe PRDs should be eliminated for several reasons. PRDs, they believe suffer from two big problems. The first is bloat. Product managers (PMs) collect discussions about product and long documents are rarely read. The second is rigidity. PRDs are also seen as inflexible documents tied to the “waterfall” development method. PRDs assume a number of features that users want, and are not updated quickly enough to create a useful product.
Given these criticisms, PRDs should change in two ways:
- To address bloat, PRDs should clarify that a clear vision also implies concision and relevance. PRDs should not exceed 6 pages — in fact some, such as Atlassian, advocate for single-page PRDs. These PRDs also have prototypes that lay out the user flow and a visual prototype, creating further clarity. Furthermore, PRDs should be relevant, with different levels of detail and content for different stakeholders.
- To address rigidity, PRDs should be the opposite: flexible. In order to match what users want, risky assumptions should be constantly validated and features updated. Furthermore, PRDs should be combined with adept project management tools that adapt to new information.
To optimize these objectives, I outlined the core features of the ideal PRD and suggest that Atlassian’s 1-page PRD (see screenshots below) is a great starting point.
Create shared purpose. We create products to help users and solve their problems. Without a description of those users’ use cases, team-members will not clearly understand what they are building for. In other words, the objectives section summarizes the key components of what product managers call a “market requirements document.” Atlassian’s PRD discusses those user stories and clearly prioritizes that features that come out of that story under the “Requirements” table on the first page. Furthermore, the section “Not Doing” on the second page provides rationales for feature choices that were explicitly discarded. By making those clear, teammates will not go backward on those choices, increasing efficiency and sharpening the product vision. Finally,
Communicate the vision clearly. What better way to communicate product vision than to literally draft a very basic prototype of the product. The PRD can include a user flow that shows how users interact with the product; a marvel prototype would be helpful here. Additionally, the PRD should consider corner cases, but not let these define the product. By corner cases, I mean low-probability set of user choices that can harm a user’s experience. Atlassian’s PRD also addresses this concern. The section “User Interaction and Design” features the prototype mockup. This prototype can be made even clearer by using tools like Invision or Marvel that allow users to interact with the prototype dynamically.
Embrace flexibility. Lean startup method advises founders to consider and test risky assumptions. PRDs can draw from this insight and create a plan or even use data to start testing these assumptions. These prototypes can also be subjected to user interviews, with the PM sitting down with users and observing how they use the prototype.
The section “Questions” on the second page addresses these concerns. For instance, after analyzing the data linked under the first page “Customer research,” the team noted that the lack of demand for Blackberries or offline modes for the app.
Case in point
In one example to develop roommate software, inspired by Lean Startup and Agile methods, my developer and I recognized the downsides discussed above. Users may not know what they want and then ultimately be dissatisfied with what they receive.
Thus we drew from the principles of Atlassian’s PRD. Test our visual prototypes as early as possible. Then adjust our prototype. This way, we could feel confident about when we increased the fidelity (and corresponding cost) of our prototype.
As the product lead, I first used various qualitative methods, such as social listening of forums and interviews, to understand what our target user — recent university graduates — wanted in their roommates. After brainstorming a set of key methods after listening to people’s problems, I used a larger survey and google ads to test which features people cared about the most and whether these problems were generalizable.
Through this, I discovered that users distrusted many existing roommate websites, and were especially concerned about verifying whether roommates were trustworthy.
That’s how the “must have” requirement of verification emerged.
Here’s the user story premise: “When roommates evaluate strangers to room with, they use various techniques to verify trustworthiness. They use social proof, such as referrals from friends or university-based facebook groups, and see if there is a cultural match, using video or in-person interviews.
Using Sketch, I drafted mockups in about a week and showed our key user who we examined using the product and gave us further feedback. This mockup, of course, also achieved clarity in communication with my developer. He knew exactly what we wanted to build. I adjusted these designs to make them more feasible, given his skill and resources.
Example visual mockup I created and showed to user – akin to Atlassian’s visual mockup.
We rinsed and repeated until we kept receiving similar set of comments from our target user. Using this feedback, we ultimately layered on more functionality to create a working website.
Functional fidelity prototype, after balancing feasibility and user needs
This helped us create something our target user enjoyed. Friends of mine shared this with their own networks — strangers I had never spoken to — but would likely be a target user. Fortunately, we received positive feedback, helping us feel more comfortable we were building something people needed.
Positive feedback from strangers who were our target user.
Ultimately, a PRD is a tool that helps teams — with different jargon and priorities — to communicate better with each other and their target users. The PRDs are in need to be sharpened, and Atlassian’s example is a great model on which to remind ourselves to test prototypes early.
Header image photo courtesy of Ylanite Koppens from Pexels.
Daniel Wu’s bio – I’m a startup lawyer and have my JD/PhD from Harvard. I’m passionate about the way law, technology, and design can advance affordability in housing. Please see my linkedin for more details and other writings on medium here.