Do you sometimes look back at your original product plan wondering what happened?

You started with a clear product vision. Something you knew would satisfy the needs of your target audience. Hell, you could even picture their excitement seeing it for the first time. But then…

…Someone had a great idea and suggested a feature guaranteed to disrupt the market.

…You decided to act on a new trend.

…And a guy from the company next door hinted at another functionality your users might like.

…And suddenly your simple product is a bloat of features, most of which your customers don’t even need.

But you know, they say the secret to maintaining a product strategy is simple:

Learn to say no.

But I’d like to add one more element to the definition:

Learn to say no…most…of…the…time.

In today’s post I’ll show you how to recognize when to agree to a feature request.

Enter Feature Creep

feature creep

I’m sure you’ve heard the term “feature creep” already. In case you didn’t, let me go over that really quickly:

Feature creep (also referred to as scope creep, creeping featurism or featurititis) is a state in a project where its scope or product features continuously change as the work progresses.

But do you know what’s the biggest problem with it?

Most of the time you don’t even notice it happening!

Just consider a couple example scenarios:

You spot new trends in usage data and decide to act on them

Reviewing how users interact with the app you notice an intriguing trend…Or results from a small test group show a promising engagement with a particular new idea.

And so you decide to build it.

The catch? Even though it’s backed by data, a particular feature might not fit the overall product idea.

It’s a quick feature to build so why not?

Since a new idea is so tiny and simple, it only makes sense to bump it in the product roadmap, right? After all, It won’t take long to build but could help satisfy more users…


For one, simple ideas don’t exist. Every change you implement requires building, testing, and iterating…and then, launching, promoting and supporting it…

When it comes to features, simple ideas don’t exist.

Tweet This

A customer demands you build a feature for them…or else…

Imagine, you try to onboard a big enterprise client. But then, halfway through contract negotiations they start demanding a functionality your product lacks…

What do you do?

Being sales and growth-oriented you decide to change your production schedule, only to win a particular account.

We can build a feature for one customer and then sell it to others

So you agreed to build a feature to onboard a new customer. Then, with your business hat on, you decided to launch it to all users.

But you see:

Most users might not need such functionality. And the cost of taking away resources to satisfy a single customer is often too high.

You overhear someone saying your product needs something…

…and convinced they’re right, proceed to build it.

You notice competitors have it


You notice a competitor launching a new feature. Panic sets in. You begin to picture customers leaving you in tens.

And so you stop all other projects and set the team to build it too.

The trouble is, you don’t even know if the feature helps customers in any way. Perhaps it’s just a new shiny thing they’ll never even touch?

[cta id=’2003907′]

So, How do you Avoid Feature Creep? And When Should you Agree to a Feature Request?when to say yes to a feature request

As a product manager you encounter new ideas all the time. From coworkers, to users, down to nosy colleagues who think they know better, everyone has a suggestion. So how do you decide which ones to reject right away? And how should you identify ideas that deserve a closer look?

It’s actually quite simple. Ask yourself:

Does the new feature fit into my original product vision?

Product vision guides everyone involved in developing a product toward making it a success. It’s the goal you strive for, the reason why you created your product.

So every time you face a new idea, run it by your product vision.

Does the new feature fit into what you decided your product will be? Will it help customers overcome the problem you set out to alleviate?

I admit, this approach demands making tough calls…And accepting a fair share of criticism too (just ask Basecamp, labeled as blind ideologists because of their hard stand on implementing only features that fit their vision).

Will it improve my customers’ experience?

Everyone’s into social sharing these days, right? So it only makes sense to incorporate a social sharing element into your product.

Then again, if you’re building an online accounting app, what are the chances that your users will tweet the latest profit and loss report?

When assessing new features, consider if they will improve your users’ experience and help overcome their main problem you’re solving.

Is it future proof?

Is the proposed feature related to a current trend? Or is it timely enough that people will still want to use it in a couple years time?

It’s easy to get swayed from your vision by an emerging trend. Given the social media craze, it may make sense to build a social element into the app. Having said that, what if a particular social network changes the way it allows you to use their data?

Can you afford to support it?

You know, building a new feature is just part of the story. And problems often start only after you’ve built and launched it.

Bugs, revisions, support inquiries, marketing, and training add up to the cost of running your business.

So when assessing whether to say yes, calculate and consider the cost of maintaining the feature in the long run.

Will it help achieve your business’ goals?

Makes no sense, right?

After all, how may a tiny, spectral feature buried somewhere deep in the settings panel  affect your business?

And yet…

When confused by functionality, users tend to leave products for simpler alternatives.

Moreover, they tend to voice their experience with a product online. Social media, for one, is filled with complaints and opinions about poor product features.interface-feedback-600x234 new-feature-feedback-600x249 twitter-feature-feedback-600x260


I’m sure it’s no different on online forums and communities…

You see:

A dissatisfied customer will tell 9-15 people about their experience (source). And so, problems with even the smallest yet unnecessary feature could result in an online backlash…and make you lose customers.

Conclusionsay no to feature requests

Maintaining a healthy product roadmap is tough. It seems that everyone around you has ideas to make your product “even better.” But as a product manager,  job, you need to learn how to tell a viable feature request from a poor idea.

The secret to maintaining a product strategy is simple: Learn to say no.

Tweet This