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.
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:
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.
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.”
Key information to include on page one of the PRD.
Supporting information that can be included on subsequent pages and/or documented elsewhere and linked to from your PRD.
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.
You can apply to a Guided Sprint and we’ll make sure you get the most value out of your coaching experience and being part of our community.
We want to make sure you don’t miss out on any of our free events and career resources, so follow Scale Higher on LinkedIn. Hope to see you at our events soon! 😊