Handling an ambiguous stakeholder feature request from discovery to decision

Quick Overview

A behavioral product manager question about handling a feature request that arrives without a clear problem, user or success measure. It tests discovery skills, use of evidence, collaboration with engineering on feasibility, prioritization against the roadmap, and communicating the decision back to stakeholders.

Handling an ambiguous stakeholder feature request from discovery to decision

Company: American Express

Role: Product Manager

Category: Behavioral & Leadership

Difficulty: medium

Interview Round: Other

You are a product manager, and a stakeholder sends you a feature request that is vague: it says what they would like built but not what problem it solves, who needs it or how anyone would know it worked. Walk the interviewer through what you do next, from the moment the request arrives until the team either commits to building something or declines, and ground your process in a time you actually handled a request like this. ```hint Request versus need A vague request is often a guessed solution sitting on top of a real problem. What would you need to learn before you could judge whether the requested feature is even the right answer? ``` ### Clarifying Questions - Who sends the request: an executive, a sales or account team relaying a client's ask, a customer directly, or an internal operations team, and should that change how it is weighed? - Has anyone already promised the feature to a client or attached a deadline to it? - Does the team have a committed roadmap and quarterly goals the request would compete with? - Can the example come from any role where you turned an unclear ask into a delivered outcome, or should it come from a product role? ### What a Strong Answer Covers - Discovery of the problem behind the request: the goal, the affected users, what triggered the ask and what people do today without it. - Validation with evidence such as usage data, support tickets or user conversations, and a rough sense of how large the opportunity is. - Early input from engineering and design on feasibility, cost and alternatives, including options smaller than the literal request. - A decision weighed against current priorities and communicated back to the requester, including how to say "not now" or "no" without damaging the relationship. - A specific, honest example in STAR form with a measurable result and a lesson learned. ### Follow-up Questions - The requester is a senior executive who will not explain the reason and simply wants it built. What do you do? - Your investigation shows the feature would help only one client, but that client is one of the largest accounts. How do you decide? - How do you stop a stream of vague requests from turning into an unmanageable backlog?

Overview: A behavioral product manager question about handling a feature request that arrives without a clear problem, user or success measure. It tests discovery skills, use of evidence, collaboration with engineering on feasibility, prioritization against the roadmap, and communicating the decision back to stakeholders.

American Express logo
American Express
Jan 12, 2025
mediumProduct ManagerOtherBehavioral & Leadership
0
0

You are a product manager, and a stakeholder sends you a feature request that is vague: it says what they would like built but not what problem it solves, who needs it or how anyone would know it worked. Walk the interviewer through what you do next, from the moment the request arrives until the team either commits to building something or declines, and ground your process in a time you actually handled a request like this.

Clarifying Questions Guidance

  • Who sends the request: an executive, a sales or account team relaying a client's ask, a customer directly, or an internal operations team, and should that change how it is weighed?
  • Has anyone already promised the feature to a client or attached a deadline to it?
  • Does the team have a committed roadmap and quarterly goals the request would compete with?
  • Can the example come from any role where you turned an unclear ask into a delivered outcome, or should it come from a product role?

What a Strong Answer Covers Guidance

  • Discovery of the problem behind the request: the goal, the affected users, what triggered the ask and what people do today without it.
  • Validation with evidence such as usage data, support tickets or user conversations, and a rough sense of how large the opportunity is.
  • Early input from engineering and design on feasibility, cost and alternatives, including options smaller than the literal request.
  • A decision weighed against current priorities and communicated back to the requester, including how to say "not now" or "no" without damaging the relationship.
  • A specific, honest example in STAR form with a measurable result and a lesson learned.

Follow-up Questions Guidance

  • The requester is a senior executive who will not explain the reason and simply wants it built. What do you do?
  • Your investigation shows the feature would help only one client, but that client is one of the largest accounts. How do you decide?
  • How do you stop a stream of vague requests from turning into an unmanageable backlog?