As a PM, one of the most important things you can do for your team is to help them understand the customer they’re building for and the problem they’re solving for them. Doing so will help your team feel motivated because they will understand the impact their work is having, and will also ensure that they’re building the right thing. It is just as important to make sure they understand how you’re solving the problem to ensure a successful build and launch.

Product requirements documents (PRDs) often run the risk of being long (I’ve seen some that are 15+ pages!) and the longer they are, the more likely they run the risk of sitting on someone’s desktop unread. That said, PRDs are often essential to communicate and document key product information, and to ensure alignment, so we can’t skip them altogether.

Here are some tips to make sure that your team internalizes essential information about a project without being overwhelmed by super long docs.

1. Make sure your team is always learning about their customers

If you incorporate your customers into your team’s day-to-day work, they will already have a good understanding of your customers’ problems before you kick off a project. This means that there’s less work to be done to get them up to speed, and they’ll have a good foundation for any project. A few ways to do this:

• Make sure that your team goals and roadmap are customer-focused. That means that they both focus on solving core customer problems, and prioritization discussions use customer impact as a key factor.
• Center customer needs and feedback in team discussions. For example, if you’re weighing two potential features to build, make sure you’ve spoken with customers to understand which would have the most impact for them and validate your solutions with customers before shipping. Make sure to include your team in the customer research so they can hear directly from the customer!
• Take any opportunity to bring the customer voice into your team’s work. You can do this by sharing customer stories & quotes, digging frequently into customer data, or even inviting customers to speak directly with your team about their experiences.

2. Bring your team along for the journey: Have them help you figure out the “why” and “how”.

Instead of waiting to bring your team into the project once everything has been defined and it’s time to build, include them as much as you can in the discovery / planning / design process. You can do this by including them directly in the work you’re doing (attending customer calls, participating in solutions brainstorms) or you can make sure to check in with them at key milestones: once you’ve finished discovery and defined the problem, once you have a few potential solutions for them to give feedback on, etc.

That way you can help them receive and digest key pieces of context on your project as you go, instead of dropping a giant file on them at the end and expecting them to catch up.

3. Highlight what’s most important in your PRD: Divide it into two sections above and below the fold.

Product requirements docs (PRDs) tend to be long for a reason: there are endless amounts of detail that need to be communicated around how you build a particular product or feature. That said, not everyone needs the same amount of detail to participate successfully in a project, and certain pieces of context are more essential to your project than others. That’s why it’s important to highlight the most essential information to make sure it doesn’t get lost. I’d recommend thinking about what needs to go above “above the fold,” on the first page, and what can go “below the fold.”

Above the fold:

Key information to include on page one of the PRD.

• What is the problem or opportunity? Lay out the key problem or opportunity you are addressing.
• Why is it important? Explain why this problem or opportunity is important to address NOW. What’s the impact for your customers / team / business?
• What does success look like? How will you measure success? What targets would you need to achieve to make this a successful launch? This can be both qualitative and quantitative measures.
• What’s in scope? Include a high level summary of the scope / boundaries for the project. Eg what activities / processes / product will be impacted. It’s also helpful to call out what’s outside of scope.
• When will this happen? Include an overview of key timelines and milestones so the team knows what to expect.

Below the fold:

Supporting information that can be included on subsequent pages and/or documented elsewhere and linked to from your PRD.

• Stakeholders: Who are the key people who will work on the project? Who needs to be informed? Stakeholder frameworks like DARCI or RASCI can be helpful here.
• User stories / Requirements: A prioritized list of the user stories and technical requirements that need to be addressed through this work. If you want to keep your PRD simple, you can also just link to the stories in your engineering project management tool so you don’t have to maintain them in two places.
• Open questions & decisions: Track key open questions & decisions related to your project.
• Related links & docs: Link to any key resources that can provide added context

And don’t forget, as you kick off projects and develop your documentation to share with the team, product requirements docs act as an aid to collaboration, but they’re not your only tool. Just as important to the success of your project is building strong context and bridges for your team. You can do that by bringing them with you along the way as you learn about customers and develop a plan to address their problems. If you drop a large document on them out of the blue they’re sure to get overwhelmed. If they’re already caught up on top customer needs and why you need to solve them, then the PRD will be an extra aid for them as they tackle the project.

‍