OUR RESEARCH PROCESS

This article was written by a startup veteran who managed multiple products from inception to launch and beyond at Jet.com, which was acquired for $3.3B by Walmart with over 4 million users. She now works Store No. 8 on the Intelligent Retail Lab project.

IF YOU REMEMBER NOTHING ELSE

  1. Respond honestly and constructively. Don’t over-promise or let requests go unanswered.
  2. Listen with an open mind, you might reject the specific request, but end up with different feature that drives your strategy forward.
  3. Go back to the basics when saying no, support your decision with metrics, strategy goals, and a strong backlog. Also makes sure to log everything.

Card Count Icon 9 cards
Card Count Icon 10 minutes
Principle
What it looks like
Make sure people feel heard
Coworker: “Thanks for sharing that idea with me, do you mind if I ask a few questions to clarify?”
Customer: “Thanks for sharing your feedback, while we aren’t able to action it right now, please always feel free to reach out with thoughts like this!”
Understand the use case
Internal: “Thanks for sharing that idea with me, do you mind if I ask a few questions to clarify?”
Customer: “Thanks for sharing your feedback, while we aren’t able to action it right now, please always feel free to reach out with thoughts like this!”
Stick to your prioritization process
Internal: “Right now, our backlog has [x features] in it, so we won’t be able to tackle this idea.”
Customer: “We are currently working on [x new feature] right now, and have some exciting future releases lined up. I hope you’ll continue to give us feedback on our product as we make these additions!”
Leverage data and metrics
Internal: “Based on past performance of [x feature type], it doesn’t seem like the best use of resources to invest it in. Instead, we should focus on [y feature] that we have prioritized projected to perform [z metric].”
Customer: No need to share these - a polite refusal to make them feel heard will suffice!

Sometimes customers or internal stakeholders will run into a roadblock while using the product. This happens most often with product power users (people that use the software every day for their job, or vocal internal stakeholders).

Bear in mind that rejecting feature requests from these users could mean you will speak directly to a core, vocal component of the product’s user base. Instead of rejecting their suggestions outright, ask questions about what goals they're trying to accomplish by using the product, then problem-solve ways of allowing them to meet those goals. Doing so reinforces their relationship with the product and potentially identifies a broader use case that could turn into a valuable feature.

Sample response:

“Could you walk me through what you’re trying to accomplish with [x product/action]? I want to be sure I understand what you’re experiencing.” From there, you can gather the core of the user’s request, and either tell them that it’ll go in the product backlog, or gently inform them that while their particular use case is frustrating, the product isn’t meant to complete that particular goal, and suggest another way to meet their needs, if possible.

Both customers and internal stakeholders will come to you with feature requests that would save them time or energy, but don’t line up with the amount of development effort (i.e. company investment) that the changes would require.

