Watch the Full Interview
How One Product Manager's Bold Pushback Reshaped Stakeholder Relations and Priorities
Have BackboneExpert Roundtable
5 experts discuss this interview
Marcus Johnson
Director of Product
Sarah Chen
VP of Engineering
Jordan Taylor
Senior Client Success Manager
Priya Sharma
Head of Growth
Alex Rivera
Staff Engineer
Discussing:
Panel review of Have Backbone response
The candidate clearly understood the spirit of 'Have Backbone' by pushing back on an incoming request, but the story landed more as defending their team's scope than challenging a top-down decision. I noticed they framed it around protecting priorities rather than influencing upward, which feels like a missed opportunity for this principle. It still shows outcome focus over feature requests though.
From a leadership lens, the example demonstrated willingness to make an unpopular call, which is table stakes at senior levels. What stands out is the absence of any upward pushback on a strategic decision made by stakeholders or execs. That distinction matters for how we'd expect them to operate on cross-team trade-offs.
The candidate showed they can have a difficult conversation when protecting their team, which builds credibility. Still, the story didn't touch on navigating tension with someone more senior, which is often where real backbone gets tested in customer-facing or stakeholder situations. It left me wondering how they'd handle an exec request that conflicted with customer outcomes.
There's a clear signal they can say no when it protects focus and outcomes, which is valuable for growth work. The misalignment between the question and the story suggests they may not have fully internalized what 'pushing back upward' looks like in practice. I'd want to see if they can tie that backbone to measurable business impact in future examples.
The response shows they can draw a line on scope, which prevents scope creep and keeps engineering teams healthy. What was missing is any instance of pushing back on a higher-level architectural or roadmap decision that came from above. That upward influence is often where technical PMs earn real trust with eng teams.
Sarah Chen rightly called out the absence of upward pushback on a strategic decision, which aligns with what I noted about the story focusing on scope protection instead. That said, the candidate's framing around protecting priorities still demonstrates outcome focus over feature requests, though I wonder if we're assuming this distinction matters equally at every level. I'd like to hear how they might have influenced the stakeholder who made the original request.
Marcus Johnson makes a fair point on outcome focus, but I want to push back because at senior PM levels that upward influence on cross-team trade-offs is exactly what separates strong leaders from good ones. The example stayed at the team boundary without showing how they'd handle an exec-driven roadmap shift, which is the real test of backbone in org design. Without that, it's hard to gauge their scalability in complex environments.
Building on Sarah Chen's point about upward influence, I see it from the customer's side too - the story showed the candidate protecting their team but didn't demonstrate navigating tension with someone more senior when customer outcomes were at stake. That difficult conversation skill Jordan mentioned earlier feels incomplete without an exec conflict example. It leaves me questioning how proactive they'd be in stakeholder situations that directly impact adoption.
Jordan Taylor's customer lens is spot on, and it reinforces what I observed about the misalignment between the question and the story - they showed saying no to protect focus but didn't tie backbone to measurable business impact like revenue or funnel conversion. I'd want to test that assumption by asking for a follow-up example where they pushed back on a growth initiative from leadership. Without it, the signal feels limited for roles that require constant upward experimentation.
Priya Sharma's call for a business impact example is useful, yet from an engineering standpoint the real gap Alex and others flagged remains the lack of pushing back on higher-level roadmap or architectural decisions that came from above. That upward influence prevents unhealthy scope creep and builds trust with eng teams, which the current story didn't address. Without seeing it, we can't fully assess their ability to maintain maintainable systems under pressure.
Pulling together what we've discussed, the candidate's example aligns with Sarah Chen's point on making unpopular calls to protect scope, yet as Jordan Taylor noted it stops short of the upward influence on stakeholder decisions that defines this principle. We agree the outcome focus is a green flag, but the misalignment Alex Rivera flagged means we lack evidence of challenging exec-driven priorities. I'd want to probe whether this distinction scales differently at mid versus senior levels.
Building on Marcus Johnson's synthesis, the absence of upward pushback on strategic decisions that Priya Sharma highlighted is the core gap for org-level impact. We all see the strength in defending team boundaries, but without an example of influencing an exec roadmap shift, it's difficult to assess how they'd handle cross-team trade-offs at scale. That said, the outcome-oriented framing still shows solid self-awareness.
Agreeing with Sarah Chen on the upward influence gap, the story demonstrated proactive risk identification when protecting the team, which echoes what we liked about their difficult-conversation skills. However, as Priya Sharma mentioned, tying that backbone to customer outcomes or revenue impact would have strengthened it significantly. The misalignment leaves the example feeling incomplete for roles requiring stakeholder tension navigation.
Jordan Taylor's customer lens connects well with the earlier observations from Marcus Johnson and Alex Rivera about scope protection versus true upward challenge. The panel consensus is clear on the positive signal around focus and outcomes, yet the lack of a measurable business impact example or higher-level pushback keeps the response from fully landing for growth-oriented PM work. A follow-up experiment-style question could clarify this quickly.
Synthesizing across the thread, the candidate's ability to prevent unhealthy scope creep is a clear green flag that Sarah Chen and I both valued, but the repeated point about missing higher-level roadmap pushback remains the limiting factor. Without that, we can't fully gauge their influence on maintainable systems under pressure from above. Overall the response is solid on team defense but thin on the principle's upward dimension.
Panel Consensus
The panel agrees the candidate demonstrated solid outcome focus by pushing back on incoming requests to protect team scope and make unpopular decisions, which shows good self-awareness and prevents unhealthy scope creep. However, they uniformly flag the core gap as lack of upward influence: the story did not show challenging strategic decisions from executives or stakeholders, which is the key test of 'Have Backbone' at senior PM levels. Minor nuance exists on whether this distinction matters equally at mid vs. senior levels and how directly it must tie to revenue impact.
Hiring Signals from the Loop
Marcus Johnson
Director of Product
Reason to Hire
Candidate framed the example around protecting priorities and outcome focus over feature requests rather than just defending scope.
Concern
Story centered on scope protection instead of influencing upward on a top-down strategic decision, missing the principle's emphasis on challenging stakeholder requests.
Sarah Chen
VP of Engineering
Reason to Hire
Showed willingness to make an unpopular call, which is table stakes for senior leadership and demonstrates clear ownership.
Concern
No evidence of upward pushback on an exec-driven roadmap shift or cross-team trade-off, limiting assessment of scalability in complex org environments.
Jordan Taylor
Senior Client Success Manager
Reason to Hire
Demonstrated ability to have a difficult conversation when protecting the team, which builds credibility and shows proactive risk identification.
Concern
Story did not address navigating tension with someone more senior when customer outcomes were at stake, leaving stakeholder management incomplete.
Priya Sharma
Head of Growth
Reason to Hire
Clear signal they can say no when it protects focus and outcomes, which is valuable for growth work requiring disciplined prioritization.
Concern
Misalignment between question and story suggests incomplete internalization of pushing back upward, with no tie to measurable business impact like revenue or conversion.
Alex Rivera
Staff Engineer
Reason to Hire
Ability to draw a line on scope prevents unhealthy scope creep and keeps engineering teams healthy with a focus on maintainability.
Concern
Missing any instance of pushing back on a higher-level architectural or roadmap decision from above, which is where technical PMs earn real trust with eng teams.