They don’t give you a handbook when you become a PM.
You just get a calendar full of meetings, a backlog that somehow tripled overnight, and a quiet expectation to know what you’re doing — even when you don’t.
The truth? Most of product management is learned in motion. Through missteps, recoveries, and the occasional “we launched what??” moment.
Here are ten lessons I’ve learned — not in theory, but in practice. Sometimes gracefully. Often clumsily. Always the hard way.
1. If you don’t decide what matters, someone else will — and fast.
There’s always someone ready to tell you what your product really needs.
That pop-up. That integration. That “quick win” they promised a client over lunch.
And if you don’t protect the roadmap, it turns into a free-for-all — a collection of wishlists and political IOUs with no through-line.
Prioritization isn’t about saying no to people. It’s about saying yes to focus.
2. People want clarity, not complexity.
We once built a brilliant, technically elegant reporting feature.
It was configurable, scalable, and genuinely impressive.
But almost nobody used it. Not because it was broken — but because it wasn’t obvious.
We fixed it by asking: “What does someone need to see in the first 5 seconds for this to make sense?”
Turns out, the answer wasn’t more options. It was more clarity.
Sometimes impact is found not in what you add, but what you simplify.
3. Talk to users — especially when it’s a little uncomfortable.
No dashboard beats a real conversation. Even when it’s awkward........Especially when it’s awkward.
The first time I sat in on a user interview, I was nervous they’d hate what we built. And sure enough, they pointed to one of our features and said, “I don’t really get what this does.”
It stung. But it taught me more than any metric ever could.
Lean into the hesitation, the confusion, the offhanded “I usually just ignore this part.” That’s where the roadmap lives.
4. Your roadmap is not set in stone. It’s more like a living hypothesis.
Every time I’ve tried to build a “perfect” roadmap, I’ve regretted it within the month.
Teams shift. Priorities change. The market throws you a curveball.
If your roadmap can’t evolve, it becomes irrelevant.
Treat it like a living document. Something you return to, adjust, and annotate — not a frozen artifact that gathers dust in a shared drive.
5. Good engineers build what you ask for. Great ones build what you need — if you let them.
There’s a world of difference between handing over a spec and inviting someone into the problem.
Early in my career, I’d write out detailed tickets with no room for discussion. The work got done — technically. But it lacked soul. Creativity. Ownership.
Now, I treat engineers like partners, not processors.
I bring them into conversations early. I explain the context. I ask for their perspective. And the work we do together is miles better because of it.
6. Saying ‘no’ isn’t rejection — it’s redirection.
It’s not easy turning down a feature request from someone more senior than you. But product management isn’t about saying yes to everything — it’s about protecting the focus your team needs to succeed.
I’ve learned to frame “no” as an invitation to rethink the problem together:
“What’s the outcome we’re aiming for? Is there another way to achieve it without derailing what’s in flight?”
Most people respect a thoughtful no more than a reactive yes.
7. Stories connect people. Specs just explain things.
A nine-page spec rarely inspires. A simple story often does.
I remember walking into a meeting with a technical deck full of diagrams. It landed flat.
Then I said, “Imagine you’re managing 30 client accounts and every morning you have to manually check which ones need attention. What if we could make that insight appear — first thing, no clicks needed?”
That’s when heads started nodding.
You don’t need theatrics. Just remind people why the work matters.
8. Not all metrics are created equal. Some are just noise in disguise.
Our activation metric once went up 20%. We were thrilled — until we realized people were getting stuck in the first step and refreshing the page over and over again.
Vanity metrics look good in a slide. But real insights come from friction:
Where do people hesitate? What’s not landing? What looks okay but feels off?
Good PMs track success. Great ones investigate discomfort.
9. Assume you’re wrong — early, often, and with humility.
One of the best things you can say as a PM is: “I’m not sure. Let’s test it.”
I used to push features based on conviction alone. Sometimes they worked. More often, they didn’t.
Now, I prototype earlier. Ask more questions. Share rough drafts. And I try to be less precious about being “right” on the first try.
Because progress isn't about being perfect — it’s about being willing to learn in public.
10. Your calm is more valuable than your confidence.
Things will break. Deadlines will slip. Someone will discover a bug right before launch — and tag you on every channel at once.
In those moments, your role isn’t just to solve the problem. It’s to steady the room.
I’ve seen brilliant teams spiral under pressure — and I’ve seen them rally when someone calmly says, “Let’s take a breath. Here’s what we know. Here’s what we’re doing.”
People won’t remember every decision you made. But they will remember how they felt working with you.
Final Thought
Product management is less about managing a product — and more about managing uncertainty. It’s messy. It’s human. And no two days look the same.
You won’t always get it right. That’s okay.
Just keep asking better questions, listening more than you speak, and showing up for your team when it matters most.
The rest? You figure out as you go.
I hope these pointers were relatable, and help you in your journey.
Until next time, keep learning, unlearning and relearning my friends!
Please do like, share and subscribe to me if you like this content, it will give me a lot of encouragement.....
Thanks again for tuning in.