The following insights were gleaned from a presentation at INDUSTRY given by Jen Dante, formerly of Netflix (now at Google). Download Product Management TACTICS eBook for more.
A Product Manager’s job is to get everyone aligned around what needs to be accomplished — and create a plan to make it happen. Yet, it’s actually impossible to lay out *every* single requirement. However, teams can create a product with purpose, even without every single requirement.
As a project manager, most of us have written up a product requirement document (PRD), stipulating the tasks needed to accomplish the project. It might be overly detailed in a way that’s condescending to developers. It might be too vague, giving developers too much leeway creating a messy end result. Either way, a PRD is not as useful in giving the team a purposeful goal.
The problem here is that many disagreements come from misaligned goals. The project manager’s goal is to define a product. The developer’s stated goal is to build a great product. However, the developer’s real goal is to build the required product on time with the minimal effort and bugs.
So, what is a product team to do?
Really, it’s all about aligning goals. Product Managers should manage the goal and the framework to help the team achieve it. This can be done by including the team into the goal-making process. This process shouldn’t be done in isolation anyway. Better outcomes will be achieved if developers and designers are a part of this process, as they will have more ownership and, most likely, will contribute ideas that the Product Manager simply wouldn’t have thought of otherwise.
To help establish the buy-in, a Product Manager can show why the team is working on a specific project instead of simply the step-by-step system to accomplish the project. Showing the “why” treats your developers and designers like adults instead of valued team members. That mentality improves results and leads to happier workers.
The nuts and bolts of this could be as follows:
First, work with the design team to create a mockup of the product. Next, write up a quick project spec in a shared place like Google Docs or Basecamp. That document shouldn’t just be an overview of the product and project itself, but it should also state the background (why the project was green lighted), the goals (hypothesis based on accurate success metrics), and the high-level requirements. Give your team edit rights to this document and have them share the ownership of this with you.
Often times, the initial product team meeting ends up resulting in a radically changed set of product and project requirements. And that’s OK! In fact, it’s a sign that your team has truly bought into the process
To view Jen’s full presentation, visit: https://productcollective.com/purpose-not-prd/
