The opportunity cost of "we've added it to the backlog!"

Let's imagine a customer has requested you to build super-fine role-based permissions into your app.

You know that building it would mean that it causes more issues than it fixes or at least that's what it feels like from the sound of the request.

How do you respond?

One option would be to tell them "That sounds like a great idea! We've added it to the backlog, thanks!"

Doing a quick search on Twitter for the keywords "We have added it our backlog" reveals different versions of the same message...

This is easy to do and doesn't take time to communicate but your customers are smarter than that. They know that it loosely translates to never seeing that feature or hearing from you again.

A customer's request for a feature is most likely the result of a more important underlying problem. Instead of discussing their issue, customers will submit a feature request to tell you their best attempt at solving it. You can't really blame them; we're all guilty of it.

It's much easier to offer assistance in the form of a feature suggestion than it is to show someone — much less a company — that you're having trouble making progress.

So, if you tell them it's been "added to the backlog!" without first understanding why they're asking for the feature, they'll have a negative impression of the interaction, and you won't learn anything from them.

So, what's the best way to handle customer requests? How will you use it to figure out which needles it will move in your product and how will it help your customers make real progress?

Ryan Singer explains how to think about it in this section of the Shape Up book.

The key here is digging deep and not taking requests at face value.

This way of thinking about requests makes it...

• Less about managing them and more about understanding the problem from their perspective.
• Less about adding to an overflowing backlog and more about opening up the conversation to collaborate with the customer.
• Less about building something with a lot of unknowns and more about bounding it into a manageable scope of work.

A one-day change vs. a six-week project, in Ryan's example, has a huge impact on both the customer and the business! The reality of it is that the customer owns the problem and how you solve it in multiple dimensions (desirability, feasibility and viability) is up to you as an innovator to figure out.

If you like this post, then you'll probably like reading how to build a bare minimum feature.

References

• How to say no to customers from starter story (filter it by customer)
• I posed the question of "how to say no to things you don't intend to build" to r/ProductManagement there are some really good discussions surrounding this topic.