Do we still need product requirements


Documentation… is there anything else related to software product development that so few people enjoy creating but so many rely on?

Yeah… I didn’t think so.

One of the more controversial documents is the Product Requirements Document (PRD). Done correctly, it helps your team build a shared understanding of the solution you’re trying to build.

Done poorly, it can be an epic (pun intended) failure that finds its way into the trash can.

The prevalence of agile approaches has led many teams to believe you don’t need a PRD because you have user stories. Except it’s really easy to lose the forest for the trees if you only rely on user stories.

It turns out that PRD’s may still be helpful, as long as you approach them in the right way.

This week I’m sharing some perspectives on PRD’s and when they may still make sense.


Recommended Reads

Want to raise the value of your inbox? Here are a couple of additional newsletters I’d recommend. When you signup you get some great info in your inbox, and I get a small referral fee, at no cost to you.

Department of Product

Department of Product Briefing - the latest product launches, news and analysis designed to help you build winning products. Join 18,000+ product people from Spotify, Netflix, Amazon, Apple and Microsoft and get your free weekly product briefing.

Subscribe to the Department of Product Briefing today!

1440

Sick of biased news? Try 1440.

If you wish all news could be as no nonsense as this, you'll want to check out a newsletter loved by millions, called 1440. It's a daily digest of all the most important info in culture, science, sports, politics, business, and everything in between—and better yet, it's the fastest way to an informed and impartial point-of-view.

The folks at 1440 scour over 100 sources every morning so you don't have to. You'll save time and start your day smarter. What more could you ask for?

Sign up for 1440 now and get your first five-minute read this minute. It's completely free—no catches, no nonsense, and absolutely no BS.

Join 1440 for free today.


Product Requirements Document (PRD): A Guide for Product Managers

Every product manager, at some point in her career, has written and read a product requirements document (PRD) in some form.

As unpopular as you might think the PRD is, there are enough product teams still using them. Hence, it is critical to understand its importance.

Sid Arora answers: “What is a product requirements document?” and “Why is it important?” And then shares good practices to create a comprehensive PRD.

Using product requirement documents and user stories appropriately without creating a mess.

You’ve written two dozen user stories in Trello for a new feature. With each new story, it’s becoming harder to see the forest from the trees. So you link, tag, and organize your stories. But this doesn’t give you the bird's-eye view. In frustration, you decide to perform a reorganization via a Google doc. Unbeknownst, you’ve created a maintenance nightmare. With two places for information, how do you keep your user stories and the Google doc in sync with changes? What information should be in one versus the other? Worse, when something is out of sync, which source is the truth?

You ask yourself:

  • Have I created a product requirements document (PRD) by accident with my Google doc?
  • Should I be writing a PRD or adding more details into my user story?
  • What’s the difference between a PRD and a user story?
  • Isn’t PRD used in the waterfall model of software development?
  • Have I created some abomination of Agile + waterfall (i.e., Agilefall?)

Fear not. You’re not alone wrestling with these questions. To tackle your problems, you have to first understand the similarities and differences between product requirement document and user story. Shaw Li provides some insights.

Is the Product Requirements Document Dead?

Although there are organizations that still use traditional PRDs, many teams have moved to more agile development processes, and several have even thrown out the PRD entirely. As with many tools in the product management arsenal, the document has seen both strong adherents and detractors over the years. The Uservoice team looks at the PRD debate and explains both slides.

Product Requirements Document: Benefits, Tips & Examples

Your product is the centerpiece of your company. There wouldn’t be any business for you without your product.

While we are consistently making efforts to strive for product excellence, we may not always reach there. This is because product owners fail at the very roots.

You may often build a product based on the basic idea you have for it. Sometimes, you may just run iterations or give feature requests to your product team.

However, you cannot just wing something that forms the crux of your business.

A country’s constitution is essential for its laws and actions. And a product requirements document is necessary for product teams to develop products that gain success.

Pradeepa Somasundaram talks about what a product requirements document is, tips on how you can write one, and examples as a bonus!

Product Ops: Lessening the Need for Product Requirements Documents

As if we needed another reason to be enthusiastic about the rise of product operations, we have one. Implementing product ops at your company will reduce your team’s need to produce clunky, one-way communication vehicles like the product requirements document (PRD).

The team from Product Plan walks you through the ways product operations can help your company enhance conversation, collaboration, and alignment across your teams—and build better products.

Thanks for Reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email.

Talk to you in a couple of weeks,

Kent J. McDonald
Founder | KBP.Media

InsideProduct

Hand-picked resources for product owners, business analysts, and product managers working in tech-enabled organizations. Check out the resources I offer below and sign up for my newsletter!

Read more from InsideProduct

I try not to overuse click bait titles, too much. For this particular topic, however, it was just too tempting. As I mentioned in a previous newsletter, there were several reasons I went to Agile2024 after a six year hiatus. One was to get a sense of the current state of agile. There’s been a bit of chatter about the decline in agile coaching opportunities as well as trends in agile transformations in general. I certainly caught some inklings about what’s going on, but I didn’t want to rush...

I’m back from Agile2024, and it was good to be back after a 6 year hiatus. I caught up with some old friends, made some new acquaintances, and had some great discussions along the way. Some of those discussions will influence future issues of InsideProduct, and others will go down as obnoxiously long running inside jokes. If you're wondering about the latter, ask me about retractable stairs or comic sans the next time you see me. While I’m not going to talk about those topics here, I did want...

For the last few weeks, I’ve explored what prioritization looks like in a variety of different scenarios. This week finished up that series with a look at how you can go about prioritizing a bunch of stakeholder requests. This is a common scenario when you’ve already built software for your company (ie internal product) and you’re trying to optimize or maintain it. A unique aspect for internal products is that most requests for changes come from other people inside your company who may, or...