Those Customer Requests in Your Backlog | by Noa Ganot | May, 2023

Your customers seem to want new features all the time. If they use your product, that’s a great signal — it means they care and they want to do more with it. But you end up with an endless list of features in your backlog. Here is a quick guide to managing them.

My daughter recently got for her birthday the Monopoly Cheaters Edition board game. It’s a nice version of Monopoly where players are encouraged to cheat in various ways in order to win. It’s nice to see though that cheating itself also has its rules, you are not allowed to cheat any way you want. Well, unless you play the Ultimate Cheaters mode which we haven’t yet dared to try.

One of the ways to cheat is to fake a Chance card, and that’s exactly what my 10-year-old did the other day: when her dice led her to take a Chance card, she “read” it out loud, making up a story about a problem with the neighbors (me) which required reimbursement — and all of my money. She played it so well that I believed her and gave her everything I had! I feel half embarrassed that she was able to trick me so easily and half proud of her for the exact same reason 🙂

One of the Chance cards in the game is titled “Just Say No”. It allows you to decline any instructions or implications (such as paying rent) once. A great card, don’t you think?

Saying ‘no’ is an important skill for product managers. Today I want to talk about a specific type of saying ‘no’, one that not many product managers even realize is an option: saying ‘no’ to customer requests.

Don’t worry, I’m not going to encourage you to bluntly say ‘no’ and leave it at that. In fact, I’m going to take you through a decision-making process that will allow you to address each customer request with care.

To do that, though, to actually give each customer request proper thinking, you must change your mindset. Customer requests are not orders to be taken (yes, even if they come through the CEO or a very determined salesperson). You, the product manager, have a say. Of course, for your stand to be respected you must understand everyone else’s take on it and be willing to go with them, but it is well within your right to say ‘no’. You must remember that, and on the other hand, remember that it needs to come with explanations that address the other person’s concerns (for example losing a specific deal).

I might write a separate post about communicating with your stakeholders when you can’t accept their request, but for today I would like you to remember that that’s exactly what it is: a request. And you have the right to refuse.

Giving yourself that mental space to truly consider the request is an important first step. I’ve seen too many times product people (including myself and other experienced people) struggling to keep their objective assessment once a request has been submitted from high above. Here is the thought process that will help you make the right decision for each and every request.

There is only one answer to it. Every customer request has reasoning behind it. It is not always clear though, and it is your responsibility to make sure you fully understand it.

When you get a request, especially if you hear it for the first time, always dive deeper. Strive to understand what drove this request, what pain or problem caused them to raise it, and why this is the solution they requested.

When you do so, use the request itself as a starting point: people like communicating solutions, but we want to understand the problem behind the solution (and then potentially come up with a different solution).

Make sure you talk to the customer firsthand and don’t only hear things through other people. You do need to get all the information you can from the stakeholders communicating with you, but if you are truly seeking the deep truth behind the request they will most likely not have answers at some point. That’s the right time to ask to talk to the customer directly.

As I said, although this section is titled “Does it make sense” it’s not really a question. It does, in the customer’s mind, and you can’t move on to the next step until you have figured it out yourself.

The fact that it makes sense from the customer’s point of view doesn’t mean that it makes sense for you to support it. Note that I’m not talking about supporting it now, but rather in general — do we see this as a valid addition to our product, at some point in the future?

There are three possible answers to this question: ‘yes’, ‘no’, and ‘it depends’.

Here are a few things to consider when you figure out your answer.

Does It Represent the Market?

A great quote that I learned early in my product management career says that the product manager doesn’t need to be the voice of the customer. That’s on sales and customer success. Instead, the product manager needs to be the voice of the market. They need to hear every single customer’s input and compile it into market insight.

A specific customer request might be just that — a request for that specific customer. They might be the only ones who need it. But they might also be a leading indicator for what we believe would become a market need, not just a specific customer need. They might be the one-too-many times you heard this request, that mark the shift from an esoteric need to something many customers might want moving forward.

Whenever you hear a customer request, research to understand if it represents “the market” or just this specific customer. Seek past signals (like previous customer requests) and future ones (trends in the making). Seek internally (ask around if people heard about it) and externally (Google and friends). Eventually, make up your mind whether this request is specific to this customer or represents a larger segment.

Does It Strategically Align With Where We Are Going?

Even if it represents a larger segment, it doesn’t necessarily mean that you should do it. For example, it might take you in a strategic direction that you don’t want to take. It could be large or small — an entirely different direction or a strategic constraint that you need to live with.

An example of the latter is something I had with a healthcare startup I worked with. They wanted to avoid being defined as a medical device since that was something that would require them to go through much heavier regulation than they could afford. So while there were many things that made sense to do, if they took them past that line they needed to be ruled out (at least until there was enough justification to reconsider this strategic decision).

If there is no immediate fit with your strategy, but the request overall makes sense market-wise, this usually falls in the bucket of ‘it depends’ or ‘maybe someday’. These are important buckets that you want to allow yourself to have.

If not, are they worth it?

In some cases, even if the request is truly specific to that customer, it would make sense to support it nonetheless. Some customers are worth making an exception for. But make sure it’s the exception and not the rule, or you might find yourself becoming a project company where each customer gets a slightly different product tailored to their specific needs.

It is perfectly fine to decide to support an important customer even if they don’t represent a larger market, as long as the implications are clear. Make an informed decision and don’t forget to consider the hidden implications such as maintaining this feature over time just for this customer, as well as the slippery slope of adding features as an “easy” way to please the customer where the real value might not be there or not clearly communicated.

This is the part that I find really powerful: even if something makes sense to do and you want to do it, it doesn’t mean that you need to do it now. Separating the ‘if’ from the ‘when’ allows you to think (and talk) about it much more clearly.

Listening to your customers will give you great ideas and insight as to where the market is going. Some of these ideas are important to implement right away. For example, they might have an immediate business impact like a golden opportunity or a threat that you already see materializing. Others are great ideas that you want to sleep on. They could represent a small part of a bigger picture that you are still figuring out. They could be very innovative to the point that the market isn’t yet ready for them. Or they could be nice but just not as important as other things you are currently working on.

Remind yourself that it’s ok to have customer requests staying in your backlog for a long time. Unlike clothes, which if you haven’t worn for the last year or two you are most likely to never wear them at all, and you can donate them to those who need them, features might wake from the dead even after a long time.

For example, if the market changes and something that used to be a niche now becomes table stakes (technology-related products go down that path all the time). Another reason could be that a strategic direction you were ruling out all along eventually became the right thing to do, and there is a certain set of features that come with it. Or for one of those ‘nice but not too important features’ — something might make it important enough.

Like true love, you’ll know it when you have it.

So next time you look at your backlog or customer request repository and see a long list of features, don’t feed bad. You are looking at a treasure trove of raw market signals. Go back to them every time you need to plan ahead, and you’ll find gold — signals turned into insights that can help you make better decisions.