5

We are a small team of developers making and maintaining a software product with a high number of users.

We are also in direct contact with users who ask us many requests about the product.

We don't have access to business information (what kind of deal a specific user has with the company that employs us).

We don't have enough resources to address all the user requests, and will have to refuse some of them. We treat in priority the requests that seem easier to comply with ; or that could benefit most users.

How can we gracefully notify those users who made requests that we will not be able to process?
How to tell them that what they asked for is not possible ; while avoiding frustrating them?

3
  • 6
    Do you have a product manager, a product roadmap, an account manager dealing with the client interactions and contracts, or any of the other usual structures that come with making a software product for external clients? Or are you literally just a bunch of developers writing software and directly answering users on your own?
    – dwizum
    Commented Feb 13, 2020 at 16:06
  • What sort of answers have you been giving these users up until this point?
    – sf02
    Commented Feb 13, 2020 at 16:24
  • dwizum: Our team has a PM (shared with other teams), but no roadmap (there is one however for a bigger product offered by the company). The company has several account manager teams, who point out to us client requests about our software. sf02: Some requests are left unanswered. Many answers were: "we'll add the task to our backlog".
    – wip
    Commented Feb 14, 2020 at 0:50

5 Answers 5

12

We don't have access to business information (what kind of deal a specific user has with the company that employs us).

This is the key thing. Unless you know the contractual details of a customer you can't make a decision as to how to reposed to a customers request.

The obvious thing is boot the request further up your managerial tree until it hits someone who can make that decision for you.

In fact all change requests should be filtered through someone who is aware of the contractual requirements before you even start to work on them. As while you may think that an item seems reasonable, it may be totally out of the scope of what your customer has paid for, and by working on it you are effectively giving away free work.

7
  • Please consider adding to this answer that you don't say no very often, you just set priorities.
    – dbeer
    Commented Feb 13, 2020 at 17:05
  • @dbeer Setting priorities can only come after you establish that you are required to fulfill a request.
    – Peter M
    Commented Feb 13, 2020 at 17:59
  • 1
    It could also be that working on a feature request without knowledge of the broader business strategy takes the product further away from the strategic vision someone has planned for the future, which would not be good either.
    – Seth R
    Commented Feb 13, 2020 at 19:25
  • 1
    My point is that even when it's something you aren't going to do, you rarely want to actually tell the customer "we will never do this." Most of the time, you want to tell customers that you are tracking the issue, but that it isn't a priority at this time. That leaves the door open if the customer wants to pay you more to do the work. Even if it's something you don't want to do, it's better to say "we can do that with the following changes" in almost all cases.
    – dbeer
    Commented Feb 13, 2020 at 19:26
  • Yes to this. Feature requests go into the queue, where the "team" (whomever your company says this is) prioritizes these into future releases. Thank the customer for their feedback and say it's under consideration for the roadmap.
    – spuck
    Commented Feb 14, 2020 at 17:07
2

Pass information up, and receive decisions that come down.

You should record all the client requests in an issue tracking system, but place them into the backlog (so they aren't worked on). The project manager (you should have one, of some sort, I hope) will review the requests on a regular basis, and decide which ones should be worked on. That PM is the person who should have the business and contractual knowledge (from the client) and techncial knowledge (from the request) in order to prioritize the work.

Once you have that type of workflow in place, you never have to say no to a client - you always say that you'll ticket it, and Ms XYZ will prioritize it.

2

The golden rule: The customer is always right - if the customer pays for it. If your manager comes to you and tells you that the customer is paying for a feature or a change, and tells you to do the work, then you do it. Otherwise you don’t.

Find out who in the company can make a decision whether work will be done at all, and for what price. Then when you get a request, you say politely “I’m sorry, but this is something I cannot decide. Please contact so-and-so about it”.

PS Just because the customer is willing to pay doesn’t mean they get it. Someone quite high up needs to decide about the company’s strategy. Any request costs money, not just for the work done, but also for all the other work you should do instead.

1
  • +1 for comment at end. Each request has an opportunity cost , which is both human labor an time given up that could be used to address other more feasible customer requests
    – Anthony
    Commented Feb 14, 2020 at 23:29
1

Get together with your sales people/whoever manages the business side of the contracts for which you do the development. You have information they need, and they have information you need.

You need to know what you should do for the clients. The sales folks need to know what you could do for the clients, and how hard (read: expensive in salary hours) it would be.

You don't want to sever all contact with the customers. It's good if developers have a clear idea of what the customers actually want to do with the software. But you do need to get the sales people involved more. Handling your problem, is part of their job.

1
  • 1
    Just a small hint based on personal experience: Make it very clear to the sales team that you could do X for customer Y if it is needed right now, but this would push back other tasks, delay the next big release that was already promised,. etc. Don't give sales the feeling they can tell whatever to the clients and you will deliver it all, and yesterday.
    – Dirk
    Commented Feb 14, 2020 at 7:25
0

I agree with all the other answers on that you need the contract info to make these decisions and pass the negotiation of features onto whoever is handling those. That needs to go to them.

However, I want to add a warning. Be careful just handing off the decision on whether something gets added to the salespeople/management. A feature might be impossible, it might be a security problem, or it might require that so many variants of the software be created that maintenance becomes exponentially more difficult.

Management might easily agree that a button should be moved a couple pixels over. That couple of pixels may seem trivial for them, but could require adding the ability to add a custom style sheet for each client. Moving from a one to one relationship for items to a one to many relationship is something that many non-technicals see as 5 minutes of work. It isn't.

Highly complex requests are going to have to be refused anyway, but it will be a lot less graceful if sales agrees and then development tells them it cannot be done.

Try to get sales to check with the development team before they approve a new feature in an agreement.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .