Big, bad, I said no!

Saying no to feature requests: why, how and what happens when you don’t.

As a Product Manager I hear lots of fantastic ideas about how we can make our product better. These range from passing comments, through enthusiastic pitches, to explicit feature requests. Some of these will be worth doing. Many will enrich your understanding of the problem-space. Many will also require a diplomatic response making it clear we won’t be doing it. This diplomacy takes a lot of skill. Saying no is hard but it’s important to do. If you don’t you may end up adding lots of features your customers don’t want, while consuming your developers’ and designers’ precious time. The majority of people will use a small subset of features and it pays to keep your product focused. Adding individual features for everybody who asks can result in a product for nobody. On the other hand people need to feel you’re open to new ideas and some of those ideas will be gold.

Be visible, information radiators

So how do you go about this? I’m certainly not an expert but there are a few things I aim to do. Sharing knowledge and understanding the context of the idea are a couple of them. Particularly with people who work on the product, who are naturally closer to it and aspire to improve it. They have often given the idea a lot of thought and deserve some of your time. Remember you have a much deeper knowledge of the product and the customers. Spend the time to talk through their idea with them. Working out the underlying reason for the idea may actually uncover a job or need your product is not satisfying. Couple this with your existing insights to judge the value of new features. At the very least sharing your knowledge will make their future ideas much more valuable.

You can also use key metrics to frame the conversation. Ask them what KPIs they would move, what success looks like? Ask them to complete the hypothesis statement I use for A/B testing (which I helped develop with Colin McFarland, based on work by Craig Sullivan, et.al.)

Design like you’re right:

• Based on the insight that [quantitative/qualitative data] we predict that [product change] will cause [impact].

Test like you’re wrong:

• We will test this by assuming the prediction has no effect (the null hypothesis) and running an experiment over [X week(s)].
• If we can measure a [Y%] statistically significant change in [metric(s)] then we reject the null hypothesis and conclude there is an effect.

Having OKRs (Objectives and Key Results) also helps as they explicitly and publicly state your focus and priorities for the quarter. Any feature requests can be easily evaluated against your OKRs to see if they would drive the desired key results.

Of course it’s not always straight forward to say no. The experience that epitomises this for me is when we added maps to Skyscanner’s car hire downtown search. This started off as a conversation but we were soon facing a lot of internal pressure to build the feature. A number of cases were raised against doing it, from competitor analysis and industry statistics to our own product usage data and metrics. In the end we felt we had no choice but to build it. After the first release our downtown conversion halved overnight. We iterated quickly but only made marginal gains. Eventually we deprioritised the map in the UI, making it an alternative option for searching (which, incidentally, hardly anyone uses). Conversion recovered to previous levels but it’s hard to claim we added value for the customer. There were, at least, a number of positives to come out of it. We’d intentionally taken an approach that allowed us to fail fast and learn quickly so we were able to rapidly improve the product. The post-mortem analysis (in particular the five-whys) was also very insightful and could arguably be seen as a catalyst for a lot of great progress made in the following months. And hopefully my skill at saying no has improved in the intervening time.