Managing requirements from customers: Not as easy as it sounds

A lot of people that I have met tell me that B2C product management is far more challenging that B2B product management (reference: Types of product managers); I don’t think it’s an apple to apple comparison, and I don’t think it’s fair to compare product managers who focus on B2C products/B2B products/In-house products. They have their own challenges. Having said that, I also believe that product managers, in general, can switch their focus with minor tweaks i.e. a B2B product manager can manage a B2C product and vice-versa.

I have been a B2B product manager for a long time; I started my product management career-defining on-premise products and then moved on to defining and eventually managing B2B SaaS products. One of the most challenging tasks for a B2B product manager is requirements management.

What is requirements management? Requirements for a SaaS product comes from various sources. The imagination of the product manager, product manager’s understanding of the industry, the product manager’s empathy for the target user contributes to a significant portion of the requirements list. There is another important source for product requirements and which is the customer. Sometimes, the most dreadful source because customers want their requirements to be fulfilled, no questions asked. Requirements management is the art of managing customer expectations by having a clear strategy for managing requirements. Not as easy as it sounds!

Why do customers behave the way they behave? It’s simple, B2B software procurement is complicated. The buyers (who represent the customer) have their task cut out. The buyer needs to have a business case, must substantiate the value proposition, needs to provide empirical outcomes of the product, needs to get a budget allocation, must have a comprehensive roll-out plan, etc. The business case is then approved by the enterprise budget owners. Also, remember that the business case is prepared by the buyers based on inputs from the software OEM (pre-sales/product/sales teams). The buyers want to ensure that the product does everything that they claimed, even a small lapse could end up disastrous for them and their reputation. Thus the behavior pattern (i.e. my requirements must have been met yesterday).

How do product managers react? Few points based on my experience:

1. In many cases, product managers lean towards the white elephant in the room (e.g. customer who pays 40% of your revenue). You may run the risk of getting labeled as a one customer product (in other words, a service or a productized service company).
2. A very related behavior pattern is accepting requirements that come from all customers. I.e. saying yes to everything. A perfect recipe for failure.
3. Product managers tend to ignore their product direction, company strategy when they say yes to a customer requirement.
4. Product managers address customer requirements to please an influencer or set of influencers (to gain their trust/support).
5. Product managers address requirements that give them a perception of closing in on competitive products.
6. In the process, the product accumulates a lot of technical debt. Debt, that takes a long long time to fix.

How can product managers handle this situation?

Being data-driven: Being data-driven (check my essay titled Communicating with data ) is a structured and scientific approach to addressing customer requirements. Helping the customer understand the value of their needs and matching the same to their industry/business is the best way to communicate the relevance of their needs. It’s easier said than done but data speak does work (it takes a product manager with a good convincing skill set to convince a customer who is hell-bent on gettings the needs fulfilled).

The golden “Triage”: Triage the customer requirements on the basis of data insights and the following guiding principles:

1. Do not jump into the solution mode for requirements. Understand the problem and categorize requirements with a lot of care and analysis (see a few examples in the points outlined below).
2. An incremental (but relevant) improvement on the current product (low effort, big win): Pass it on to the development team.
3. Requirements that aligns with your product strategy (medium/high effort, big win): Keep it with the product team for definition.
4. Requirements that do not align with your product strategy (medium/high effort, no win): Knock it off and keep the customer in the loop.

The “soft” approach: Soft approaches are more behavioral and less product management-oriented, following are few examples:

1. Acknowledge the customer when they reach out with their side of the story.
2. Maintain a public requirements board (e.g. boards are amazing) to showcase that you have not just captured but also analyzing the requirements.
3. Align with partner teams (remember, your product may be solving just one out of many problems solved by a suite of products offered by your company); it’s important to give a complete picture to the customer (as they seldom care about how you are organized internally).
4. Review on a regular basis (too much review could end up as an overkill, apply caution).
5. The bottom line, engage with the customer.

Whilst this may not be exhaustive, I guess it’s a good start to this pretty interesting topic for a B2B product manager.

Originally published at https://www.raghsforte.com on April 24, 2020.