Declining Feature Requests While Keeping Stakeholder Trust as a Product Manager

Quick Overview

A behavioral product manager question about turning down feature ideas and stakeholder requests. It tests how a PM weighs a request against the problem behind it, current goals and the roadmap, and how they decline in a way that keeps executives, sales, peers and customers on side, backed by a real example.

Declining Feature Requests While Keeping Stakeholder Trust as a Product Manager

Company: Meta

Role: Product Manager

Category: Behavioral & Leadership

Difficulty: medium

Interview Round: Other

Product managers hear far more feature ideas than a team can build. They come from leadership, sales and support, engineers and designers, other PMs and customers. How do you decide that a request should not be built, and how do you deliver that "no" so the person still trusts you and keeps bringing you ideas? Give your general approach and back it with an example from your own work. ```hint Two separate problems Treat deciding and communicating as two different steps. For deciding, think about what you would need to know about a request before you could weigh it against work already planned. For communicating, think about what changes when the person asking is an executive or a large customer instead of a peer. ``` ### Clarifying Questions - Should I describe a general method, walk through one real situation where I turned a request down, or both? - Should the answer cover requests from people with more authority than me, such as an executive or a key customer, as well as requests from peers and my own team? - Does "saying no" include "not now", where the idea is parked with a condition for revisiting it, or only a permanent no? ### What a Strong Answer Covers - A repeatable way to evaluate a request: the user problem behind it, its fit with current goals and target users, and its priority against work already planned - Looking past the proposed feature to the underlying need, including cheaper ways to meet it - Delivery adapted to who is asking, built on shared criteria and evidence rather than personal opinion - Protecting the relationship: credit for the idea, a clear reason, a path to revisit and closing the loop later - A specific example told in STAR form, with the outcome and what the candidate learned ### Follow-up Questions - An executive still wants the feature after you have shown the evidence against it. What do you do next? - Tell me about a request you declined that later proved to be worth building. What did you change afterwards? - A sales lead says a large deal depends on a feature that only that one customer has asked for. How do you respond?

Overview: A behavioral product manager question about turning down feature ideas and stakeholder requests. It tests how a PM weighs a request against the problem behind it, current goals and the roadmap, and how they decline in a way that keeps executives, sales, peers and customers on side, backed by a real example.

Meta logo
Meta
Jun 6, 2024
mediumProduct ManagerOtherBehavioral & Leadership
0
0

Product managers hear far more feature ideas than a team can build. They come from leadership, sales and support, engineers and designers, other PMs and customers. How do you decide that a request should not be built, and how do you deliver that "no" so the person still trusts you and keeps bringing you ideas? Give your general approach and back it with an example from your own work.

Clarifying Questions Guidance

  • Should I describe a general method, walk through one real situation where I turned a request down, or both?
  • Should the answer cover requests from people with more authority than me, such as an executive or a key customer, as well as requests from peers and my own team?
  • Does "saying no" include "not now", where the idea is parked with a condition for revisiting it, or only a permanent no?

What a Strong Answer Covers Guidance

  • A repeatable way to evaluate a request: the user problem behind it, its fit with current goals and target users, and its priority against work already planned
  • Looking past the proposed feature to the underlying need, including cheaper ways to meet it
  • Delivery adapted to who is asking, built on shared criteria and evidence rather than personal opinion
  • Protecting the relationship: credit for the idea, a clear reason, a path to revisit and closing the loop later
  • A specific example told in STAR form, with the outcome and what the candidate learned

Follow-up Questions Guidance

  • An executive still wants the feature after you have shown the evidence against it. What do you do next?
  • Tell me about a request you declined that later proved to be worth building. What did you change afterwards?
  • A sales lead says a large deal depends on a feature that only that one customer has asked for. How do you respond?