The “lies” in 7 Lies PMs Tell Engineers are usually not deliberate: they are familiar promises and assumptions that can hide uncertainty, changing requirements, or a priority tradeoff. The examples below come from software engineer and technical writer Hadil Ben Abdallah’s humorous, anecdotal article; they are not a measured list of behavior across product teams. The useful response is to make assumptions visible and agree on the next step.
Why these statements cause friction
A product manager (PM) is often balancing customer needs, deadlines, and competing priorities. An engineer is responsible for understanding how a requested change interacts with code, services, data, and testing. Each role sees part of the work, so a confident-sounding request can unintentionally imply more certainty than the team has.
Ben Abdallah frames the seven statements as “lies,” but says most are not meant to deceive. Treat them as prompts for clarification, not proof of bad faith.
1. “It’s just a tiny update. It should take 15 minutes.”
A short description does not reveal the work underneath it. A seemingly small change may depend on an API or another service, require testing, or lead into unfamiliar legacy code. Until an engineer has understood those dependencies, a precise estimate is not established.
#1 Best Overall
Better response: “I don’t know yet; I need to check the implementation and dependencies before estimating.” Then agree on when the engineer can investigate and return with an estimate or questions.
2. “We can add it quickly. It’s basically the same feature.”
Two features can look alike to a user but differ in validation rules, endpoints, permissions, data relationships, error handling, or edge cases. Existing work may provide a starting point, but similarity alone does not show that the new behavior is a quick reuse.
Better response: Compare what the feature must do, including who can use it, what data it changes, and how it should behave when something goes wrong. Estimate after those differences are understood.
3. “The client definitely won’t change their mind.”
People may revise a request after they see and use an implementation. That does not make the original requirement dishonest; it means the team’s understanding may change when the idea becomes tangible.
Better response: State that the current plan reflects what is known now, and make it easy to discuss revisions when the client sees the result. Avoid treating an untested assumption about future feedback as a guarantee.
4. “We don’t need to worry about edge cases yet.”
Some unusual conditions can cause ordinary-looking features to fail: an empty or unusually long input, repeated clicks, a lost network connection, or legacy data in an unexpected shape. Which cases matter depends on the feature; accounting for relevant failures does not require imposing heavyweight process on every small change.
Rank #3
- book
- A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Seventh Edition and The Standard for Project Management (ENGLISH)
Better response: Agree on a realistic definition of done. Identify the edge cases that could affect this feature’s users or data, and test those without turning every hypothetical into a blocker.
5. “We don’t need a ticket for this. I’ll remember it.”
When a request lives only in someone’s memory, teammates can lose track of what was asked or which details changed. A shared written record gives the team a place to check the current understanding.
Recommended Free Tools
Better response: Record the request in the team’s agreed tracking system, even if it is small, and update the record when the requirement changes. The point is a shared reference, not paperwork for its own sake.
Rank #4
- Harvard Business Review Project Management Handbook: How to Launch, Lead, and Sponsor Successful Projects
- Harvard Business Review Press
- BLANK BOOK
6. “It’s urgent.”
Urgency affects the work already in progress: if the team moves to a new priority, something else may wait. Without an explicit tradeoff, “urgent” can sound as if the new task has no cost to the plan.
Better response: Ask, “Okay, what should I pause to work on this?” That question turns urgency into a concrete prioritization decision.
7. “This will be the last change.”
Feedback can continue after a client sees a feature, so a promise that no more changes will follow is difficult to rely on. New requests may affect scope, timing, and cost; treating them as free additions obscures those effects.
Best Value
Better response: Describe each requested addition plainly and discuss its impact on the agreed scope, schedule, and cost before committing to it.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Make uncertainty and tradeoffs discussable
The practical lesson is not that PMs and engineers should distrust one another. It is that neither role has the whole picture by itself. Estimates need technical discovery, requests need a shared record, and priority changes need an explicit decision about displaced work. Saying “I don’t know yet” is often the start of a more reliable plan.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
