Listen to Customers (or Not)

January 18, 2018 / Steve Johnson

Should we add every feature that customers (and sales people) request? No. All requests should be vetted against key strategic elements of product direction. Here's one approach. 

Customer (and sales) requests can quickly overwhelm your development capacity, so you have to ensure that ideas align with your product strategy. Should we listen to our customers? Here are some factors that determine whether we should build a feature to support a customer request.

Committed: Well, hell! Like it or not, our team has agreed to deliver this, either verbally or via contract. Doesn’t have to be a good idea.

Customer need: Most of our customers need this. A lot of them. Not one. Yes, customers are the source of recurring revenue and references. Adding capabilities that appeal to customers will increase their satisfaction and the likelihood they'll recommend the product to others.

New revenue: This will enable us to generate new revenue. Capabilities that appeal to those who buy (and your sales people) are likely to generate new sources of revenue.

Losing deals: Alas, we lose deals because we lack this solution. Are you losing deals because you don't have a similar capability? (Don't ask sales people; they don't know. Get some win/loss analysis.)

Product parity: Most of our competitors have this capability. Dang it. When many or most of your competitors have a feature, it probably means you should have it too. But it doesn't necessarily have to be as robust as the competitive feature; it has to satisfy the checklist. (Got feature x? Check!)

Increases renewals: This will improve recurring revenue and/or renewals. Adding capabilities that appeal to those who use your product on a daily basis will increase the likelihood that they will buy again or buy more.

Reduces costs: This will reduce our internal costs. Some capabilities make a product easier to maintain and support, such as refactoring and redesign. Or a logging function so you can see what clients really did, not what they say they did.

Dissatisfaction: Are customers really dissatisfied with the current solution? (Do I really need more than 140 characters in my tweets?) When customers are truly dissatisfied with a capability, it may indeed be time to revise or rewrite it, particularly when the original capability wasn't implemented well.

Expertise: Do you have the expertise to deliver this? Capabilities that leverage your internal expertise are likely to be easier to deliver and more robust in their implementations.

Easy to deliver: All things being the same, focus on things that are easy to deliver so you can get them to customers quickly.

Prerequisite: This is core functionality necessary for other stories. This is a foundational element that other stories will build upon.

Just because it's a customer request doesn't mean you have to say "yes." Customers want an answer. An reply of "no" is acceptable; no reply is unacceptable. 

Which "yes or no" statements would you add to your list?