One of the most challenging aspects of being a product manager is reconciling recurring customer feature requests with your overall product strategy. In our recent Product Stack webinar, Aligning Product Strategy with Customer Feature Requests, we received hundreds of great product-related questions from our attendees and thought it would be helpful to take a deeper dive into the most popular ones. We co-hosted the webinar with our Product Stack partners, Pivotal Labs and Notion, who also opted to answer a couple of standout attendee questions. Their answers can be found here and here, respectively.

During the webinar, we received dozens of versions of the following question: At what point do recurring feature requests signal market demand and a need to re-evaluate your product strategy?

 

This is a slippery (yet extremely common) way to frame the question because it points to the idea of a point where you reach a “critical mass” of feature requests. Something like, “If you receive X requests for the same feature, then you should build the feature and update your strategy.”

From one perspective, this seems fairly reasonable. There’s obviously a demand for a feature if you’re getting a ton of requests, right? But. This is a very reactive (and not particularly strategic) way to respond.

As a rule, your product strategy should be flexible, but pretty consistent over a given period of time. Ideally, when you developed your product and business strategies, you went through a solid market validation process, considering a number of factors to determine the right product-market fit.

Your product shouldn’t have to pivot every three months based on customer feedback. So, if it’s not a magic number of requests, how do you know when you should adjust strategy based on feature requests?

Here are 6 questions you can use to guide your thinking:

1. What are your customers really asking for?

This question becomes much simpler to approach when you think of the feature request less as a request for a “new button,” “app integration,” “configuration option,” etc., and more as a request for a solution to a specific problem. When a number of feature requests come in, your customers are signaling that they have a shared challenge.

Identifying the problem your customers are trying to solve is critical because it lets you perform a quick litmus test: Is this problem something our product is supposed to solve? Is this problem one that we want our product to solve?

Remembering that your customers are requesting things because they have a job to do is an important step. They’re not asking you to add a button because they love buttons—well, most of them aren’t; they’re asking for a button because it will make their jobs and workflows easier, faster, more efficient, or enjoyable. It might help them build more widgets or ship more software. Understanding their real intentions and motivations is an important part of this process.

2. Does this problem align with your broader strategy?

Once you have a lock on the underlying challenge behind the feature request(s), you can better determine whether that problem is something you want your product to solve. Would building this new feature or capability align with your overall strategy or deviate from it? If it aligns with it, is it worth prioritizing over other features in your backlog? Is this something you initially considered when you first developed your strategy, or is it a wild departure from your product’s mission? It might be that your market and customer have evolved, but it could also be a waste of time.

With your strategy in mind, it might not matter to you if you get 1,000 requests for a feature that isn’t aligned with your product’s primary goals. On the other hand, you might get one great request that would really propel your product forward.

3. What are the positive and negative impacts on business metrics if we add or ignore this feature?

If you build this feature, are you likely to see an increase in revenue? A decrease? Are you gaining entry into a new market, one that you had been planning to enter? Would it increase customer retention rates and slow down churn? It’s much easier to make a strategic decision when you can back it up with data and projections.

Tweet This:
“Ask yourself: What are the positive and negative impacts on business metrics if we add or ignore this feature?”

If you’re re-evaluating your product strategy just to meet a handful of customer requests, you might be setting yourself up for failure.

4. How big is the project?

What’s the required investment and overall level of effort involved? This can be a gut-based kind of calculus, but as a product manager you should have a quick, instinctual sense of the scope of a given request. Would this request involve a quick UI update, or a major code refactor? Is there a huge potential for scope creep, i.e. if you start development on feature X are there a bunch of dependencies involved that would require development on features Y, Z, etc.?

5. What’s the opportunity cost?

Now that you have a sense of the scope of the feature, what resources would be required? Would it be worth pulling your team off of other projects to work on this one? There’s a lot of cost-benefit analysis that happens when weighing feature requests against your overall strategy.

Whether requests come from customers or internal stakeholders, a product manager is responsible for allocating her development resources in a way that advances her strategy without wasting the team’s time and energy.

6. Does it require further investigation or research?

Maybe, after moving through steps 1-5, you’re starting to sense it might be worthwhile to further explore adding the feature. That doesn’t mean you should start development immediately. It just means the feature gets added to your backlog, or to your Parking Lot or Planning Board. Do some more research. Interview your customers to further understand the problems this new feature would solve. Treat it like any other new component or feature.

____

At the end of the day, there’s no formula for determining when it’s time to take development action on a given request. Maybe the request is great and would really move the right needles for your organization. Maybe the environment you developed your original product strategy in has evolved significantly and your customer persona has evolved with it. Maybe not. Maybe it would be a distraction or push you into a customer segment you’re not interested in targeting.

You need to use your instincts as a product manager, supplemented by business success metrics, and conversations with your customers and product team, to determine if a feature request warrants a re-evaluation of your product strategy or if it’s an opportunity to say “no” to your customer.

That’s for you to feel out and investigate using the questions above.



Have more suggestions for how to balance customer feature requests with your overall product strategy? Leave them in the comments below!

Post Comments

One Comment

  • Greg Cohen
    September 17, 2017 at 12:26 pm

    Great and actionable advice. As you point out, the PM needs to drill down to the reason for the request. Otherwise, the PM is just an “order taker” and that’ not PM.

Leave a Comment

Your email address will not be published.