Decision flow for customer feature requests
January 28, 2014 10 Comments
If you manage a product or service in the business-to-business (B2B) market, customer requests for features will be a regular part of your work. Requests come in through the sales team, service reps, and senior management, as well as directly from customers themselves. It’s a disruptive insertion of new items for your agenda. That disruption isn’t necessarily bad, but it does distract you from other planning and execution you’re working on.
Reflecting on my own experiences here, I realized that each request needs to go through a series of decisions. These decisions make sure you know why you would agree to or decline the request, and are aware of the bigger picture effects of your decision. They make up the customer request decision flow:
The flow is a series of decisions, in priority order. My perspective is product management, but they apply to other areas as well (service, contracting processes, etc.).
Firm request from a priority customer?
This decision point is made up of two criteria: priority customer and firm request.
Priority customer
The first decision point may be somewhat offputting, especially if you operate in the small business or consumer markets. It matters who makes the request. In the enterprise market, just a few customers will be a significant share of your revenue. These customers’ revenue help you meet the payroll. They help keep the lights on. If you’re public, they help keep the stock price up.
In addition to high revenue, some customers are also valuable for non-monetary reasons. Lighthouse customers are important for establishing credibility with other companies.
Whether based on revenue or marketing value, some companies will be priority customers. They are a reality in every B2B company. Keeping them happy is part of the job.
Firm request
Sometimes a request is urgent, and vitally important to the customer. Other times, it’s merely a suggestion, a minor nit or a fleeting idea. It’s important to understand the difference.
Firm requests often come freighted with emotional terms, or subtle threats. “We really need this to make sure our sponsors continue to support you.” When they’re firm, pay attention, immediately.
Not all requests are firm. The customer may couch the request with wiggle room. Or directly say “it’s not a big deal”. Often, they have bigger things they want to tackle (on the product, on processes, on strategy) and look at their request as a suggestion-in-passing. They will move on to the bigger items and not focus on the request.
The ability to recognize the difference gets better with experience.
Multiple similar requests?
If the request is not a firm one from a priority customer, the next decision point is: are multiple customers are asking for the same feature? What the request lacks in priority, it may make up in commonality. If customers are making multiple requests for a similar feature, you’ve got a pain point on your hands that needs to be addressed.
A key issue is this: how do you know multiple customers have the same request? A common way is to utilize software which allows customers to post ideas, suggestions and requests. There are idea management providers that are good for this. Or you can user customer feedback sites. These asynchronous, always-on, open-to-all sites are well-suited for capturing suggestions.
In addition, you may need to check other areas. Bad as it is, your email often contains customer suggestions. Or you have a service ticket database you can check. Relevant knowledge will be in people’s heads, those who directly work with customers.
Once you know where to look, the process of determining commonality has two steps:
- Identify all similar requests that have been made by different customers
- Find all signals of support from customers
If you’re using an ideas or feedback site, finding similar requests is easier. Search on terms that relate to the request. Also, look at the ‘Likes’ and comments the suggestions have. I look at the number of companies represented in these signals of interest.
After gathering this information, you will have a sense of how wide the support is for the suggestion. If it’s sufficient, consider adding the request to your roadmap.
Meaningfully enhances outcomes?
Assume that the request is not a firm one from a priority customer, or one that has yet to be shared by multiple customers. There’s one final decision point: will the suggested feature meaningfully enhance customers’ outcomes?
Outcomes has a specific meaning here. It is the definition of when a job task has been satisfied. It should reflect the customer’s expectations. Remember, they only agree to use (and pay for) your product because you’re making them successful.
To apply this criteria effectively, you need working knowledge of what customers want to get done, and where they’re falling short. If you can see that the request will improve outcomes for a significant number of customers, it should be addressed.
Committed to maintaining feature?
For each of the previous three decision points, if the answer is ‘yes’, there is one more decision to make. Are you committed to maintaining the feature? While this may seem like a simple enough question, there are a number of considerations to it. Below are six factors to consider before answering ‘yes’.
Economics: What are the costs to build and maintain the feature? The expected upside of the feature should cover these. Upside is a holistic concept, including money for the new feature, new sales contracts and renewals because of the feature and increased customer satisfaction that translates into informal marketing for your company.
Release velocity: Every new feature added to a product increases the complexity of future releases. In software, a given configuration can have ongoing downstream impacts. Yammer’s V:P Engineering Kris Gale sees the additional complexity as a tax on product velocity. Your ability to release quality products quickly is impacted with each new feature. It’s worth it to add features, but think carefully about velocity impact.
User experience: The ability to use the product or service effectively is a core requirement for customers. If they find that it too complex, they will not fulfill their jobs-to-be-done. Joshua Porter nice summarizes the issue of feature creep: “No single feature addition is a big deal, but taken together change everything.” The value of the request must be greater than any negative effects on user experience.
Tip of the iceberg: sometimes, a request is a “jump” from the current product or service. And it’s only part of a broader offering needed to really address the need. You can look at a request and see how additional features will be needed over time to make it deliver value. And that may take the product in a direction you don’t want to go. Understand the longer term plan related to the request.
Mass market: You’re building a product or service for the mass market. It needs to address a large swath of customers’ needs. In that light, look at the current request. Is it the umpteenth time that this customer, or one of a handful of customers have requested something? Too many ‘outside-the-market’ requests can undermine your broader strategy. You win the battle for the lighthouse customer, but lose the war with the broader market.
Outcome prioritization: Smart product management is organized according to customers’ jobs-to-be-done and expected outcomes. Some outcomes may be currently underserved. Customers’ expectations are being met, and that needs to be addressed. The new request will delay the implementation of features to address these outstanding pain points. Determine if the new request outweighs the currently underserved outcomes.
Decide on the request
Decline the request
If the request cannot cleanly get through the six criteria of the “Committed to maintaining feature?” decision point, it is reasonable to decline the request. Indeed, you now have specific reasons for doing so. That alone is a big improvement versus what often happens: the request sits in the equivalent of a “dead letter” file. Or if there is a response, there’s only a vague, “we can’t do that right now.”
Address the request
If the request makes sense, then it’s full steam ahead. However, notice I’ve used the term “address the request”. This is different than “implement the request”. Maintain a philosophy that:
Customers know their jobs-to-be-done better than you, but you will know potential solutions better than them.
Not to say the customer hasn’t provided a specific feature solution that is right. But avoid just passing through exactly what what was requested without giving thought to different ways the job-to-be-done can be addressed.
Customer requests will be a constant in the B2B product manager’s life. Knowing how you’re going to handle them is key to the success of the product and the business.
I’m @bhc3 on Twitter.
About Hutch Carpenter
I'm Not Actually a Geek 
Great post Hutch.
I’ve been on the receiving end of 100s of B2B requests in my time and, early on in my career, would treat all of them with equal importance. Using enhanced outcomes as a hygiene factor for progress to a formal evaluation of the business case is clearly a better way of doing things.
The only thing I would add is that this will only work when capabilities and strategy align with process: Experience tells me that B2B revenue generators have a habit of setting the product agenda in the absence of strong leadership committed to an evaluative process such as you describe (strategy) AND the product management team have the gravitas, experience and seniority to stand their ground (capabilities). As with many things this is a communication issue as much as anything else.
Agree Mike. The pressures of hitting revenue numbers can obliterate smart long term thinking about product. Senior executives need to understand the ramification of their decisions. I talked with one product guy for a Bay Area enterprise software company. He said he spent quite a bit of time talking about trade-offs that needed to be made to address everything the CEO came up with. That mentality, and that relationship, are important to make this work.
Hutch, this is a great topic. I have seen this problem many times, and it is especially a problem in small organizations were those who have to make the changes are also the same ones working on new products. It is also particularly a problem in software feature requests since any one of them in and of themselves may be a small task. Project managers who are counting on a particular person to spend most of their time on a specific problem suddenly find that this person’s time has been re-priortized, usually by a senior manager, to solve a high-priority (e.g., every customer request) customer request. That same senior manager laments that none of their projects are never on schedule!
I know what you mean. It’s a reality in larger B2B environments. The biggest learning for me has been to work to differentiate between ‘hard’ and ‘soft’ requests. As soon as the customer says something, the salesperson’s natural reaction is to get it to product ASAP. Which is appropriate, I don’t want the sales folks trying to manage the product. But then it’s smart to sit back and determine the actual importance of the request to the customer.
While all important considerations, I think the components in this decision flow miss the elephant in the room. The single most important criterion for all product decisions – including feature evaluation and prioritization – is the extent to which the decision supports the product’s unique value proposition. Otherwise, you end up with a fragmented product that doesn’t capture coherent, contiguous territory in the minds of prospects.
Thanks Roger. I guess for me, that’s implicit in everything a product manager does. I also don’t like to get too hung up on making everything specific to the unique value proposition. If something is becoming more important for customers to get their jobs done, you need to look at it. Even if it’s something (e.g. activity streams) that others have. It might violate the ‘unique value proposition’ requirement, but it’s more important to ensure customers are getting the outcomes they seek.
I hear you, Hutch, but consider this factor: if the unique value proposition doesn’t speak to the customer “getting the job done”, it’s probably not a compelling unique value proposition. So distinguishing “getting the job done” from the unique value proposition sets up a false dichotomy.
Customers are trying to get many jobs done. When we choose a unique value proposition, we are narrowing the set of jobs and problems that our product is uniquely suited to solve. Every time we deviate from that value proposition, we are chasing problems that cause a lack of focus. That lack of focus impacts development resources, external perceptions of the brand, and marketing messages and content.
So yes, it’s a given that support for the unique value proposition should be key criterion for every product decision. But the unique value proposition is constantly at risk. We need to be relentless and persistent in reminding the entire team of what the value proposition is, why focus matters, and that all product decisions should flow from it. Whenever we set up a decision flow that doesn’t explicitly include it, we undermine this all-important goal.
Pingback: Assessing Disorder in a New Product Development (NPD) Process | New Product Visions
Pingback: Practical Tools for Project Portfolio Management | New Product Visions
Pingback: Prioritization – Part 1 | Kristin Runyan