Mature vs Immature Product Managers When Joining a Company
Mature vs Immature Product Managers when joining a company.
Recently, while traveling in a cab, the driver started talking on the phone using one hand and steering with the other. He had to switch hands when he needed to change gears.
My wife panicked and wanted to shout at him.
As I had been observing the driver from the start, I told her not to say anything. It seemed he had done this wrong thing for so long that he was doing it without any impact on his driving. We ultimately reached our destination safely and smoothly.
The drive was fine. The behavior looked risky from the outside but was harmless in practice.
And that's exactly how immature PMs get it wrong when they join a new company.
TL;DR: Immature PMs join a company and start commenting from Day 1 about everything they think is wrong. Mature PMs observe, ask questions, and stay silent until they have enough context to offer informed opinions. You establish yourself as a reliable PM by speaking facts and data, not by making shallow comments about things you don't yet understand.
What immature PMs do on Day 1
They join a company and immediately start commenting:
- "This UX is not smooth"
- "That UI looks old school"
- "We are so behind our competitors. They have cooler features"
- "Why do we deploy on Fridays? That's risky"
- "Why is the onboarding flow so long?"
- "Have you tried doing X instead?"
Each comment feels smart in the moment. You're showing initiative. You're demonstrating that you have high standards. You're "adding value" from day one.
But here's what the team hears: someone who doesn't understand our context is judging our work. Someone who's been here for 72 hours thinks they know better than people who've been building this for years.
That's the cab driver analogy. From the outside, things look wrong. But you haven't observed long enough to know whether it actually matters.
What mature PMs do instead
Mature product managers will never open their mouths unless they have clarity on everything that's going on.
They will try to understand the reasons behind the current state of UI/UX. Maybe there's a technical constraint. Maybe there's a customer segment that prefers it. Maybe it's on the roadmap but other things ranked higher. Maybe the team tried your "obvious" fix and it didn't work.
They will analyze the stage of their product, adoption trends, and their competitors to see if the gap actually matters. Maybe the competitor's "cooler features" don't drive any meaningful adoption. Maybe your product wins on reliability, not flashiness.
They are fine with Friday deployments as long as there's confidence and low risk, or there's no negative past record. Just because "the internet says don't deploy on Fridays" doesn't mean it's wrong for every team. If they've been doing it successfully for two years, who are you to complain?
It's similar to the cab driver talking on the phone while driving. It seems wrong from the outside. But the ride is smooth. So why do you want to complain?
The listening and observing phase
To be a mature product manager when joining a company:
Be in "listening and observing" mode constantly
Not for a day. Not for a week. For weeks or months, based on the size of the company.
A startup might take 4-6 weeks to understand fully. A large enterprise could take 3-6 months. During this time:
- Read every doc you can find
- Sit in on meetings as an observer
- Talk to people across functions
- Understand the history behind decisions
- Map out who owns what and why
Be highly curious and ask a lot of questions without hesitation
Questions are different from comments. Questions show humility and desire to learn. Comments show judgment.
-
Question (good): "I noticed we deploy on Fridays. What's been the team's experience with that?"
-
Comment (bad): "We shouldn't be deploying on Fridays."
-
Question (good): "The onboarding flow has 8 steps. What drove that design?"
-
Comment (bad): "This onboarding is too long."
Don't have the urge to talk or say something in meetings
This is the hardest one for high-achieving PMs. You got hired because you're smart. You want to prove it. You feel like silence means you're not contributing.
Silence in your first weeks IS contribution. You're absorbing context that will make your future contributions 10x more valuable.
Never comment. Share suggestions only when you have data or observed things over time.
This is critical. This is the entire point.
You can establish yourself as a reliable PM only by speaking facts or offering informed opinions, not through shallow comments or idealistic suggestions.
| Shallow comment (Week 1) | Informed opinion (Week 8) |
|---|---|
| "This UI looks dated" | "I noticed our enterprise accounts are requesting a dark mode based on 12 support tickets I reviewed. The UI refresh could be scoped to address that segment" |
| "Competitors have X feature" | "After talking to 5 customers, none of them mentioned wanting X. They care more about Y, which we already do well" |
| "We should do A/B testing" | "Based on our traffic patterns, we have enough volume on the pricing page to run a meaningful test. Here's what I'd propose" |
See the difference? One is opinion. The other is evidence. One makes you look impulsive. The other makes you look competent.
Why this matters for your reputation
Your first impression at a new company follows you for months. If you're the PM who commented on everything in Week 1, people remember. Even after you develop context and start making good suggestions, there's a voice in people's heads: "Oh, this is the person who complained about everything before understanding anything."
That reputation tax is expensive. It takes months of consistently good work to overcome a few days of premature commentary.
Conversely: if you're the PM who listened for 6 weeks and then made one suggestion that was backed by data and context? People remember that too. "When they speak, it's always worth listening to." That reputation compounds.
The exception: genuine problems
Sometimes you join and see something genuinely dangerous. A security vulnerability. A broken user flow losing revenue. A compliance issue.
In those cases, yes, speak up immediately. But frame it as a question, not a judgment:
"I noticed X. Is this a known issue being tracked, or should I flag it?"
This gives the team a chance to say "yes, we know, it's on the roadmap" without feeling attacked. And if it IS new information, you've flagged it helpfully without being the person who "criticized the whole product on Day 3."
The bottom line
The cab driver's phone call looked wrong. The ride was smooth. You didn't have enough context to judge.
Most things in a new company look wrong in your first weeks. You don't have enough context to judge. And the people who built those "wrong" things are the same people you need to earn trust from.
Listen. Observe. Ask questions. Build context. And when you finally speak, speak with data, observation, and informed perspective.
That's how mature PMs operate. And that's how you earn a reputation that compounds over years.
How ProductResume helps
If you're joining a new company soon, your resume is what got you there. Make sure it signals PM maturity, not just PM activity. Score your PM resume to see whether your experience communicates thoughtful, evidence-based leadership, the kind that builds trust rather than creating friction.