Requirements, stakeholders, and product management — oh my!

If you want to be a bad product manager, collect requirements from stakeholders without questioning their necessity or intent. It’s called requirements gathering for a reason — your job is just to gather requirements from other people inside the organization. If corporate marketing wants to have space for 3 banner ads on the home page of your product, that’s a requirement. If product managers representing other products in the family want to put flyers in the shipping boxes, that’s a requirement. If legal wants users to read through 5 pages of detailed text before they register, that’s a requirement. Once you’ve collected them up front, you won’t need to update those stakeholders on progress since you already know exactly what they want from the product.

If you want to be a good product manager, ensure that stakeholder needs are represented in the product requirements. When stakeholders are asked for requirements, they usually provide specifications for implementation details. As a product manager, you are responsible for determining the needs of internal constituents, just like you are responsible for identifying and representing the needs of the market. You should not accept all “requirements” at face value, nor should you reject all requests from stakeholders. Rather than focusing on requirements that others provide, focus on the needs that those groups have with respect to your product.
Product management responsibilities include working with other groups — sales, marketing, finance, legal, customer support — to identify, clarify, and document their needs. This can be a challenge, since, as Roger Cauvin writes, “A significant cause of problems in many organizations is a tendency to go from vague stakeholder requests to features or low-level functional specifications.” If your stakeholders have vague requests — ability to add new content, for example — then your responsibility is to clarify why that is important and the underlying objective, and translate that into measurable requirements for development. If your stakeholders provide low-level functional specifications — a data model for subscriber information — then your responsibility is to understand what that specification is trying to accomplish and represent that as a requirement to which a solution can be developed.

Product managers are responsible for the overall product, and part of that product management responsibility is to work with stakeholders to ensure that their needs are met while at the same time maintaining the integrity of the product as a whole.

One thought on “Requirements, stakeholders, and product management — oh my!

  1. Sometimes translating stakeholders’ requirements into products requirements is tough job, but when is done correctly and forbearingly, it saves a lot of work and time and acquires associates supporting you and your product. Though it isn’t not easy to properly prioritize stakeholders and requirements.

Comments are closed.