top of page

Is the PRD Dead?

Michael Marks

Updated: Nov 11, 2022

I've had 2 clients' Engineering departments recently ask for long-form Product Requirements Documents (PRD), stating it is their preferred method of receiving requirements from Product Managers. The Agile PM in me thought that we killed PRDs long ago in favor of writing requirements as epics/features/user stories. (Of course, written requirements comes after a lot of collaboration with Design and Engineering to establish necessary context, prioritization, prototyping, experimenting, and healthy negotiation.)


So why is it that 2 very different clients are asking to "revert" back to the old ways of developing software?


There are 2 reasons:

  • Misunderstood definition of "what is a PRD?"

  • Lack of collaboration early in the discovery stage


Misunderstood definition of "what is a PRD?"

Engineering lacks the vocabulary to state what it is they really need from Product. When they state they want a PRD, they are really asking about context about the feature and how it fits into the broader product offering, what this feature's end-to-end user journey looks like, and what the goal is that we're looking to accomplish with this new change. Essentially they want to know why this is the most important thing they could be working on right now. What they receive in the form of tickets is not meeting their needs to understand the "why?" behind the feature. Answering "why?" can be done in multiple ways, and is usually not best addressed in a 20 page PRD that lists every requirement and acceptance criteria in minute detail.


What to do about it:

Lack of collaboration early in the discovery stage

Some Product Managers write requirements as epics/features/user stories that make Engineers feel like ticket takers. PMs are not taking Engineers along on the discovery journey and getting their buy in. The best Engineers understand why their service is so important to their customers, and how new features will make their users' lives better. Resorting to treating them as order fillers is demoralizing. At the same time, Engineers struggle to understand how to communicate that they want to be more engaged and better understand their users - making PMs feel like Engineering doesn't care and simply wants to be told what to do.


In very immature software development organizations, Engineering will intentionally not participate in discovery and rely on the PRD to state all use cases, acceptance criteria, edge cases, and nonfunctional requirements as a "C.Y.A." If you see this type of behavior, you should address it head on with the Engineering Team Leader and redefine how you should work together. (If you need help addressing this team dynamic, contact me at michael@product-bridge.com.)


What to do about it:
  • Invite your Engineering Team to meet with customers or internal stakeholders to learn more about their users straight from the source.

    • Engineering - accept the invitation. Better yet, create a performance KPI on "number of customer meetings attended."

  • Work together with your Engineering Team to understand how they want to receive feedback from users and context about new features.

    • Remember, you are a story teller and you must tailor your story to your audience


Conclusion

No one really wants a PRD as it used to be. People naturally seek understanding the "why?" behind what they are asked to do, and some PMs aren't doing a sufficient job addressing it before writing up requirements. Engineering and Product should work together in the discovery process to foster collaboration and mutual understanding.



Comments


bottom of page