ProductFTW #13: Mastering the Art of Requirements: PRDs that Actually Work

Ah, the PRD. The bane of every product manager's existence. We've all been there, staring at a blank screen, wondering how the hell we're supposed to dump all of our product knowledge into a few measly pages. And then, once we've poured our heart and soul into it, we watch in despair as it sits untouched in a dusty corner, never to be read again. Folks, let's be real—most PRDs are about as useful as a screen door on a submarine. They're long, boring, and often ignored by everyone except the poor sap who had to write them—you.

But fear not, my friends, your PRDs don't have to suck. Today, we're going to explore the art of crafting PRDs that actually work. We'll dive into the essential components of a PRD, explore tips and tricks for making them concise and compelling, and uncover the secrets to getting your team to actually read and use them. Let's go!

What’s a PRD?

At its core, a Product Requirements Document, aka PRD, defines what you're building, who you’re building for, and how it addresses their needs. It's the blueprint from which your product team, designers, and engineers draw inspiration and direction. Critically, in a startup environment, it's less about rigid specifications and more about guiding principles that evolve as you build out your product. 

I like to treat PRDs as living documents until the product or feature has gone live because things will inevitably change as we start designing, building, and getting feedback from people. But we're getting ahead of ourselves: Let's start with the core components of a PRD before we talk about how to use them effectively.

The Non-Negotiables: Essential Elements of a PRD

You'll find infinite PRD templates online. Most are bad, some are good, but nearly all of them overcomplicate things. The best PRDs are short and to the point, especially at an early-stage company. Yes, documentation is important, but you don't need to spend all of your time trying to make it perfect–spend it talking to customers, building reports, analyzing data, coding…do literally anything except spending too much time writing the PRD.

Assuming you know your product well, you should be able to create an entire PRD in less than a day, especially if you focus on just the essential elements of a PRD. The most straightforward PRD has only these sections:

• Problem to solve: The "why" behind your product or feature, articulating the issues the feature or product the PRD aims to solve. This is critical because it ensures that everyone understands the purpose and value of what you're building.
• Objectives and Success Metrics: How do you know you've solved the problem? Whether it's increasing sign-ups, reducing churn, or whatever metrics are most important to your business, you need to identify two or three clear goals with measurable outcomes that define what success looks like. These metrics will help you track progress and determine if your product is actually meeting its goals. 
• User Persona: Who are you building this for? This is just a sentence or two detailing your ideal user, ensuring that you're focused on real user needs. Understanding your target audience is crucial for creating a product that people will actually want to use.
• Requirements: A high-level overview of the product's must-have features and functionalities. Requirements should be numbered and written in plain English. You should also include any applicable Acceptance Criteria. For example:

With these four components, you should have more than enough information to get you and your team started toward building your sweet new feature.

The Bells and Whistles: Optional PRD Components

While the essential elements of a PRD will get you pretty far, complex, more mature products may require more thoughtfulness. These "supplemental" sections of a PRD will provide the specific details that bigger, cross-functional teams may require, particularly when dealing with a lot of features or products. This is not an exhaustive list, but some of the more common things to cover include:

• TLDR: A snapshot of what the PRD contains, ensuring an immediate understanding of the product vision. This is especially useful for the people who won’t take the time to read the entire PRD (e.g., everyone). 
  • Keep it simple: “We are solving this problem for this person, and it needs to do X, Y, and Z. We are measuring success by 1, 2, and 3.”
• User Stories: Detail the explicit scenarios that describe how your User Personas will interact with your product, adding a human element to the requirements. (link to use story article). 
  • These stories help your team empathize with the user and create a more user-centric product.
• UX: Initial thoughts on user experience, typically a set of wireframes, acknowledging that the final design will evolve. This gives the team a starting point for the design process and ensures that everyone is on the same page about the general look and feel of the product. 
  • Once the final mockups have been created, embed or link out to them in this section.
• Technical Considerations: You probably touched on some technical elements in the Requirements section, but a deeper dive into the architectural and technical requirements is critical so that the engineering team knows not only what to build but how to build it. This is particularly important for complex products that may require significant engineering effort or deeper external integrations where outside collaboration with a partner or vendor is needed. 
  • You might take a stab at this section, but typically, your engineering counterpart should be responsible for it.
