Rarely say yes to feature requests

Here’s a simple set of Yes/No questions that you can quickly answer before you add another item to your product roadmap.

Saying yes to a feature request – whether it’s a to an existing customer, a product enquiry, a teammate, or a manager – is immediately rewarding. It’s an unspoken transaction where you barter long term product focus in exchange for short term satisfaction. Buying short term joy for the cost of long term pain is the human condition.

Previously we’ve written about how product strategy means saying no, but a list of reasons to reject a feature isn’t as immediately useful as a test that any new feature must pass. Lots of our readers made that exact point to us too:

So here’s a list of questions your new feature must score straight yes’s on.

1. Does it fit your vision?

More important than any metric, customer request, or sales target is your vision. What do you believe that no one else does? What do you know about this problem that no one else does? How do you believe it should be solved? Anyone can pull the data, run the focus groups, read the Gartner reports, get out of the building, but only you have your vision.

Product decisions based on vision alone sometimes seem irrational, because they’re tough decisions. Most people understand that their bug tracker doesn’t also monitor server uptime. That’s rarely debated, it’s not a marginal call. But should a project management tool have a reporting feature? Not so clear.

The more nuanced decisions are the ones where you meet resistance. Colleagues, customers, even other product managers and founders will push back. Here’s some examples.

• Garrett Dimon refuses to add an “on-hold” state to his issue tracker, Sifter, as he simply doesn’t believe it’s the right way to manage issues.
• Apple refused to ship netbooks at a time when netbooks were the most popular style of PC. Every analyst demanded them.
• Basecamp refused to add Gantt Charts. For that they were labelled blind ideologists

Worse than being a hard decision, you’ll never truly know if you got it right. There is no right. There is no wrong. This is art, not science. It’s just you and your vision.

2. Will it still matter in 5 years?

There’s nothing like the immediate gratification from jumping on the latest trend. Twitter cards, Google Glass Apps, apps for wearables, Facebook apps, some new JavaScript effects library – it’s all crying out to be used. It’ll make you feel modern.

It’s a hard and boring question to ask but will this still deliver value in five years time? You’ll feel like the curmudgeon of product planning. But that app that was so hot in 2013 was gone by 2014. Those slide, fade, and fold effects that everyone loved last year look tacky as hell this year. If you’re going to spend the best years of your life on a product eschew the trendy, and focus on the meaningful.

3. Will everyone benefit from it?

Beware the “fre-cently” bias. You assume the things you hear frequently or recently should without doubt be road-mapped. It’s a natural reaction caused by your inbuilt empathy for customers. It’s not nice to tell people “no” repeatedly and hear the same responses over and over, so when possible “fre-cently” is used as an excuse to reward yourself. “Sure we’ll build that, I’ve heard it twice today already,” says the founder with 4,800 daily active users, to the unbridled joy of 0.0625% of her customer base.

The danger of the fre-cently bias is that it gives you the illusion of analysis, the sense that you’ve done your homework and this is a rational conclusion you’ve come to. In reality you’ve made a lazy decision to satisfy the whims of a small sample of vocal users without taking a second to investigate how many people really want or need the feature.

4. Will it improve, complement or innovate on the existing workflow?

Adding a whole new workflow to your product should be a rare occurrence. The majority of your time should be invested in improving, complementing, or innovating upon existing ones, and for any given project you should know which of these you are doing.

If you’re improving the current solution, your metric will be customer satisfaction and/or maybe a decrease in tool time, or support requests.

If you’re complementing it, your metric will be an increased throughput for the workflow as it now works in more cases or can be used in more circumstances.

Innovation is the trickiest. You’re shooting for the mythical “whole new way”, which carries so much risk but offers so much reward. Your measure will likely be new customers acquired though often they come indirectly, as a result of the PR, marketing or awareness created.

Redesigns are fun, but you can spin your wheels on them. A good way to cut through the bullshit is to simply ask “Will more people use it? Will people use it more? If neither, then will it definitely be better for those who do use it?”

5. Does it grow the business?

Can you join the dots between the impact this new feature will have and new revenue? In the example above the company makes the case for project templates, the argument being that templates can be used in more cases, which should increase the number of projects customers have, which in turn increases upgrades, and thus revenue.

Note that reducing churn also grows the business; dollars don’t care where they come from. Often a feature is added to ensure stickiness of customers, or to widen the moat around a product. The key point in all cases is to understand how any work affects growth, after all everyone works on growth.

6. Will it generate new meaningful engagement?

Most metrics ignore the system and focus on the isolated feature being added. Put a new button in your product and people will click it. Get enough clicks and you can call that an increase in engagement. But that’s nonsense. A counter-metric is “have people stopped doing anything else”. So if you add a metric to track one area of your product, you must also analyse the other areas that are likely to be impacted.

