You've spent two weeks on the spec. The user research is solid. The priority rationale is defensible. You send the PRD to the engineering lead on a Thursday—and by Friday morning, your Slack has this:
"Hey — I read through the spec. There are some issues. This isn't going to be possible in the timeframe."
That's it. No specifics. Just: not possible.
Your stomach does the PM thing it does. You start running through every possible interpretation simultaneously. Does "not possible" mean technically impossible? Does it mean possible but insanely expensive? Does it mean possible but they already have three sprints of committed work? Does it mean they think your requirements are wrong? Does it mean something went sideways in the last all-hands that you didn't see?
This is the engineering pushback problem — and it's not a technical problem. It's a communication problem. Because "it can't be done" is almost never a complete statement. It's the opening line of a conversation that most PMs don't know how to continue.
The Four Types of Engineering Pushback
The critical insight is that engineering pushback comes in four fundamentally different flavors, each requiring a different response. Treating them the same way is the source of most PM-engineering friction.
Type 1: The Technical Impossibility
What it means: The requirement genuinely cannot be built the way it was specified — either because of architectural constraints, infrastructure limitations, or fundamental technical reasons.
How to identify it: The engineering lead can explain why in specific terms. "We can't do real-time sync because the data model doesn't support it — the events table isn't designed for that query pattern" is a Type 1.
The PM mistake: Fighting it. If a constraint is genuinely architectural, it's not a negotiation — it's a reality. The question is whether the underlying user need can be met a different way.
The right response: "Help me understand the constraint. What's the user experience we can actually support given this architecture? What would need to change to make the full requirement possible — and what would that cost?"
Type 2: The Cost-Complexity Pushback
What it means: It's possible, but the engineering estimate is much larger than expected — often because the spec touched a part of the codebase that's fragile, undocumented, or technically indebted.
How to identify it: The conversation starts moving toward estimates that feel disproportionate. "That pagination feature would take four weeks" means something technical is lurking under the surface.
The PM mistake: Accepting the estimate at face value without understanding it, or dismissing it as inflated without understanding it. Both create problems.
The right response: "Walk me through what's driving that estimate. Is it the feature itself or something in the underlying codebase?" Usually this surfaces either tech debt that should be addressed explicitly, or an opportunity to descope to a version that's 80% of the value at 20% of the cost.
Type 3: The Motivation Pushback
What it means: The feature is technically straightforward, but the engineering team doesn't believe in it. They've seen features like this added and then removed. They think it's the wrong solution. They're skeptical the use case is real.
How to identify it: The pushback is vague, shifting, and doesn't anchor on specific technical reasons. The conversation feels like a debate about product strategy, not engineering feasibility.
The PM mistake: Treating this like a technical conversation. Bringing more data about technical feasibility when the concern is about product judgment.
The right response: Have the actual conversation — about the product decision, not the technical constraint. "It sounds like you have concerns about whether this is the right thing to build. I'd like to understand that. Tell me what you think we're missing." Engineers are often the best product critics in the organization. Their skepticism is frequently well-founded.
Type 4: The Proxy Pushback
What it means: The engineering team is raising a concern about something else — team capacity, burnout, a previous broken promise, lack of trust in the requirement changing midway — and the pushback on this feature is the proxy expression of that underlying issue.
How to identify it: The pushback feels emotionally weighted. The team has been delivering on previous commitments without issue, and this resistance came out of nowhere. Or you recently had a feature change significantly post-scoping.
The PM mistake: Debating the feature when the real conversation needs to be about the relationship or the process.
The right response: Get the actual conversation on the table. "I want to check — are there concerns about this feature specifically, or is there something broader going on that we should talk about first?" Most engineering leads will be relieved someone asked this directly.
The Pushback Diagnostic Conversation
When a PM receives pushback, the first instinct is to respond — to defend the spec, explain the reasoning, escalate to the timeline requirements. Before any of that, there's one move that almost always helps: the diagnostic conversation.
The goal of the diagnostic is to identify which type of pushback you're dealing with before you respond. It takes 20 minutes and saves days of misaligned friction.
The conversation structure:
PM: "I got your message on the spec. Before we get into solutions, can I ask you a few questions to make sure I understand the concern?"
[Engineering lead agrees]
PM: "When you say it's not possible in the timeframe — is the challenge the feature itself, or is it something about what we've committed to in the current sprint?"
[This distinguishes Type 2 from capacity constraints]
PM: "If we had unlimited time, is this technically achievable the way it's specified? Or would we need to approach it differently?"
[This identifies Type 1]
PM: "I'm also curious — beyond the timeline question, do you have concerns about the feature itself? The direction, whether it's the right thing to build?"
[This surfaces Type 3]
PM: "And is there anything else going on that I should understand — process, team workload, anything from previous sprints?"
[This opens the door to Type 4]
This conversation will feel slow to a PM who is under timeline pressure. It will save you a week of back-and-forth in almost every case.
The PM-Engineering Trust Equation
Engineering pushback doesn't happen in a vacuum. The frequency and type of pushback you receive from an engineering team is a function of the trust relationship — and trust is built through specific PM behaviors.
What builds trust with engineering:
Writing tight specs. Ambiguous requirements create engineering uncertainty — and engineering teams express uncertainty through pushback. Every requirement that says "the user should be able to filter" without specifying filter logic, edge cases, or empty states is a future pushback in waiting. Clear specs reduce friction.
Fighting for tech debt time. The PM who advocates to include a 20% sprint allocation for tech debt — and then actually protects it — earns profound loyalty. Engineers who feel like their technical health is respected are dramatically more willing to stretch on delivery timelines when business needs require it.
Showing up to engineering meetings without an agenda. Sit in on technical design reviews. Ask questions. Express genuine curiosity about technical decisions. You don't need to understand everything — you need to demonstrate that you care about their craft, not just their output.
Acknowledging when requirements change. Requirements will change. The PM who changes requirements without acknowledging the cost creates resentment. The PM who says "I know this changes the scope we scoped together, and I want to be explicit about that — what does this do to the sprint?" builds a reputation for intellectual honesty.
Crediting engineering wins publicly. In leadership meetings, attribute technical decisions to the engineers who made them. "The engineering team made a brilliant architectural call that reduced our infrastructure costs by 30%" is not a thing that happens enough. When engineers know their technical excellence will be visible, they invest more in it.
What destroys trust with engineering:
| PM Behavior | Engineering Experience |
|---|---|
| Changing requirements mid-sprint without acknowledgment | "PMs don't respect our work" |
| Agreeing to timelines without consulting engineering | "Our capacity doesn't matter to them" |
| Escalating pushback to leadership before having a direct conversation | "We can't trust the PM with honest feedback" |
| Treating estimates as opening bids to negotiate down | "If we give an honest estimate, they'll just push back anyway" |
| Not attending sprint reviews or demos | "They don't care about what we actually build" |
The Scope Negotiation
When you've identified the type of pushback and understand the constraint, the next conversation is usually about scope. The goal is to find a version of the requirement that serves the user need at the engineering cost the team can actually commit to.
The framing that works:
"Given [the constraint you've described], what would it take to give the user 80% of the value? I'm not looking to cut the feature — I want to understand what a first version looks like that we can actually ship, and what we'd add in a Phase 2."
This framing does several things:
- It signals flexibility without giving up on the requirement
- It invites engineering into the product design process (which most engineers actually enjoy)
- It creates a shared ownership of the solution — "we figured out to ship Phase 1 on time" is a better story than "engineering pushed back and PM escalated"
The Phase 1 / Phase 2 structure is genuinely underused. Most features are overspecified on the first pass. A focused first version ships faster, generates real user data, and usually informs a better Phase 2 than extended upfront design would have.
When to Escalate
There are cases where pushback genuinely requires escalation — where the engineering constraint is organizationally significant, or where a direct conversation reveals a team health issue that needs leadership attention.
The rule: escalate with a recommendation, never with a complaint.
"Engineering says they can't do it and I need you to make them" is not an escalation. It's a failure to do your job. It also destroys your relationship with engineering permanently.
"I've had a conversation with the engineering lead and we've identified a structural issue: our tech debt burden has gotten to a point where significant new features require architectural investment first. I have a recommendation for how to address this, but I want your input on the business trade-off." — that is an escalation.
For the PM-engineering relationship, also see our guide on building trust with engineering teams.
The Prodinja Angle
The most expensive engineering pushback is the kind that happens after a spec is written — because it means rework, resetting expectations, and lost sprint time. Prodinja's Spec Precision Scorer analyzes your PRD before it reaches engineering, flagging the ambiguities, missing edge cases, and requirement conflicts that drive the most common pushback patterns. It doesn't replace the PM-engineering conversation — it makes that conversation shorter and more productive by removing the low-signal friction before it starts.
Key Takeaways
- Engineering pushback comes in four types: technical impossibility, cost-complexity, motivation, and proxy. Identify the type before you respond.
- The diagnostic conversation saves more time than it costs. Twenty minutes of understanding beats two weeks of misaligned back-and-forth.
- Trust with engineering is built through specific behaviors: tight specs, fighting for tech debt time, public credit, and intellectual honesty about requirements changes.
- The Phase 1 / Phase 2 structure is underused. A focused first version ships faster, generates real data, and creates shared ownership of the solution.
- Escalate with a recommendation, never a complaint. The PM who brings leadership a problem without a recommendation damages their credibility — and possibly their relationship with engineering permanently.