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).

In this post, we’ll walk you through the ways product operations can help your company enhance conversation, collaboration, and alignment across your teams—and build better products.

How Product Ops Can Replace the PRD

Before we discuss the awesome things a product operations manager (or, if you’re lucky, a whole team) can do for your company, let’s quickly review the product requirements document. That should make it clearer why we’re recommending that you think of product ops as an upgrade over it.

What is (was?) the product requirements document, and why would you ever want one?

A product requirements document describes every capability needed for a product or feature release. To make these details clearer for the team tasked with building the product, PRDs typically also include a use case to further explain each capability.

PRDs are common in businesses using the traditional waterfall product-development approach. The product team drafts the document, which can run dozens of pages. They then deliver it to the engineering team to begin work.

This contrasts with the more modern (and way cooler) agile methodology. Under this framework, product and development are both involved from the start, collaborating to release small pieces of functionality to the market. Then these teams use real-world feedback to update the product in small increments.

Why would a business want to use the document-everything-upfront approach and send a 30-page PRD to the engineering team? There are a few reasons.

Download From Product Manager to Product Leader➜

1. The company uses a third-party development firm.

When the product and engineering teams are all part of the same company—maybe even working in the same building—these teams can communicate and collaborate easily. Conversations can happen without much preparation. A product manager can walk over to the development manager’s cubicle, or the two can hop into a conference room.

For businesses that outsource product development to a third-party firm, those developers will need more detailed guidance on what the product team envisions. Having impromptu chats or Q&A sessions will be more difficult. In these scenarios, the company might benefit from using the PRD method.

2. The developers and product managers are in different time zones.

This is a similar challenge to the first one. Let’s say the company’s developers are “in-house” employees. If they’re located halfway around the world from the product team, a lot of the communication between the two groups will be asynchronous.

When cross-functional teams are 10 or 15 hours apart, phone calls or real-time instant messaging threads will be difficult. That can force the product managers to fully document their needs and goals for every aspect of the product. In these cases, a PRD or something similar could be useful.

3. The organization wants to party like it’s 1985.

Some companies still prefer the waterfall development method. They want their product teams to document everything needed for a new product. They need this before showing those requirements or plans to the engineering department.

For these businesses, a comprehensive document like the PRD makes sense. The product managers won’t green-light the engineers to start building until they’ve written down a complete blueprint for the product. Also, the engineers won’t start working until they can see the product fully documented.

Why Product Operations Is Awesome

But in our view, this waterfall approach—and the PRD that comes out of it—prevents valuable collaboration from taking place between product managers and developers in the early planning stages.

That’s why we believe the collaborative agile framework will prove more successful for most businesses. It’s also why we’re so enthused about the rise of the product operations role. Here are a few specific examples.

Product ops professionals document the good stuff.

When we say that a product operations manager negates the need for a massive, all-inclusive product development bible like the PRD, that’s not to say that documentation isn’t part of the product ops role.

Having a product operations manager on your team means your company will have more documentation—not less—than if you didn’t hire such a person. The even better news: The product ops manager will help your team capture the really valuable stuff. For example:

  • Product ops will document and standardize processes for team meetings, product experimentation, and other ongoing initiatives.
  • They document usage data, user feedback, and other information needed for evaluating and improving the product’s resonance with customers.
  • Product ops will document quality assurance checks on new products and features. They make sure before they’re released that these solutions deliver a great user experience.
  • The role also documents which tools in the product tech stack are delivering value, which need to be replaced, and which tools the company hasn’t deployed but should.

Product ops professionals connect the cross-functional team.

The second strategic role a product ops manager will play is serving as the connective tissue between product and development (as well as between product and other teams across the business).

This is why we believe product operations can essentially replace the PRD—in other words, writing a huge amount of product documentation and then throwing it over the wall to engineering.

With agile in general, and with product ops in particular, the wall doesn’t need to exist. Product and engineering can work together from day one on planning a new product.

By taking responsibility for setting a regular cadence of cross-functional meetings, and devising processes for communication across teams, product ops can help make sure that developers can connect with product managers, and vice versa, more reliably.

And that’s just one more reason that we’re thrilled to see the product operations role becoming more common across businesses around the world.

Move Forward with Product Operations

If you’re with us, and you’re ready to add a product ops team to your company, read our free guide:

Download Scaling Product Teams with Product Operations➜