Stop gathering requirements

If you want to be a bad product manager, gather requirements. How else will you know about what to put in to the product if you don’t ask others? Interview current customers, ask them what their requirements are, and make sure to capture them. That’s what being “customer-focused” is all about, after all — responding to any customer request. Make sure to gather requirements from internal stakeholders too. Get a list of features from customer support, marketing, sales, and senior executives. If you just gather all of the requirements from all of the right people, you’re bound to have a successful product — right?

If you want to be a good product manager, understand unmet needs and use that insight to drive requirements. A product manager who just “gathers requirements” is doing nothing more than taking orders or documenting requests. Good product managers add value to their product by understanding the problems and needs behind requests.

Requirements gathering is an activity often thought to be the cornerstone of any project. The mentality comes from traditional information technology projects, where “the Customer” who was funding the project appeared to know exactly what was needed, and an “analyst” would document the requirements. Successfully gather the requirements, document them, and get sign-off, and the end product will be guaranteed to meet the customer’s needs — or so the theory went.

Of course, this theory fails because “customers” usually do not know exactly what they want and can rarely understand or articulate what they really need. They may have an accurate picture of some of the obvious needs, though often they do not recognize the underlying problems nor are they in a position to come up with the optimal solution. For example, a customer may request a small change in a 10-step process, though someone in a position to better analyze the problem may be able to figure out a way to reduce it to 3 steps — or eliminate the process altogether.

Additionally, gathering requirements from various parties will inevitably lead to conflicting requirements. One type of end user wants a simple Google-like interface on the home page, while another wants lots advanced search features; one internal department wants to use the home page promote what’s new on the product, while another wants to market other solutions which the company offers. These requirements are impossible to all fulfill simultaneously, so the act of gathering them in and of itself has left you no better off than you were before. Additionally, by asking for “requirements” from each group, you have set up each group for disappointment when they eventually realize that their “requirements” were not and can never be met.

A product manager — or anyone — who is just focused on “gathering requirements” misses the greater value that their role can bring. Simply put, there is no value in a product manager who just gathers requirements. The product manager must add value through insight and understanding, by making decisions about priorities and focus. Those who gather requirements just document; the product manager must

• Set the vision for the product: Which customers and internal stakeholders are important to the product’s success?
• Prioritize the different customer needs: When needs conflict, whose are more important?
• Determine which needs will and will not be fulfilled: Does this fit with the vision and strategy for the product?

Good product managers do not just gather requirements — they understand unmet needs, existing problems, and opportunities for improvement, and they then use that information to determine the requirements for the product.