A real world metaphor is the effect of “Diet Coke with Lime” on Diet Coke sales. We see how launching a whole new workflow affects sales. If you’re the PM on Diet Coke with Lime, you could call your launch a success, but if you’re the CEO you’ll realise you complicated your product line, bought all these limes, all these juicers, and all that advertising, and have no new revenue to show for it. Not exactly a success, no matter what metrics that PM can show you.

7. If it succeeds, can we support & afford it?

One fallacy of “quick wins” and “easy hacks”, is they usually only evaluate effort required before shipping e.g. someone surprises you with a JavaScript bookmarklet for your app, or an agency produces a Windows Phone app in record time and low cost, and because the effort was relatively minimal, and the idea makes sense, you ship it. Success!

Then the support requests come in, and it turns out none of your team know XAML, so you’re stuck with a broken build live, and a few hundred customers complaining to support about it. Of course it’s never that obvious. Good engineers rarely say they don’t know something, they’ll hack at it some evenings, display some initial competency, and then estimate how long until they fix the bug. This is all time that you didn’t plan on spending when you shipped this app. And that estimate is wrong. And then some.

Another area that can bite is offering incentives, or initiatives that you can’t justify. If you have a CMS product, and you offer free homepage designs, you’ll get more sign-ups. It makes sense to do this early on, when you really need to entice customers to try an as yet unproven product, but it won’t work long term. It goes without saying that doing things that don’t scale is a great strategy, until you scale.

8. Can we design it so that reward is greater than effort?

As Paul previously wrote, for any feature to be used the perceived benefit has to be greater than the perceived effort. End users understood the benefit Google Plus could bring, but the overhead of dragging and dropping many copies of your contacts into various boxes, on a regular basis, was simply not worth it. I feel that check-splitting apps habitually fall into this category. Splitting a check can be a pain point, but any solution seen thus far still costs too much, and we’re not talking about price. We’re talking about time, overhead, social capital, etc.

Product design is about cost-benefit analysis. How useful is something, vs how hard is it to do. Here’s how I think of it…

It’s important to know which quadrant you’re designing in and if you’re wise you’ll steer clear of the upper left for all but the most essential of features.

9. Can we do it well?

Every product has its neglected corners, usually areas where the PM dabbled but conceded defeat. Conceding defeat all too rarely results in removing a feature, it usually just means ignoring it, leaving a messy trail and a confused offering.

The problem here is when product teams tackle areas they don’t fully understand. This is often the case when a team moves beyond self-design, that is, past the point where they are their customer. At this point their design process breaks, and they need a new one. Examples include:

• Teams that don’t track time adding a time-tracking feature
• People who don’t manage calendars designing a calendar management option.
• Designers who don’t close issues building an issue tracking system

Note that none of the above are inherently wrong, what’s wrong is the design process. It needs to move beyond “works fine for me” into something much more activity focussed. To build a feature well, you have to understand the job it does intimately. As a corollary to the old saying: if you can’t do it well, it ain’t worth doing.

10. Can we scope it well?

Starting with the cupcake release for a feature is essential. Early usable releases provide the feedback necessary for an idea to flourish. A good sign that a feature isn’t well scoped is when it lacks specifics, e.g. “Make it work for bigger companies”, or that it’s feature based e.g. “reports”, as opposed to job-based e.g. “Let sales managers see their team performance”.

It’s always easy to agree on truisms in product meetings. Someone says “It should be easier for bigger teams”, everyone nods, and a Post-it gets stuck on a whiteboard. It’s only in the specifics that you’ll understand the scope e.g. “we should let people group their colleagues by department” vs “we just need an enterprise mode”.

Badly scoped features meet no ones requirements, ship late, if at all, and add nothing to the product but confusion.

Slippery Slopes & Marginal Calls

It’s tempting to excuse occasional violations of this list, assuming that “as long as it’s right most of the time”, it’ll be fine. Maybe that’s true in theory, but this is software. Reality bats last here. This is why we say that product strategy means saying no. Roadmaps are incredibly hard and require agonizing trade-offs, but regardless, every good product manager needs a firm checklist for when they say yes, and when they say no. And they don’t make exceptions.

Products get bloated one lazy decision at a time. There is no single choice you’ll make where some light turns on saying “Your Product is Now Too Complex”, and you’ll never get an email saying “Last Thursday at 2:03pm Your Product was Disrupted”. Bloat, complexity, and disruption can only be seen in the rear view mirror, so always be mindful of the risk of saying yes.

Want to read more of our product best practices? Download our free book, Intercom on Product Management. It’s recommended by folks like Ryan Singer, Hunter Walk, and Dharmesh Shah.