May 7

Purpose Over Product Requirements

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:

Paul McAvinchey

About the author

For over 20 years, Paul has been building and collaborating on digital products with fast-growing startups and global brands, including AOL and WMS Gaming. Currently, he's a co-founder of Product Collective, a worldwide community of product people. Members collaborate on in the exclusive Member Hub, meet at INDUSTRY: The Product Conference, listen to, learn at Product Interviews and get a weekly newsletters that includes best practices in product management. In recent years he led business development at DXY, a leading product design firm in the Midwest, and product innovation at MedCity Media, a publishing startup acquired by Breaking Media in 2015.


You may also like

Deep-Dive: AI for Product Managers

Deep-Dive: AI for Product Managers

Deep-Dive: Product Operations

Deep-Dive: Product Operations