How To Say “No” To A Feature Request

Sometimes No Is The Right Answer

Can you talk to me about a time when you had to say no to a customer? Why did you have to say no? How did you handle it?

Customers often make feature requests that seem obvious on the surface, but which in fact are misguided or a bad idea. My goal is to be able to tell them that we won’t implement that feature, and have them thank me for that answer. I do that by leading them to make the decision themselves. This is a matter of asking the right questions in the right way.

Oh, That’s A Terrible Idea!

For example, let’s say your product is a project management tool. And one of your big features is being able to staff a project by role. For example, you can specify that the project will take two DBAs, three Developers, a Project Manager, and a Business Analyst. And you can say how long you need each of these, and even define when on the calendar they are needed.

That’s a very powerful capability. But one of the first things you think of when you look at it is, “Wouldn’t it be cool if I could use skills in addition to roles?” For example, some Developers know Java, and some know .Net. Our customers often asked for the ability to use skills, not just roles, to help them staff projects.

This feature request turns out to be a bad idea, and very difficult to implement in a usable way. So I used the following approach when I’d get that request.

Leading The Customer Along A Path

First, I’d acknowledge that this seems like a good idea, and that other customers have asked for this capability.

Then I say “I want to understand more about what you’re looking for.” It’s always a good idea to ask the customer this question, and the follow-on questions, whether or not the request is valuable.

The resulting conversation can head in several directions. One is that we actually can do what they need (which is often not what they ask for). This happens all the time: customers ask for features that already exist, or they are trying to solve a problem that’s already solved a different way.

You Can’t Handle The Truth

However, if they truly are looking for something new, as in this case, the next step is to drill down into how they expect that might work. For example, I always ask about how they expect to manage the association between skills and resources. Who maintains this information? How do you keep that relationship trustworthy? How will it be vetted? Does it capture enough information that it will be useful in allocating resources, etc.?

Usually by this point in the conversation the customer starts to hem and haw. It turns out that they don’t have a way to ensure the information is accurate over time. And as a result they also start to understand how supporting skills could actually be counterproductive if the data isn’t kept accurate.

Closing The Conversation

I’ll usually say at this point that we have considered this enhancement, but we also haven’t come up with a solution to make usable in real life. And that other customers agree as well that the cost of maintaining any model that was used for resourcing based on skills would likely break immediately. (In fact, for many of our customers just maintaining the role mapping for resources can be difficult to maintain.)

By the end of the conversation the customer typically admits that they don’t have a good use case for making this work. And we move on. Of course, I’m always gracious throughout this whole process. I’ll associate the customer with the enhancement request. And I’ll say that if we crack this nut, if we figure out how to make it work and make it valuable, it’s a common request and we’ll prioritize it along with all our other work.

What’s amazing is that the customer usually feels better about the product, and about me, at the end of this process. I just saved them a lot of headache (if we’d actually done their feature). And I made sure that my resources could continue to be focused on more valuable capabilities that they’d benefit from.

Leading The Customer To Say “No” Themselves

The steps are:

1. Find out what the customer is really asking for – what’s the desired outcome behind the feature request?
2. If you already solve it, then fantastic – you don’t have to say “No.”
3. Otherwise, help the customer understand the implications of the enhancement – in the case of using skills for staffing, the implication is a huge overhead in maintaining data integrity, for which there is no good solution.
4. Lead the customer to say “No” themselves.
5. Make sure to capture the enhancement anyway, and promise to reconsider if a good solution presents itself.

What If It’s Not A Terrible Idea?

Of course, this is the case where it’s an enhancement request that you don’t want to do and that isn’t a good idea anyway. It’s a different process if the enhancement is a good idea, but you are just unable to prioritize it highly enough to replace something else on the roadmap. I’ll do another article on that soon.

(Image “No” copyright (c) 2014 Henry Burrows, Attribution-ShareAlike 2.0 Generic – CC BY-SA 2.0)