In these cases, acknowledge the value of the feature request and explain the reality of the development load currently on the team. With an internal stakeholder, this can be a conversation about the product backlog and tradeoffs can be offered. With a customer, this can be a chance to walk them through upcoming features (if you're allowed to announce them) that relate to their usage of the product.

On occasion, you will have to establish that though the user's request is valuable, fulfilling it would be too great an investment to be worth building. It’s important not to lie to or mislead either internal or external stakeholders about a request going into the backlog - that can break trust and doesn’t benefit either party.

Sample internal response:

“[x feature request] sounds like it would improve [y reason they’ve suggested it], and unfortunately, it would be a stretch for our development team to take on when we’re already focused on [a, b, c features] that will have [z impact].”

Sample external response:

“Thank you for sharing your feedback on the product, while we would love to be able to action this, we don’t have the development resources to accommodate it while we work on [x new feature launches]. Hopefully these new features will provide value to you, and we look forward to hearing about your experience with them!”

Sample external response:

“Thank you for sharing your feedback on the product, while we would love to be able to action this, we don’t have the development resources to accommodate it while we work on [x new feature launches]. Hopefully these new features will provide value to you, and we look forward to hearing about your experience with them!”

“Thank you for sharing your feedback on the product, while we would love to be able to action this, we don’t have the development resources to accommodate it while we work on [x new feature launches]. Hopefully these new features will provide value to you, and we look forward to hearing about your experience with them!”

“[x feature request] sounds like it would improve [y reason they’ve suggested it], and unfortunately, it would be a stretch for our development team to take on when we’re already focused on [a, b, c features] that will have [z impact].”

Sample external response:

“Thank you for sharing your feedback on the product, while we would love to be able to action this, we don’t have the development resources to accommodate it while we work on [x new feature launches]. Hopefully these new features will provide value to you, and we look forward to hearing about your experience with them!”

Sample external response:

“[x feature request] sounds like it would improve [y reason they’ve suggested it], and unfortunately, it would be a stretch for our development team to take on when we’re already focused on [a, b, c features] that will have [z impact].”

Sample internal response:

“[x feature request] sounds like it would improve [y reason they’ve suggested it], and unfortunately, it would be a stretch for our development team to take on when we’re already focused on [a, b, c features] that will have [z impact].”

Sample external response:

“Thank you for sharing your feedback on the product, while we would love to be able to action this, we don’t have the development resources to accommodate it while we work on [x new feature launches]. Hopefully these new features will provide value to you, and we look forward to hearing about your experience with them!”

“Thank you for sharing your feedback on the product, while we would love to be able to action this, we don’t have the development resources to accommodate it while we work on [x new feature launches]. Hopefully these new features will provide value to you, and we look forward to hearing about your experience with them!”

“[x feature request] sounds like it would improve [y reason they’ve suggested it], and unfortunately, it would be a stretch for our development team to take on when we’re already focused on [a, b, c features] that will have [z impact].”

“Thank you for sharing your feedback on the product, while we would love to be able to action this, we don’t have the development resources to accommodate it while we work on [x new feature launches]. Hopefully these new features will provide value to you, and we look forward to hearing about your experience with them!”

Sample external response:

Sample internal response:

This type of feature request will come from internal stakeholders and customers alike. A word of caution: if you’re hearing a feature request over and over, it could be a sign that you’re missing market fit, and it should be surfaced in a strategy meeting. Otherwise, when talking with an internal stakeholder, draw their attention back to the product backlog in terms of the strategy. When talking with an external customer, thank them for their feedback and briefly explain upcoming releases and the direction the product is going. If there’s another product that will solve their need (especially one from your company!), then point them that way. You don’t have to explain the company strategy, but do reinforce the purpose of the product and try to solve their problem with them.

Internal stakeholder sample response:

“I see the value of what you’re suggesting, but I don’t think it rolls up into our strategy for this quarter. Let’s stay focused on [x, y, z goals], and revisit this when we go through our next strategic planning session.”

External stakeholder sample response:

“Thank you for taking the time to send us your feature request, it’s always great to hear from customers. We aren’t going to be able to implement this right now, as we’re focusing on [x, y, z feature or an upcoming set of features we hope you’ll find value in/enjoy using]. Please let us know what you think after the release!”

This type of feature request comes most often from an internal stakeholder rather than an external, as most customer requests with low demand would fall more into the edge case scenario. To reject this type of feature request, suggest customer research and polling be done around the feature to determine what the projected adoption would be.

If you’re working in a lean environment without cycles to devote to research, emphasize the existing strategy and goals to help drive the product roadmap away from features that won’t have traction with customers.

One exception to this rule of focusing on customers would be features needed to win over investors or board members, which should be discussed in a trade offs conversation with the stakeholders of the product. Always try to drive the conversation back to features that would bring value to the user or the company.

Responding to a request from a person in management can be tricky, but if handled well, can result in a better product and greater alignment around the work the team is doing.

  • Don’t get defensive, try to take every suggestion as a positive sign, it means that they care about what’s happening with the product! Welcome suggestions, even if you disagree with them.
  • Know that sometimes their rank will outweigh your prioritization process. Handle this graciously, and trust that they have the product’s best interest at heart.
  • Remind them of the currently product strategy and backlog, and offer tradeoffs if necessary to help fit in their suggestion. This will help them see that their idea may not fit with the plan.
  • Work with them to understand why they’re suggesting the idea. Get to the heart of the need, and see if there’s an alternative way to meet it in the product.

Regardless of whether a feature request comes from an internal or external stakeholder, it’s important that your process of managing them captures the following elements:

4uqVL_MvIML6JJXeb9e3J48fBigz-Cv03nVQf4PnCLUo14uFFxuNMF3N6FInRK77G75jXOyBzIBfda8sEvaUr3r9bM4ZQn2_caOjSUC5tBmtfgHs0csv_dBKD6BAwl5CrQ

Schedule regular time to go through requests. Set expectations with stakeholders about how and when they can expect to hear from you, and design this feedback to be convenient for your team. For example, put their feedback into the ticket in Jira rather than sending a personal email to the requester. This keeps track of the request’s history and keeps all the information in a single source.

Instead of...
Try...
Personally managing each request
Implementing a process for responding to requests
Getting defensive
Understanding the heart of the request
Promising future work
Communicate the decision, even if it’s a rejection
Prioritizing work based on internal politics
Point internal stakeholders back to the strategic goals
Rejecting requests out of hand
Gathering metrics and user testing results to support your stance