Thuan: My PM just asked me if we can “squeeze in one more feature” before the release. We’re already overcommitted. I want to say no, but every time I try, it comes out wrong — either too aggressive or too soft and they don’t take it seriously.
Alex: Saying no to a PM is the most important communication skill a tech lead can have. Do it wrong, and you’re either a pushover or a blocker. Do it right, and you’re a trusted partner. The secret? Never say “no” — say “yes, if.”
The “Yes, If” Technique
Alex: Instead of rejecting a request, you redirect it:
| PM Asks | ”No” Response (Avoid) | “Yes, If” Response (Use) |
|---|---|---|
| “Can we add this feature?" | "No, we don’t have time" | "Yes, if we remove [X] from the sprint" |
| "Can we ship by Friday?" | "No, that’s impossible" | "Yes, if we cut [feature] from the scope" |
| "Can the team work on this too?" | "No, we’re at capacity" | "Yes, if we deprioritize [Y]. Which do you prefer?" |
| "Can we do both A and B?" | "No, we can only do one" | "We can start both, but we’ll only finish one. Which is the priority?” |
Thuan: So I’m never saying “no” — I’m saying “yes, with trade-offs.”
Alex: Exactly. PMs understand trade-offs. They don’t respond well to flat refusals because their job is to deliver scope. When you offer options, you’re helping them do their job while protecting your team.
Essential Phrases for PM Conversations
Deadline Discussions
| Situation | Phrase |
|---|---|
| Original estimate | ”Based on the current scope, our estimate is [X] weeks.” |
| PM pushes for faster | ”We could compress the timeline if we reduce scope. Which features are must-haves?” |
| Unrealistic deadline | ”To hit that date, we’d need to cut [X, Y]. Or we can deliver everything by [later date]. What’s the priority — date or scope?” |
| Discovery of hidden work | ”We found additional complexity in [X]. The original estimate didn’t account for [Y]. Revised ETA is [date].” |
| Need more people | ”To hit this deadline with full scope, we’d need [X] more developers. Without them, we need to prioritize.” |
Capacity and Workload
| Situation | Phrase |
|---|---|
| Team is overloaded | ”The team is at 100% capacity this sprint. If we add this, what should we deprioritize?” |
| Burnout risk | ”The team has been running above capacity for three sprints. We need a lighter sprint or we risk quality drops.” |
| Unplanned work | ”We lost 2 days this sprint on production support. That impacts our velocity.” |
| Leave / absence | ”With [Name] on leave, we’re at 80% capacity. I’d suggest reducing scope by 20% too.” |
Scope Negotiation
| Situation | Phrase |
|---|---|
| Feature creep | ”We’ve added 3 unplanned features since sprint start. Can we freeze the scope?” |
| MVP discussion | ”What’s the minimum we need for launch? I’d suggest [X, Y, Z] and defer [A, B].” |
| Cutting scope | ”If we cut the admin dashboard, we save 2 weeks. Users can manage via API for now.” |
| Risk flagging | ”I want to flag a risk: [X] has a 30% chance of taking twice as long. Plan B is [Y].” |
The Three Types of “No”
Alex: As a tech lead, you’ll face three different situations when saying no:
1. “Not Now” — It’s a Good Idea, Wrong Timing
“I love this idea. Let’s put it in the next sprint when we have capacity. I’ll create a ticket so we don’t lose it.”
2. “Not Like This” — The Approach Needs Changing
“I agree with the goal, but the approach has risks. What if instead of [X], we try [Y]? It achieves the same result with less risk.”
3. “Not Possible” — Technical Constraint
“This isn’t feasible with our current architecture. Here’s why: [reason]. To support this, we’d need to [change], which would take [time]. Is that investment worth it?”
Real Dialogue: The Deadline Negotiation
PM: “The client wants the notification feature by March 15. Can we make it?”
Thuan: “Let me break it down. The full notification feature — email, push, in-app — is a 3-week effort. March 15 is in 2 weeks.”
PM: “Is there any way to make it work?”
Thuan: “Yes, if we phase it. We can ship email notifications by March 15 — that covers 80% of use cases. Push and in-app follow in the next sprint, by March 29.”
PM: “Would the client accept that?”
Thuan: “I think so. We can position it as: ‘Phase 1 delivers email notifications on March 15, with push and in-app notifications in Phase 2 by month-end.’ It shows progress and doesn’t over-promise.”
PM: “Good approach. Let’s propose that.”
Thuan: I gave options instead of a flat “no,” and I even helped frame it for the client.
Alex: That’s tech lead thinking. You’re not just protecting your team — you’re helping the PM succeed too.
When the PM Won’t Take No for an Answer
Thuan: What if the PM keeps pushing after I’ve explained the trade-offs?
Alex: Escalation phrases:
Firm Pushback
- “I understand the pressure. But if we rush this, the quality will suffer — and fixing bugs post-launch will cost more time than building it right.”
- “I need to be transparent: the team can’t deliver this scope by this date at the quality level we need. Something has to give.”
- “I want to find a solution, but committing to something we can’t deliver isn’t fair to the team or the client.”
Escalation (When Needed)
- “I think we need to involve [engineering manager / CTO] in this decision. The trade-offs have significant impact.”
- “Let me document the options and risks, and we can review them together with [leadership].”
The Nuclear Option (Documenting Risk)
If a PM insists on an impossible timeline despite your pushback:
“I want to go on record: the team can deliver [scope] by [date], OR we can deliver [full scope] by [later date]. If we compress both, the risk is [bugs / outage / rework]. I’m documenting this so we can refer back if needed.”
Thuan: “Go on record” — is that too confrontational?
Alex: It’s professional. You’re not threatening — you’re documenting. In English business culture, this is normal and expected for senior technical people. It protects everyone.
The Status Update: Proactive Communication
Alex: The best way to avoid deadline fights? Keep the PM informed so there are no surprises.
Weekly Status Update Template
Subject: Sprint 14 Status — [On Track / At Risk / Delayed]
Hi [PM Name],
**Sprint Progress:** 6 of 10 stories complete (60%)
**Velocity:** On pace for 28 points (target: 30)
**On Track:**
- ✅ User authentication (done)
- ✅ Payment integration (done)
- 🔄 Notification service (in progress, on track)
**At Risk:**
- ⚠️ Search feature — found performance issue at scale.
Investigating. May need 1 extra day.
**Blockers:**
- Waiting on API credentials from [third party]
**Next Week:**
- Complete notification service
- Start admin dashboard
- QA round for completed features
Let me know if you'd like to discuss any of these.
ThuanThuan: If I send this every week, the PM is never surprised.
Alex: Exactly. Proactive communication eliminates 80% of deadline fights. Problems are always cheaper to solve when they’re small and early.
10-Minute Self-Practice
The “Yes, If” Reframe (5 min)
- Think of a recent request you wanted to say “no” to
- Rewrite your response using “Yes, if [trade-off]”
- Write the trade-off options: “We can do A if we cut B”
- Say it aloud naturally
The Status Report Practice (5 min)
- Write a 1-minute status update for your current sprint
- Use the template above
- Include one “at risk” item with a specific impact and action
What’s Next
You can now negotiate with PMs like a partner, not a pushover. Next post: Code Review Communication — the art of giving and receiving feedback in writing without sounding like a jerk.
This is Part 9 of the English Upgrade series. See also English Upgrade #3: Sprint Planning — where many deadline commitments are first made (and should be challenged).
Related: Tech Coffee Break #12: Career Growth — why managing up is a critical tech lead skill.