The early days: Proving my worth (and guessing half the time)
When I landed my first PM role, I thought I had to prove myself. To everyone. All the time. I needed to show I belonged in the room — especially when that room was full of people twice my age, in a country I was still trying to decode, in a workplace culture no one gives you a manual for.
So I did what seemed obvious: I went deep. I claimed a product area. I owned it. I became the person for one very specific slice of the pie.
It worked. Kind of.
People respected me for being the expert on that one thing. But I was also… blind to almost everything else unless it directly touched my little kingdom.
I didn’t know what other teams were building. I didn’t know what learnings I was missing. I wasn’t learning from customer research others had already done. Worst of all? I wasn’t talking about my work. No feedback, no visibility — just vibes. I know it sounds stupid, I even felt stupid writing this! But let’s proceed.
The collaboration breakthrough: Growth isn’t a solo quest
Did a wise manager help me shift my mindset? Nope.
It was my peers — design, engineering, data science, customer success — who had my back. They talked about my work in rooms I wasn’t in. They gave me confidence. They dragged me (kindly) out of my silo.
Here’s the funny part: I’m not even an introvert. But being new, in a new country, in a high-ambiguity job with zero instructions? I folded into myself. I didn’t know if I had what it took. And I definitely didn’t know if I was “doing it right.”
Spoiler alert: there is no “right.” But there is better.
From Checking Boxes to Thinking Bigger
Curiosity has always been my thing. I love digging into industries, trends, user behavior, strategy. But early on? My curiosity was tactical. Safe. Boxed in by Jira tickets and a sprint board.
I didn’t ask how I could grow. I didn’t ask my manager what they needed from me. I assumed if I delivered shiny features, I was doing my job.
Spoiler (again): I was doing a job. Just not the one that moves the needle.
Now, I focus on zooming out — on understanding the org, the team, the business model. I ask better questions. I’ve learned that “What do you really need from me in this role?” is 100x more powerful than “Is my ticket ready for grooming?”
Learning to love the fuzziness
In the beginning, I hated change. Process changes? Vague goals? Strategic pivots? I treated them like personal attacks.
I liked clarity. I liked control. And PM is… not that.
Eventually, I realized:Â fuzziness is a feature, not a bug.
When things are unclear, you get to define them. When there’s chaos, you get to shape it. That’s the actual superpower of a PM.
Also? I used to treat feedback like an emotional crime. Every comment on my PRD felt like a hit job on my identity.
Now? I separate ego from execution. I ask, “Is this feedback useful?” not “Is this feedbackfair to my inner child?” That shift has been a game changer — for my work and my peace of mind.
Practical guidance for new PMs (That I Wish came with the job offer)
-
Treat your job like a product problem.
You will not know where to start. That’s normal. Break it down. Start with what you need to feel functional — product area, stakeholders, org map, whatever. Build a plan. Stay curious. Ask why, how, who, and “why is this held together with duct tape?”
-
Ask for help. Seriously.
You are not a productivity wizard. You’re not here to solo the roadmap. Use your team. Use your manager. Don’t wait until you’re drowning in stakeholder meetings to realize your designer has had the answers all along.
-
Be confident — but don’t LARP as an expert.
Own what you know. Speak clearly. But don’t pretend. You’ll lose credibility faster than a feature spec with no acceptance criteria. Ask questions. Say “I don’t know, but I’ll find out.” That’s leadership.
The evolution: From good PM to great PM
While there is no formula, here’s what I’ve learned and something you might want to take along in your product journey:
A Good PM ships features. They:
- Hit deadlines
- Keep the backlog clean
- Write specs
- Track success metrics
And it’s great. We love a functional roadmap. But it’s also where many PMs plateau — cranking out tickets without ever asking, why are we building this again?
A great PM sells the story. They:
- Inspire with “why”
- Rally teams around a shared vision
- Connect the dots across features, users, and business goals
- Translate strategy into excitement
- Know when to push, and when to let go
When I finally made that leap, something changed: my teams didn’t just build what I asked — they built better. They understood the “why,” and started bringing their own brilliance to the table.
Hence, I encourage all of you to make the transition! You really need to in order to stand out anyway. Moving from execution to leadership takes practice. Try this:
- Start meetings with why, not what
- Share user stories, not just tickets
- Tell your product story like a narrative, not a checklist
- Practice pitching your feature to a non-technical friend
- Ask for feedback on your influence, not just your velocity
It’s not about being louder. It’s about being clearer.
The ongoing journey
I will leave you with one last thought — Product management isn’t a destination. It’s a slow (and sometimes dramatic) evolution. I’m still learning. Still stretching. Still fumbling through strategy docs at 1 a.m.
But if I could go back and tell my younger PM self anything, it would be this:
You weren’t hired by accident. You don’t need to prove anything to anyone. You just need to grow like hell, stay curious, and bring people with you.
Let the chaos motivate you. Let the discomfort teach you. And please — stop treating your roadmap like your personality.
You’ve got this!