The Most Stupid Thing I Did as a New Product Manager
After my MBA, I joined a startup as a Product guy for the first time. Their first product hire as well. Everything was new. I was eager to prove myself.
And then I did the most stupid thing a new PM could do.
TL;DR: I escalated a developer for missing a self-stated estimate, cc'ing my manager with "evidence." My manager's response: "Did you sleep well?" The lesson took weeks to land: team morale matters more than any single commitment. Estimates aren't black and white. Delivery is a collective responsibility. And escalations in startups serve no purpose other than destroying trust.
What happened
I used to conduct daily standups. In one of them, a developer mentioned she'd definitely complete something that day. The task had been delayed for a few days already. She sounded confident.
Later that evening, I checked. It wasn't done. When asked about it, there was no proper response.
With a hurt ego (let's call it what it was), I decided I should escalate this to my manager. So I emailed him with the developer in cc, showing "evidence" of the estimate and current status of the deliverable. I even exaggerated the content to make my case stronger.
There was a strong response from her soon after. Defensive. Upset. Understandably.
There was no response from my manager.
"Did you sleep well yesterday?"
The next day, my manager met me in a meeting room.
He asked: "Did you sleep well yesterday?"
I said: "No."
He said: "I'm sure the developer might not have slept well either."
After that, he gave me multiple lessons about working with people, about trust, about what really matters in a startup. But I was so convinced I was right (I had evidence!) that I didn't absorb them immediately.
I convinced myself that I was justified. The estimate was clear. The commitment was stated publicly. She didn't deliver. I had proof.
What I was too proud to see
It took me some weeks to realize I had done something genuinely stupid. Because:
- There was no customer commitment. Nobody external was waiting for this. No deadline was being missed to a client. The urgency was entirely in my head.
- There was other work going on. She might have been pulled into something else. Or blocked. Or dealing with complexity I wasn't seeing.
- I did not have clarity on the complexity. I assumed "this task" was straightforward because it was described in a few words in the standup. I had no idea what the implementation actually involved.
- I did not think about the seniority of the developer. She had years more experience than me. She understood the codebase. I was a fresh MBA hire with zero engineering context.
Then why all this overreaction?
"Exactly." That was my manager's implicit point. There was no good reason. Just ego.
The lessons that took years to land
Some lessons you understand intellectually in a day but internalize over years. These took me years:
Team morale is more important than commitments
This sounds extreme. But think about it: a demoralized team delivers less over months than one missed estimate costs you in a day.
When you publicly embarrass someone over a missed deadline, you don't just damage that relationship. You send a signal to the entire team: "If you miss something, you'll be called out." That doesn't make people more accurate. It makes them defensive. They pad estimates. They avoid committing. They stop being transparent about blockers.
The team's morale is more important than commitments any day. It's more important than even customers. Because without morale, you don't have a functioning team. And without a functioning team, you can't serve customers at all.
Trust is easy to break
It can take a PM months to build rapport with the engineering team. Months of consistent behavior. Months of showing respect, providing context, being fair.
One escalation email can destroy it in an hour.
Not just with that developer. With everyone who heard about it. In startups, everyone hears about everything. The moment I sent that email, my reputation with the entire engineering team shifted. I became "that PM who escalates." And that label takes a very long time to shed.
There is no place for ego
If you're here to make an impact, ego is your enemy. Ego made me send that email. Ego made me think "I was right" mattered more than "the team is functional."
Being right about a fact (she said she'd finish, she didn't) doesn't make the action right (escalating to management with cc). You can be factually correct and still do the wrong thing.
The question isn't "was she wrong to miss the estimate?" The question is "what action would have led to the best outcome for the team and the product?" And the answer was never "public escalation."
Estimates are not black and white
Estimates are not promises. They're not contracts. They're not commitments you can hold against people in court.
Estimates are educated guesses made with imperfect information at a point in time. They change when complexity surfaces. They change when priorities shift. They change when blockers appear.
Treating estimates as commitments and then punishing people for missing them is a recipe for dysfunction. Engineers will start over-estimating to be safe. They'll stop giving estimates at all. Or they'll rush to meet the "commitment" at the cost of quality.
Delivery is a collective responsibility
This is the one that took longest to land. I thought delivery was the engineer's responsibility. They said they'd do it. They didn't. That's on them.
Wrong.
Delivery is a collective responsibility. The PM is responsible for providing clear requirements, removing blockers, managing scope, and creating conditions where the team can succeed. If someone misses an estimate, the first question should be "what got in the way and how can I help?" not "why didn't you deliver what you promised?"
Escalations don't serve any purpose in startups
In a large corporation with layers of management, escalations might serve a structural purpose (routing decisions upward when they're blocked).
In startups, escalations serve exactly one purpose: destroying relationships. Your manager doesn't want to arbitrate developer conflicts. The developer doesn't want to be cc'd on accusatory emails. And you don't gain anything except a reputation for being difficult to work with.
Just get work done. If something is blocked, understand why. Help unblock it. If someone is struggling, offer support. If there's a pattern of missed deliveries, have a direct, private conversation.
No email. No cc. No "evidence." Just human communication.
What I'd do differently today
If the same situation happened now, a decade later:
- I'd ask privately: "Hey, I noticed the task didn't get done today. Everything okay? Anything blocking you?"
- I'd listen to the answer without assuming bad intent.
- If there was a pattern, I'd have a 1:1 conversation about it. Privately.
- I'd never, ever put someone on the spot in writing with their manager cc'd.
The irony: this approach would have gotten the work done faster. Because trust and psychological safety are what make teams productive. Not surveillance. Not pressure. Not escalations.
The bottom line
If you're a new PM reading this, especially if you just came from a management program where you learned about "accountability" and "driving results": slow down.
Your job is not to catch people failing. Your job is to create conditions where the team succeeds. Those are very different things.
And if you ever feel the urge to escalate an engineer over a missed estimate, ask yourself: "Did anyone sleep well after the last time someone did this?"
The answer is always no.
How ProductResume helps
The lessons here, building team trust, leading without authority, prioritizing morale over micromanagement, are exactly what hiring managers evaluate under Leadership & Impact. If your resume shows collaboration and trust-building (not just "drove execution"), it signals maturity. Score your PM resume to see how your leadership experience reads.