Loki Meyburg

A lot has been written about saying “no” to feature requests. Steve Jobs said that having focus meant saying “no”, 37Signals wrote a chapter called “Start With No” and many other product managers have echoed the same advice. But, when is it time to say “yes” to a feature request? Here are 5 questions I ask before an idea can be promoted to your product’s roadmap.

Will it matter in 5 years?

I’m always reminded how quickly things go out of fashion in our industry by looking at designs from a few years ago. What was fashionable or “cool” two years ago looks tacky and outdated today. It’s really tempting to jump onto the newest design trend or integrate with a cool new app because it makes you feel modern.

“Find the things that won’t change in your business and invest heavily in those things.” - Jeff Bezos

Often times it’s things that aren’t fancy that you should be focusing on, such as making your app really fast and reliable. Don’t chase fads and trends, instead, focus on building something that will always be meaningful.

Can you support/afford it in the wild?

When you’re estimating work with your engineering team you’re estimating the “effort required to build something”. Which is why another cost - “the effort required to support the thing being built” - is often overlooked. Before you think something is a good idea, take a second to consider how much time will be required from you and your team once it’s in the hands of real users.

At Medeo, an app that lets doctors see their patients online, we only allow doctors to video conference using Google Chrome. This is deliberate. It’s not that video calls are impossible on Firefox or Opera, it’s that the cost of supporting every browser (and version number) would take too much time for our small development team.

Does it grow your business?

Can you make a case for how this feature will impact revenue? You are either creating new revenue (new accounts, account upgrades) or you’re preventing revenue from being lost (churn).

Sometimes it sounds like the perfect feature to build until you realize that it’s only improving the experience for existing users but won’t generate any new revenue.

As a product designer you’re always thinking of ways existing screens or interactions can be improved. But be careful of investing time and energy into something that’s already “great” or “good enough”. Instead focus on areas where you can really affect meaningful growth.

Will most of your customers benefit from this feature?

Ever found yourself hearing the same feature request again and again? Did you grow tired of saying of “no” to those customers who were asking for that feature? When we hear the same thing being asked repeatedly we incorrectly attribute importance to what’s being said.

Hearing 10 people ask for the same thing in one week sounds like it must be important, but remember they’re only 0.2% of the 5,000 active users that use your app.

You’ll need to investigate if the feature being requested would benefit most of your users or if what you’re hearing is only a small sample of vocal users.

Does this feature fit your product vision?

The more nuanced decision is deciding not to build something because it doesn’t fit your overall product vision. The decision often can be met with a lot of resistance. Deciding whether something fits your product vision is more of an art than a science but that decision rests with you and your team alone. You should have product principles that act as a guide when making these decisions.

Here are some examples of companies that took a step in a different direction:

Apple never released a netbook when they became very popular. Analysts believed they were making a big mistake. Apple released the iPad two years later.
Basecamp [doesn’t have gantt charts] (https://gettingreal.37signals.com/ch01_About_37signals.php) that are typically used to manage project schedules because they believe it doesn’t lead to better project management
Nintendo built the Wii because they believed video games should be fun & inexpensive while the rest of the industry was building graphically impressive and expensive titles

Assessing feature opportunities

Once you’ve answered “yes” to these 5 questions it’s time to create what I call a “feature opportunity assessment”. The Silicon Valley Product Group use an opportunity assessment for products as an alternative to creating a product spec and is intended to clearly and concisely define the problem to be solved. I’ve been using a slightly modified version that focuses instead on features that make up a product.

Exactly what problem will this solve? (value proposition)
Who exactly is having this problem? (persona)
How many people have this problem? (potential impact)
What alternatives are out there? (competitive landscape)
Why are we best suited to pursue this? (our differentiator)
Why now? (market window)
How will we measure success/make money from this feature? (metrics/revenue strategy)

Creating a “feature opportunity assessment” will help you understand what is required to succeed and where to prioritize this feature in your roadmap.

Idea to product roadmap. The Guantlet.

Great roadmaps are incredibly hard to build and always require trade-offs. But truly great product managers need a firm checklist for when they say “yes” to items being added to the roadmap. Compromising on your checklist, even just a little, leads to bloated software. Every feature needs to be brought through a gauntlet of inquiry before it can be promoted to your products roadmap.

When is it time to say 'yes' to a feature request?