Got PRD? The Who and Why of developing a Product Requirements Document

Time and time again, I see engineering teams approach me all bright eyed and bushy tailed with a great idea and a slick prototype, asking for help to bring their product to mass production. These are the teams I enjoy working with the most - those that understand there’s a significant effort to get a product ready for manufacturing. My first request is always for a copy of their PRD (Product Requirements Document), so I can figure out how to best help them. This is when their bright eyes turn into blank stares.

So many engineering teams will already have developed a prototype without any written list of specification requirements. This is a certain path to wasted time and capital - both of which, most startups don’t have a lot of.

The Why

I can’t stress enough how important it is to have a PRD for your product. Without a ratified PRD, too many details become ambiguous, forgotten, or simply misunderstood. For those familiar with the Software Agile methodology, I refer you to the requirement of well written User Stories. A PRD has similar goals.

As a <blank> I need <blank> so that <blank>.

I posit these questions to you:

  • Without a written and approved list of specifications, how does your engineering team know what to develop? 

  • Without a comprehensive list of features, how does your sales team know what to tell customers? 

  • Without forecasted volumes and costs, how can a manufacturing team optimize the production line?

I’ve seen engineering teams talk about their vision for the product, then start prototyping it only to figure out several features were not developed how they were originally envisioned. The team misunderstood the intention of the feature, because it was not written down with metrics to evaluate against.

The Who

Which brings me to my next topic: Who are the key stakeholders for the PRD? While the engineering team will likely become the most familiar with the requirements over time, several other key people are critical to get involved as well.

  1. Product Manager - The PM is actually the primary author of the PRD. It’s their responsibility to put pen to paper the final vision of the product, incorporating input from all of the teams: engineering, sales, marketing, management, and even customers. While the leads of each of these departments have specific contribution responsibilities, it’s the PM who will aggregate their inputs and make the final decisions.

  2. Engineering Manager - The engineering team is responsible for being the reality check. Can the features outlined in the PRD be developed without defying the laws of physics, in the timeline requested, and for the targeted costs? Sometimes a small R&D effort is required to answer these questions first, before the PRD can be finalized. That’s ok. It’s better to use a small amount of resources early to answer these questions rather than wait until it’s too late or too costly to recover from.

  3. Sales Manager - The sales team needs to determine if customers actually want the features listed in the PRD and if any fine tuning is required to ensure an optimized product-market-fit. The sales team is also responsible for determining how much customers are willing to pay for the product, as defined.

  4. QA Manager - The QA team needs to see early versions of the PRD so they can ensure they have the right resources to test it, and estimate any associated costs to procure them. These peripheral costs are often neglected when calculating the actual cost to develop, test, and manufacture a product. Test equipment can get expensive quickly!

  5. CEO - The CEO needs to review the product roadmap outlined in the PRD to make sure it aligns with the company vision and consistent with the business model.

None of these disparate teams should work in isolation. Developing a PRD is a company wide effort, which involves several conversations and debates. Believe me, people’s negotiating skills will definitely be tested when the engineering team reports back that the features are too expensive or will take too long to build, and the sales team refuses to raise the price for the customer or remove a feature, and the CEO mandates the product be on store shelves within 6 months. 

This Engineering-Management-Sales team triad will need to roll up their sleeves and work together, iterating on the specifications until all three teams are happy with the outcome. The Product Manager is the ultimate tie breaker and records the final decisions.

What’s in a PRD?

So, what’s in a PRD? Well, remember, the PRD should be detailed and exhaustive enough such that every team can find everything they need to complete their responsibilities. More specifically, the PRD enumerates all the features a product will have, to what performance metrics they must comply to, how many units will be sold, at what price, with what landed cost, and on what timeline.

In Part 2 of this series, I will describe these specifics in more detail.