“Mark, you told us to build this feature for the customer’s pilot deployment, but they just told me they need something different – what’s going on?”

I walked into this trap during my first months as a product manager. It took a small crisis to teach me that product managers are responsible for validating requirements no matter who is asking. While this sounds obvious on the surface, I’ve seen too many instances where features appear in a requirements document because “my VP told me to put it in.” Or, “the account team says the customer needs it.”

As the product manager, it’s your job to validate all requests and take appropriate action. Chances are that your VP has been told that a particular capability is important to your business. The VP is doing her job in placing this request on product management’s radar, expecting you to make an informed decision. Likewise, your account manager wants a satisfied, paying customer and passes the request to product management, expecting you to manage the roadmap towards winning more business.

In both scenarios, the higher goal being communicated is not literally building a new feature, but growing your business. Each person requests what they believe will lead to that success.

The product manager must prioritize and implement either what was requested or other capabilities that will more effectively meet her business goals. It’s a critical responsibility requiring transparent reasoning and clear data to support your decision. Product requirements become an arbitrary list without a clear rationale, easily swayed by the loudest voice – a sure way to kill confidence in a viable product strategy.

It’s personal

Validating requirements gets personal, especially when working with new technologies and market disruptions. Abstractions fall away in deference to specific users and use cases. Mature businesses inevitably encounter a large customer opportunity or competitive situation where “one more feature” is mooted as the key to winning the deal. New ventures must make decisions without a proven path forward – else the problem would already be solved.

A product manager can maximize her chance of success by working directly with users and not allowing information to be filtered by intermediaries, no matter how well intentioned. Your VP doesn’t have time to fully dissect the customer’s environment, processes, and goals. Your account manager is operating on many fronts to secure a win and has a full-time job prospecting for new opportunities.

My beginner’s error was mistaking the account manager’s feature request as being already validated. One of the customer’s IT architects proposed that we integrate with a specific storage array, though they had many storage arrays that could be used with our product. Had I contacted the customer directly following my discussion with the account manager, I could have discussed their use case, exposing the fact that it depended on the capabilities of a different type of storage array. We fortunately discovered the gap soon enough, but with unnecessary delay.

Moving from ‘no’ to ‘yes’

That early lesson taught me to exercise positive skepticism when anyone in my organization requests that we build something. The skepticism is positive in that I know the person is doing what they believe is right given their perspective on our business. Yet it’s still skepticism because the product manager, being accountable for product strategy, has the responsibility to maximize product success in the face of many stakeholders offering their own perspectives on what should be built. The product manager must inevitably say ‘no’ to many incoming requests and offer instead a crisp roadmap that achieves the success your stakeholders seek based on an understanding of what will make users successful.

My CTO came out of a meeting convinced we needed to move quickly on an Openstack market opportunity. She directed that my team adopt a business partner’s apparently simple solution: demonstrate that our products worked together in an Openstack configuration and make it easy to buy the packaged offering. By this point, I had been speaking with customers every week about their cloud requirements and recognized a general perception of undifferentiated, “me-too” Openstack capabilities. Customers wanted to know what unique Openstack benefits our product offered as compared to other solutions. We did not yet have a good answer, yet our CTO directed us to proceed with the partner’s offer.

The skeptic in me refused to spin up sales and marketing on a generic Openstack offering because I knew we would be forced to sell on price due to our lack of differentiation. The effort required to close deals would distract us from larger opportunities and result in poor margins. Yet it was clear that Openstack represented a market shift and our business could benefit by delivering value to customers deploying Openstack. I also knew that my CTO’s real interest was ensuring that our company had a competitive portfolio in the Openstack market.

Spending time each week with customers who showed specific interest in Openstack, educating ourselves about evolving Openstack technologies, and knowing what our product was capable of, our product management team identified a range of value-added benefits we could deliver into a “me-too” market. We created a roadmap for Openstack differentiation and made that our priority. Partner activities became one element of our overall roadmap and were introduced after our own value was clear.

Confidence comes from knowing your users

Intimacy with your users and their use cases allows you to make crisp, confident decisions based on problems that are truly useful to address. Everyone around the product manager has opinions on what should be done. The product manager is ultimately responsible for guiding the roadmap with a clear articulation of what will make users successful and return value to her business.