If you work with software engineers long enough, you start noticing something strange.
PMs have a special talent.
They can take a sentence that sounds completely harmless and make an engineer's entire afternoon disappear.
To be fair, most PMs aren't actually trying to lie to engineers.
Sometimes they genuinely don't know how some things are complicated.
But after hearing the same sentences over and over again, you start developing a little internal translator.
So, for fun, here are 7 lies PMs tell engineers, according to engineers who have definitely never complained about PMs in Slack.
Obviously 😄
1. “It’s just a tiny update. It should take 15 minutes.”
This one deserves to be number one.
A PM comes to you with a request from the client.
“They just want one small change on the dashboard. It shouldn't take more than 15 minutes.”
You look at the ticket. The requested change is one sentence.
You look at the code. The requested change is no longer one sentence.
Maybe that “small” UI change depends on data coming from an API. Maybe the API doesn't return the information you need. Maybe the backend gets its data from another service. Maybe that service has a completely different structure. Maybe changing the backend response will affect three other components.
And then there is testing.
And then there is the possibility that nobody knows why the existing code was written that way because the person who wrote it left the company two years ago.
So, the 15-minute task has become a full day.
And when you finally explain this, you get:
“But the client said it's very simple.”
Of course they did.
The client doesn't have to open the repository. He just sees a button.
You see the 14 things that happen after someone clicks the button.
That's one of the biggest differences between how clients see software changes and how engineers see them.
This is why I think PMs should be allowed to say:
“I don't know how long this will take. Let me ask the engineer.”
2. “We can add it quickly. It’s basically the same feature.”
This one usually arrives right after the previous one.
You already have Feature A.
The client now wants Feature B.
The PM looks at Feature A and says:
“We already have something similar, so we can probably reuse most of it.”
Sometimes that's true.
But sometimes “similar” means the two features have the same color and absolutely nothing else in common.
The problem is that software features can look identical from the outside while being completely different underneath.
A user might see two forms.
An engineer might see two completely different validation rules, API endpoints, permissions, database relationships, error states, and edge cases.
And then we just hear:
“Can't we just copy the existing one?”
Copying something can take five minutes. Making sure the copied version behaves correctly everywhere can take much longer.
This is also where engineers sometimes get blamed for “overcomplicating” something.
But we're not trying to turn a simple button into a distributed system.
We're trying to avoid discovering next week that the button we copied quietly broke something else.
Sometimes the feature really is easy.
Sometimes it only looks easy because the difficult parts are hidden behind the screen.
And engineers have a slightly unfortunate habit of knowing where those hidden parts are.
3. “The client definitely won’t change their mind.”
This sentence should probably come with a warning label.
“Don't worry, this is the final requirement.”
There is no such thing as a final requirement.
Okay, that's unfair.
There probably is.
I've just never personally met one.
You finish the implementation. You test it. You deploy it. You finally feel that moment of peace.
Then the message arrives:
“Small feedback from the client…”
The “small feedback” turns out to be:
- Move this section.
- Add another filter.
- Change how the data is calculated.
- Make it work on mobile.
- Add an export button.
- Also, can we make it available to admins only?
- And the client wants the old behavior back.
At this point, the engineer is staring at the screen wondering whether “final requirement” was ever a real concept or just something PMs say to help everyone sleep at night.
Of course, requirements can change. That's normal in software development.
The frustrating part is pretending they won't.
I'd rather hear:
“This is what the client wants right now, but there may be changes after they see it.”
Perfect.
Now I know what I'm dealing with.
No false promises. No magical 15-minute estimates. No emotional damage when the “final” version becomes version 2.7.
And honestly, that's probably the biggest thing engineers want from PMs:
Just tell us what you know, what you don't know, and what might change.
We can work with that.
4. “We don't need to worry about edge cases yet.”
This sentence sounds reasonable until the edge case becomes the thing the customer is experiencing.
You build the feature for the normal situation.
A user enters a valid email. The API returns the expected data. The user has the correct permissions. The database contains exactly what everyone expected it to contain.
Great.
Then someone enters an empty value. Or a name with 200 characters. Or clicks the button twice. Or loses their internet connection at exactly the wrong moment. Or somehow manages to have an account created in 2018 with a data structure that nobody has seen since the dinosaurs walked the Earth.
And 😢
“We should probably handle that.”
Yes.
We probably should.
This is one of those conversations where PMs and engineers can have very different ideas about what “done” means.
I'm not saying every tiny feature needs six days of testing and a 40-page technical specification.
There has to be some balance.
But “we'll deal with edge cases later” has a funny habit of turning into “why did production just explode?”
And the answer is...
Because later arrived.
5. “We don't need a ticket for this. I'll remember it.”
No. You won't. I won't. Nobody will.
We're developers. We already have 37 tabs open because we were afraid we'd forget something.
Please make the ticket.
The request might sound tiny:
“Can you also change the error message?”
Sure.
Then someone mentions it during a meeting.
And it gets mentioned again in Slack.
And someone says they'll add it to the ticket.
But days later, everyone remembers that there was something about an error message, but nobody remembers exactly what it was supposed to say.
And somehow I'm looking at a Slack conversation from Tuesday trying to reconstruct a requirement from four messages and a thumbs-up emoji.
A ticket doesn't need to be a novel.
Even something like:
“Change the login error message from X to Y.”
is enough.
It gives everyone one place to check.
It also protects engineers from the classic:
“But we talked about this!”
Tickets aren't just for project managers.
They're useful for engineers because they give us a written record of what we're actually supposed to build.
And if the requirement changes later, great.
Update the ticket.
Now we have history, and future engineers will thank us.
6. “It's urgent.”
The word urgent is possibly the most overused word in software development.
Everything is urgent.
At some point, if everything is urgent, nothing is.
The problem isn't that PMs have urgent requests. Of course they do. Production issues happen. Customers have deadlines. Business priorities change.
The problem is when every request arrives with the same level of emergency.
Because engineers don't work in a magical universe where we can put our current task on pause without consequences.
If I'm halfway through a feature and you give me an urgent request, something has to move.
Maybe the original feature moves.
Maybe the urgent request moves.
Maybe the deadline moves.
There is always a cost somewhere.
And this is where a simple question can save us confusion:
“Okay, what should I pause to work on this?”
If the answer is:
“Pause the dashboard and fix this first.”
Cool. Now I know what matters.
But if the answer is:
“Don't pause anything. Just do this too.”
Then we have discovered that the request isn't actually a priority.
It's a request for additional hours disguised as a priority.
And engineers have already received enough magical powers in our job description.
Please don't add time manipulation to the list.
7. “This will be the last change.”
“Just one last change.”
Every engineer knows this sentence.
You make the requested change. You send it for review.
Then:
“Looks great! Just one tiny thing…”
You fix the tiny thing.
Then:
“Actually, the client had one more idea.”
You fix that too.
Then:
“Can we also…”
At this point, you stop reading the message and start preparing yourself emotionally.
The funny thing is that I don't even think PMs say this because they're trying to annoy engineers.
Sometimes the client really does send one more change.
Sometimes the PM genuinely thinks it's the final one.
And sometimes the client has apparently discovered a new feature while looking at the old feature for the first time.
That's normal.
People understand software differently once they can see and use it.
I'm not against changes. I'm against pretending that changes don't have a cost.
If we're adding another requirement, that's fine. Just tell me.
If it adds another day, tell me.
If it changes the original scope, tell me.
I'll probably complain for approximately 45 seconds and then start coding.
So, do PMs actually lie to engineers?
Probably not as much as this article makes it sound.
Most of these “lies” aren't really lies.
They're usually a combination of optimistic estimates, incomplete information, client pressure, changing requirements, and two people looking at the same feature from completely different angles.
And that's probably where a lot of the tension between product managers and software engineers comes from.
PMs are often thinking about customers, deadlines, business requirements, priorities, and expectations.
Engineers are thinking about architecture, dependencies, bugs, testing, technical debt, edge cases, and whether touching one innocent-looking function will somehow wake up three other systems.
Neither side gets the complete picture alone.
That's why I think the best PM-engineer relationship isn't built on pretending everything is easy.
It's built on being able to say:
“I don't know.”
“I don't know how long this will take.”
“I don't know whether the client will change it.”
“I don't know if this affects another feature.”
“I need to ask the engineer.”
Those sentences are completely fine.
Actually, they're useful.
Because the fastest way to make an engineer nervous isn't telling them that something is complicated.
It's telling them:
“Don't worry. It's super easy.” 😂
Your turn
What is the funniest or most suspicious sentence a PM has ever told you?
💬 Drop it in the comments.
And PMs, you're absolutely welcome to defend yourselves 😂
| Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah |
  
|
|---|
Top comments (2)
This is hilarious 😂 Really, almost all PMs tell these lies. But the one that makes me disappointed is "We can add it quickly. It’s basically the same feature."
Most of the time PMs don't know what's hidden behind the scenes, and even when you try to explain that it's not as easy as it looks, they don't even try to understand; they just don't care 😢
All that's written here is true 😂