Lessons From My PM Journey…So Far
A beginner product manager’s guide to not consistently screwing up.
Before we begin, a caveat: this is not a dunk on developers, even though it might look like it. Any possible slight to developers real or imaginary is totally unintentional…. I think 😁.
Although I’ve flirted with the role of a Product Manager for over a year, I only decided to officially make it serious a couple of months back. The role wasn’t difficult for me to transition into: I’ve always been a generalist, having played different roles from marketing and operations to strategy and people management in my previous endeavors.
However, being a generalist can be exhausting — you are good enough to know about everything but not enough to be an expert in any.
Product management seems to be the next best fit for me, a way to coalesce all of my disparate skills and expertise into something a bit more specific.
So, I started the only way I knew how — by doing.
I read a lot of books and articles, listened to podcasts, and took a few courses. “It can’t be that hard…” I thought, and boy was I wrong (but this is a story for another day). Anyway, I volunteered for a product role in my church as we seek to enhance our tech footprint — starting with the website redevelopment.
My career had officially begun.
What we learn to do, we learn by doing.
It was the kind of role that allowed me to learn and experiment, but engaging enough to get me hands-on experience. I learned to engage with senior stakeholders to understand the vision and objectives, designers and developers to build the vision (more on this later), and prospective users to know how they fit into the product vision.
Notwithstanding, my career is still young; I’ve made a few mistakes, and learned a lot — usually the hard way. I don’t pretend to know everything there is — a good product manager never stops learning; however, I’ve picked up some lessons along the way, and here are a few of them:
1. When it comes to time delivery, NEVER give a direct response.
This is one of those lessons I had to learn the hard way. When dealing with timeline deliveries, always give yourself enough wriggle room, in case things don’t go as planned (and they never do). For example, if the top brass wants a feature done in 7 days, tell them it will take between 12–15 days. Then tell the developers they need to deliver within 4 days. It doesn’t always work though, developers can be inexplicably erratic (I’ve always wanted to use this phrase in long-form writing 😁); you never know when to expect what to expect.
What this does is that it gives you enough time to find solutions when things don’t go as planned, or cook up an excuse for more time to deliver if necessary (more the former than later). Always use ranges instead — “between 7–10 working days” instead of “Next Friday.”
2. Constant Communication is very important(er):
Constantly communicating with all stakeholders is key when handling a product. Developers hate giving feedbacks, especially when they are stuck, you literally have to pry it out of them. Your executives want constant updates, users want to know when a feature will be ready — it’s a constant circus, and you must be comfortable being the clown. You must learn to compartmentalize information and tell everyone what they need to know, when they need to know it.
A few weeks back, my church leadership wanted a feature implemented on the website, and they wanted it done immediately (Another thing you’d learn is that bosses always want things done immediately, if it’s possible, do it. If not, please say so immediately).
I asked for a couple of days for it to be delivered but of course, developers will always be developers, so I had to go back and ask for an extension. Being less specific with delivery timelines sometimes helps reduce the need to constantly ask for an extension, however, there are times when this is inevitable — you just would not be able to deliver within said time, or there is a problem that you need help sorting out — It is always better to communicate updates, possible solutions, and extension requests as quickly as possible rather than waiting until close to deadline. This makes you more proactive.
3. You really are just a glorified babysitter.
Except in this case, your charges aren’t obnoxious toddlers or young teenagers but mature adults (well…usually). Like Alfred to Batman, you are everyone’s loyal messenger, tireless butler, guardian angel, best friend, aide-de-camp, and surrogate parent. You’re just a glorified maid, really (sometimes not even glorified) — whether it’s pandering to your executives to temper expectations, defending your team before your leaders, speaking to customers to understand their pain points, firefighting between designers and engineers, or buying multiple bottles of Coke to motivate your developers so they can meet up the deadline (I won’t mention names).
You do whatever is needed to get the product to work.
One important rule to bear in mind here is that you manage products, not people; you are actually nobody’s direct boss. Hence, you must learn to achieve everything using soft influence, effective communication, leadership, biblical long-suffering (patience), and trust — not orders.
An extra lesson….
Resourcefulness
If you only need to master one skill as a PM, this is it. You don’t just set the vision; you get everyone involved to work their arse off towards achieving it. This means helping everyone overcome any hurdle that might hinder their work, or at least creating a framework where they can sort it out themselves. The goal should be the latter though but sometimes you have to get your hands dirty.
Lately, my team has been working on automating a certain feature on our website. My developers wanted to build the code from scratch but this would take time, (time is a luxury PMs can’t afford), and it might not even work. I decided to do some research to get possible solutions, and I came across one, quite serendipitously I might add while scrolling through X (formerly Twitter).
You have to be resourceful: whether it’s thinking about possible pitfalls and addressing them, searching for useful API integrations, troubleshooting code errors even if you can’t write a single line of code, or simply getting drinks for the team to show appreciation. Your job is to do whatever is right (not easy) to get the product working.
I learned to do all of these, engaged in numerous meetings (and I hate meetings!), wrote user stories, and created PRDs, and product backlogs(which wasn’t too difficult as I was already a freak for documentation, although I had to learn the right format) - simply doing the scut work so others can do theirs.
Of course, it hasn’t been easy. It’s a journey that can only get better and tougher I suppose but then, whatever I’ve learned to do, I‘ve always learned by doing.
I still have a lot to learn though. It’s going to be an interesting next couple of months.
