Managing the 'Shiny Object': How to Say No to Executives Using Data
Every product manager eventually faces the same scenario. You are mid-sprint, the team is executing on a validated roadmap, and an executive walks in — or sends a Slack message — with a new feature idea. It is urgent. It is strategic. It came from a customer meeting, or a competitor analysis, or an intuition from someone who has been in the industry for twenty years. And it completely disrupts the plan you spent the last two weeks building. This is the HiPPO problem: the tendency for product decisions to be driven by the Highest Paid Person's Opinion rather than by evidence about what users actually need and what the team is best positioned to build right now.
The HiPPO problem is not a personality flaw or a management failure — it is a structural problem. In organizations without a shared framework for evaluating feature requests against outcomes, the default decision-making variable is authority. Whoever has the most authority wins the argument. The PM who can replace authority with evidence — who can show, objectively and with data, why one initiative is more likely to drive the desired behavioral outcome than another — is the PM who can actually manage the shiny object problem without resorting to political capital they can only spend once.
Evidence-based PMs replace 'it is not on the roadmap' with 'let us evaluate this against our Key Results.'
Understanding Why HiPPO Decisions Are Hard to Resist
The HiPPO problem persists because it exploits a real asymmetry in product organizations. Executives have more authority, more context about strategic direction, more relationships with key customers, and more visibility into competitive threats than most PMs. Their feature requests are not random — they are typically grounded in real signals from the market, even if those signals have been interpreted subjectively and without systematic analysis. The PM who dismisses executive requests as 'just opinions' is both tactically wrong and strategically foolish. The executive's input is data. The problem is that it is a single, unweighted data point being treated as a definitive answer.
The constructive reframe is this: executive feature requests are hypotheses, just like any other feature request. They represent the executive's belief that Building X will drive Outcome Y for Customer Segment Z. The PM's job is not to resist that hypothesis or accept it uncritically — it is to evaluate it against the team's current OKRs, the existing behavioral evidence, and the other hypotheses currently in the discovery pipeline. When an executive request is evaluated on these terms rather than on the basis of authority, the conversation shifts from 'Are you saying my idea is bad?' to 'Let us figure out whether this hypothesis is the right one to test given our current strategic priorities.'
Using OKRs as a Decision Filter
OKRs are the most powerful tool available for making HiPPO-resistant product decisions, because they provide a shared, authority-neutral framework for evaluating whether a feature request is strategically aligned. When a team has well-defined Objectives and Key Results that are publicly shared and endorsed by leadership, every new feature request can be evaluated against a simple question: which of our current Key Results does this initiative serve? If the answer is clear and compelling — 'This feature should drive a significant increase in our 'new users who complete activation' Key Result' — then the initiative has a legitimate claim on the team's attention. If the answer is vague or non-existent, the initiative is a distraction from the team's current strategic commitments, regardless of who requested it.
The critical enabler of this approach is having OKRs that are specific enough to serve as a genuine filter. Vague OKRs — 'Improve the user experience' or 'Grow our customer base' — are useless as decision tools because almost any feature can be rationalized against them. Specific OKRs in the 'Who Does What By How Much' format — 'Trial users who complete onboarding activate at least one integration within their first session, at a 35% rate or higher, by end of Q2' — create a clear, objective standard. The executive's shiny object either contributes to this specific behavioral change or it does not. That is a factual question, not a political one.
OKRs provide an authority-neutral filter for evaluating any feature request.
Building Your Evidence Portfolio
Making the transition from HiPPO-driven to evidence-driven decisions requires building and maintaining an evidence portfolio: a running record of what the team has tested, what was learned, and how that learning informs the current priority set. This portfolio serves two purposes. First, it gives the PM a concrete body of evidence to draw on when evaluating new feature requests against existing priorities. 'We actually tested a version of that idea in Q1 and observed that users in that segment don't respond to that kind of prompt' is a factual rebuttal that authority cannot easily override. Second, it builds the credibility of the evidence-based approach over time.
The evidence portfolio does not need to be elaborate. A shared document or spreadsheet that records each experiment the team has run — what was hypothesized, what was tested, what the behavioral data showed, and what decision was made as a result — is sufficient. The discipline is in maintaining it consistently and referencing it explicitly in prioritization conversations. When executives see that the PM is making decisions from a documented evidence base rather than personal preference, and when some of those evidence-based decisions produce strong outcomes, the credibility of the evidence-based approach compounds. The PM earns the right to say 'the data suggests otherwise' by demonstrating a track record of making decisions from data that produces results.
Having the Conversation: A Script for Difficult Moments
When an executive brings a shiny object, the worst response is a direct refusal. 'That is not on the roadmap' closes the conversation without addressing the underlying signal. The better approach acknowledges the signal, reframes it as a hypothesis, and routes it through the team's evaluation process. A practical script: 'I hear that this customer conversation surfaced a real pain point. Let me understand what outcome you are hoping this feature would drive — which of our current Key Results does it relate to? I want to make sure we are evaluating this properly against the work the team already has in flight.' This response treats the executive's input with respect, establishes the evaluation framework, and buys time for a considered decision rather than a reflexive one.
In organizations where the evidence-based culture is still being established, PMs often need to invest in the relationship before the framework. An executive who trusts the PM's judgment — who has seen the PM make good calls before, who knows the PM has their interests in mind — is an executive who will accept 'let me route this through our evaluation process' as a reasonable response. Building that trust requires proactive communication: sharing behavioral data from experiments before you are asked, explaining the reasoning behind prioritization decisions in terms of outcomes rather than capacity, and being genuinely curious about the executive's strategic instincts rather than treating them as obstacles. The goal is not to win arguments. It is to build a shared language for making product decisions from evidence.
The Bottom Line
The HiPPO problem is not solved by better politics or better process alone. It is solved by creating the organizational conditions in which evidence is more influential than authority — which requires a shared framework for what evidence means, consistent application of that framework to all feature requests regardless of their source, and the credibility that comes from making evidence-based decisions that consistently produce results. OKRs provide the framework. The PM's job is to build the culture around it.
Related Posts from Sense & Respond Learning
Moving from Dates to Deliverables: How to Build an Outcome-Based Roadmap
Why 'Velocity' Is a Vanity Metric (And What to Measure Instead)
The 'HiPPO' Problem: Why Your Opinion Is the Most Dangerous Thing in the Room
Further Reading & External Resources
Who Does What By How Much? — Jeff Gothelf & Josh Seiden — The OKR framework that makes feature prioritization objective and evidence-based
Inspired — Marty Cagan — The industry-standard guide to building products in a product-led organization
Good Strategy, Bad Strategy — Richard Rumelt — On the importance of genuine strategic focus vs. wish-list thinking
Want to go deeper? This post is part of the Sense & Respond Learning resource library — practical frameworks for product managers, transformation leads and executives who want to lead with outcomes, not outputs.
Explore the full library at https://www.senseandrespond.co/blog