• Scope: The boundaries of what the product will and won't include are crucial for maintaining focus. Define at least the MVP and major follow-up releases as well. This helps prevent scope creep and ensures that everyone is clear on what will be delivered.
• Timeline: A flexible schedule that anticipates adjustments as the project progresses. Call out the major milestones, like design completion, UAT, launch, etc. While timelines are likely to change, having a rough schedule helps keep the team accountable and aligned.
• Risks and Assumptions: Potential hurdles and assumptions that could impact the product's development. Identifying these early on can help the team proactively mitigate risks and make informed decisions.
• Go-to-market: Define how you will launch this feature and get the word out. This ensures that the product launch is coordinated with marketing efforts and that the team is prepared to support the product once it's live.

I don't recommend including most of these things in your PRD at an early-stage startup unless you feel like it's needed to get buy-in or aid in comprehension. These items are still (mostly) important, but you'll figure most of them out on the fly. Overthinking it too much before collaborating with your team will just end in heartache. Odds are pretty good that your engineering team will tell you that one sweet feature will take six months to build, so you can throw everything related to your timeline, scope, UI, and GTM out the window.

I created the PRD: Now what?

With that PRD in hand, step one is done: score! Now, only…99 more steps to go. Once the PRD is written, the focus shifts from planning to action, iteration, and collaboration. We won't go deep into the full development process in this post, but the general sequence looks something like this:

1. After you've got a draft PRD ready to go, you need to share it with your team and key stakeholders, including design, engineering, sales, marketing, and customer support. This review process is crucial for alignment, identifying oversights, and getting different perspectives from others throughout the business.
   1. When nobody gives you any feedback because they forgot to read it, shed those cats into a meeting to walk through it in real time.
2. Take that feedback and incorporate it into the PRD. Now, with general alignment, engineering will start to identify the technical specifications, and design can start creating the mock-ups. Add those things back into the PRD.
3. Development begins.
4. As features and major components are completed, you should test them against the requirements in the PRD. 
5. If possible, test things out with some users before launch. This may result in some changes to the product based on their feedback- go back and update the PRD to reflect those changes.
6. Once everything meets requirements, has been thoroughly tested, and you've gotten some user feedback, you can pick a date to deploy your new feature.
7. Generate some buzz and launch that bad boy.

This is an incredibly abridged version of what actually happens, but hopefully, you get the idea. Throughout this process, treat the PRD as the source of truth. If that truth changes, be sure to go back and update the PRD. It's critical that the PRD remains the single artifact that everyone refers to, and the only way that's going to happen is you keep it up to date.

Other Tips

Now that you have a solid understanding of what goes into a PRD and how it fits into the product development process, here are a few additional tips to keep in mind:

Embrace the Journey

Remember, your initial PRD doesn't need to be exhaustive. It's a living document meant to evolve. Start with a clear problem statement, objectives, user persona, and requirements. As your project unfolds, so will your understanding, allowing you to beef up the PRD with newfound insights and refined details. Don't be afraid to update the PRD as you learn more about your users and the problem space.

Acknowledge the Unknowns

You will not know everything in your first PRD draft, especially if you use some of the Minor Components. Mark those sections that require future research or decisions with placeholders like "To be determined." For example, if you're unsure about the technical feasibility of a particular feature, you might write "Technical architecture TBD pending engineering review." This transparency can foster a culture of openness and collaborative problem-solving. 

Collaboration is key

Even in its early stages, sharing your PRD can spark valuable dialogue. Feedback from your team can validate assumptions, unearth new ideas, and help prioritize tasks. Don't be afraid to share your PRD early and often, even if it's not perfect. Remember, the goal is to create a shared understanding and get everyone on the same page, not to create a flawless document. This collaborative spirit is a key facet of a startup's agility.

Closing Thoughts

Before we wrap up, let's hammer home a few final points. Remember, a PRD is not a one-and-done kind of deal. It's a journey, a story that unfolds alongside your product. Embrace the twists and turns, the updates, and the pivots. Use your PRD as a tool for alignment, a springboard for collaboration, and a reality check when things start to go off the rails.

But most importantly, don't let your PRD become a dusty old document that no one reads. Keep it fresh, keep it relevant, and keep it real. Share it with your team, listen to their feedback, and don't be afraid to make changes when needed. A good PRD is like a trusty sidekick—it's got your back through the good times and the bad.

Finally, there are a handful of useful AI tools that can really help you create a PRD in no time. Check out ChatPRD, find some GPTs for ChatGPT, try LennyBot, or ask for help from Claude. Work smarter, not harder!

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it. Brought to you by the team at Totavi.