Saying no to customers
The success of any company rests on its ability to understand the needs of their customers. In an environment like ours, that need is exacerbated by the fact that we sell products to other businesses and we don't have a direct relationship to the users and advertisers those products will serve. This business to business relationship makes understanding our customers needs more critical; our customers are the ones that know the landscape best.
That said, we are sometimes forced to say "no" or "not right now" to feature requests from our customers. Many very smart people have written about why it’s important to sometimes say no to your customers. Here's some insight into how we balance saying no with delivering a great product for our customers.
Needs over Solutions
Telling a customer we can't work on a particular feature is difficult. To a customer, it can sound like "you aren't important" or "your idea isn't good enough" or "we're not capable of helping you." Even if the proposed feature is the perfect solution for that particular customer, it may not be right for other customers. Instead, once we understand the needs of our customers (and their readers and advertisers) we're in a position to solve problems in a way that works for a broader audience. That way the product gets better for everyone.
To ensure we're hearing the needs of our customers, you'll often hear our product management team ask customers "what problem are you trying to solve?". Instead of saying no to a particular solution, if we take the time to understand the problem there's a much greater chance we can help the customer (immediately or down the road).
For example, here's an actual request we received during a feedback session for Turnstyle:
"We need a progress bar in the footer that shows you how far into the issue you've read."
When we translate it to a need, we get:
"The user needs to know where they are in a magazine."
Due to the number of use cases involved, it would have been very difficult for us to implement the exact solution specified above. Understanding the underlying need however allowed us to solve the problem in a different way (more on that below).
The Product Backlog
Once we understand the customer's need, we log it in Trello. We use Trello as our idea backlog, it's the tool all our product managers and user experience designers work from each day. It is basically a giant list of problems that need to be solved, their priority and what state they are currently in.
This list gets reviewed once a week by the product management and user experience teams and we discuss what new has been added to the board, the discussions we've had with customers in the past week, what's been worked on and what the next priority should be. This list is used as input to a monthly roadmap discussion with the Sr. Management team.
So while an initial conversation may have ended with a potentially frustrating answer like "No, but we'll keep it in mind", we do actually have a process that ensures we record and discuss the needs our customers have. On several occasions, we have been able to release new features in a way that solve several problems at once in a way that doesn't take away from the overall usability or maintainability of the product.
Let's take the scenario described above, where the need was to have the user understand how far into a particular issue they've read. That particular problem wasn't the most important one for us to solve at the time. Instead, we chose to focus on some additional navigation options, which was another common need we were hearing. As he was designing the navigation functionality, our Lead User Experience Designer Andrew Yip noted that highlighting the article the user was currently reading in the navigation list would give the user a way to understand how far into the magazine they've read. The result is shown here:
This is possible because we had many conversations with our customers and tried to really understand their needs. Without hearing from our customers, we fail to deliver successful products. While we can't always drop what we're working on to work on a new request, we are listening. Please keep those requests coming!