By Rivi Aspler
Can you say ‘No’ to customers’ requirements? Should you?
Good product managers always keep their intended (and yet dynamic) product strategy in mind, i.e. the list of required modules, features, workflows, parameters etc. that all together define the best possible product. And yet, most product managers, once faced with real-life customers, will be asked to add features and modules that may not align with their intended product strategy.
This is where a product manager will be required to actively analyze each and every requirement and sometimes return to the customer and say ‘No’. Easier said than done of course. Product managers should stay on-guard, making sure that their intended product strategy doesn’t turn into a (not good enough) practical product strategy.
Now, I know that this is one of those blog posts that if I was the one to read, I would definitely say …. Yea, Yea…. Let’s see this person sit in front of a customer and say:
“No. We don’t have this feature in our roadmap and are not planning to have it in the near future”.
Before further diving into the details, I would like to note that there is no official product management course that will teach you this stuff. Only the school of hard knocks will sell you such a diploma and yet, since I have been in this situation more than a few times, it’s rather easy to draw the matrix for the ‘Yes’ vs. ‘No’ answers.
- Customer attributes: How similar is this customer to your target customer? How much has this customer already invested in your product?
- Vendor attributes: How aligned is this requirement with your long-term roadmap plans? How dependent are you on this customer? How much of this requirement are your competitors offering?
- Requirement attributes: How expensive is this feature (R&D effort estimation)? Does it fit well with current functionality and architecture?
The diagram on the right maps roadmap alignment with R&D effort. It’s fairly easy to refuse a request when roadmap alignment is low AND the R&D effort is high. It’s also easy to see that there is no easy answer to the combination of a high roadmap alignment AND high effort by R&D (hence the TBD). This is a classic case for taking that feature into account when planning your next release backlog.
Be careful. Don’t underestimate those small, yet unaligned requirements. A bunch of such requests will practically shift your roadmap away from your intended product strategy. How and when will you draw the line? A nice work-around can be the definition of a limited pool of R&D days per quarter that can be used for such minor requests.
Now, let’s go to a more interesting and less discussed scenario: How deep, as a vendor, are you webbed (financially and personally) into the customer’s organization? Or in other words, how easy will it be for the customer to replace you? If the sunk costs of the customer are high, you can carefully pull the rope and refuse unaligned-to-roadmap or expensive-to-develop requirements. And yet, this parameter should be handled with caution. Note that the customer knows you are pulling the rope and will remember that. Additionally, don’t underestimate the competitors’ efforts to take you off this account. Carefully handle requirements by such a customer.
Does this Customer Represent a Target Customer?
This next one is an easy one…. Any product manager knows, it’s best to meet customers and hear their needs directly. When meeting a customer that is similar to your target customer, is deep into your product and has the time to dwell into new requirements with you, sit down and write….
When a customer doesn’t represent the target customer, that’s when you should politely yet firmly say ‘No’. As always, the dilemma is more challenging when the customer is a relevant one but the requirement is estimated by R&D as an expensive one to develop (TBD box). It is best if you simply take that requirement into account when planning your next release backlog.
Are you, as a Vendor, Financially Dependent on this Customer?
Another parameter that is not that often openly discussed is the level of financial dependency of the vendor on a specific customer. It’s easy to say ‘no’ when you have dozens or hundreds of customers and they all bring-in similar amounts of dollars. But imagine a scenario in which you have just a few customers (often the case with a B2B start-up) and one of them represents 30% of your annual income.
As painful as it is, often the product managers will actually be forced by the CEO to change their product roadmap to include features that fit that customer’s requirements. If that customer is similar to your target-customer, you’re lucky. If not, there goes your intended product strategy to the drains and you are most welcome to start maintaining a ‘practical’ product strategy.
On the bright side of things, the CEO will be able to pay your salary.
Tweet this: Guard your intended roadmap by regularly asking these 4 questions. http://wp.me/pXBON-3oA #prodmgmt #roadmap
- Roadmap Planning – Bottom Up View
- You Need Direction – Try a Product Marketing Roadmap
- Roadmap Planning – Top Down View
- Getting buy-in for your roadmap
- The Challenge – Planning a Full Year Roadmap When Working with Agile