The Five Mistakes Every First-Time PM Makes
1 August 2026 2 min read
Every one of these is survivable, and most experienced PMs made all five before anyone told them not to. Better to read them here than learn them the expensive way.
1. Saying yes to a deadline before checking with the team
A stakeholder asks “can this be done by the 15th?” and the instinct is to say yes on the spot, because saying “let me check” feels like it makes you look uncertain. It’s the opposite — a PM who commits the team to a date without asking them first is the one who looks unreliable three weeks later when it slips. “Let me confirm with the team and get back to you today” is a stronger answer than a yes you can’t actually stand behind.
2. Treating the plan as fixed once it’s written
A project plan is a snapshot of your best guess at the start, not a contract with reality. New PMs sometimes treat any deviation from the original plan as a personal failure and try to hide it, when the actual job is to notice the deviation early, understand why, and communicate it — see our PM glossary entry on baselines for how experienced PMs think about this.
3. Avoiding the stakeholder who’s hard to deal with
Every project has one stakeholder who’s slower to respond, more critical, or just more difficult than the others. The instinct is to route around them and hope it doesn’t matter. It usually does — the person you’re avoiding is often the one whose sign-off you need eventually, and the relationship only gets harder the longer it’s neglected.
4. Confusing being busy with making progress
Answering emails all day, attending every meeting you’re invited to, and updating the tracker constantly can fill a full day without the project actually moving forward. The useful question isn’t “was I busy today” but “did anything I did today remove a blocker or move a deliverable closer to done.”
5. Not writing anything down
Early on, a lot feels too small to document — a quick decision made in a hallway conversation, an informal agreement about scope. Three weeks later, when someone disagrees about what was decided, there’s nothing to point to. You don’t need heavy documentation for everything, but decisions with any real consequence deserve a one-line record of what was agreed and by whom — even just a dated note in a shared doc.
None of these make you bad at the job. They make you new at it. The only real mistake is making the same one twice.