What does a Product Manager really do? — My side of the story
Nope, this is not another product article with vague terms and Venn diagrams.
While working in a small team last year, I got the opportunity to assume a Product Manager role as one of the several hats I wore. I honestly had no idea what I was doing, and even up till now I still google “what is product management” on some days of self-doubt. Notwithstanding, I went ahead with it and these are the things I found myself doing in my product management role throughout last year.
1. Learning how to check blood pressure
If you’re about to resume in a product management role tomorrow, please stop everything you’re doing, stop reading this article even, go and buy a portable blood pressure checker today. Product management isn’t for the faint-hearted oh, and you should always have this in handy to know when your blood wants to burst in your vein. Don’t say I didn’t warn you!
To do that, you can get one from a doctor or visit Madam Nurse like my friend Ibe.
2. Learning new buzzwords
I primarily call myself a product designer — with all the user-centred, data-driven, human-centric, interactive buzzwords attached; but all those things changed with the new role. I had to start learning new buzzwords associated with product management and practised using them in front of my mirror.
Luckily enough, I found out that I could also use some product design jargon while trying to look like I knew what I was doing when talking about product management.
Product School and Udemy really helped in getting me up to speed!
3. Learning project management
There are 1001 articles online that try to convince you that project management and product management aren’t the same. I’ve read all of them, and trust me when I tell you that you would definitely need project management skills when working as a product manager. To prevent you from reading all those articles and confusing yourself too, just see product management as a modern, more democratic, less rigid role of a typical project manager.
Big foreign companies still separate the two roles though, allowing the product guy to be the Visionary and project guy to be the Military General making sure things are relatively within time/scope/budget.
Don’t even think about it here in Nigeria o, PM is PM.
4. Confusing your clients
Another thing I learnt how to do with my new words and talkative skills, was to put my clients in utter amazement with my passion when talking about proposed projects. I would tell them about activities like conducting design sprints, creating user stories and product roadmaps.
I would usually talk about how AGILE my product team was, and try to explain our development process using words like transparency, milestones, sprint planning (Another sprint? Yes, we like running sir), and backlogs. If you do this too, you are doing a great job at product management!
Don’t know what Agile means? You can get up to speed using this one hour course (I promised no vague terms 🤞 ).
5. Always talking with users
Your target users should be your best friend. When working on a product, you’d see me (who barely talks by the way), forcing a conversation with a random stranger or a friend who fits my user persona.
I would always be running through concepts and performing informal user interviews here and there, trying to find out if the product was a waste of time? Will it make money at all? Obviously, I didn’t know how to present my findings very well to the team but trust me when I say, the user ALWAYS had a voice all through the product development cycle.
I would also have to point out how awkward interviews can quickly get, especially if you’re introverted or just starting out, but I’m sure you’ll get a hang of it (I hope).
6. More grammar
One thing is sure, if you don’t like too much English, you shouldn’t bother taking a role as Product Manager, because it is literally all you will do. Listen to grammar, organize grammar, document grammar, and speak grammar.
One more thing I usually did (that was annoying), was writing Product Requirement Documents. And I’ll tell you this for free, nobody reads them; not the clients, not the developers, not even your employer. Most a-times the clients just want to see working software, your development team would usually prefer going through your user stories, and your employer just wants to see credit alerts.
But you still have to write them though, for documentation purposes of course. You can download my PRD template here.
7. Accurate timekeeper
Well done! You’ve ordered for your BP checker, you have all those new buzzwords flying in your head, you’ve embarrassed yourself enough trying to advocate for your users, and your unread PRD has been approved.
The next thing you would have to learn is working with your preferred monitoring tool, filling it with user stories, tasks, dates, comments and everything you can think of. One piece of advice here, use what you’re comfortable with, don’t go learning a new tool so that you could fit in as a trendy PM.
8. Influencing productivity
Remember what I said about being a product manager in skill 2? Let’s just say you really don’t have any authority over your team, but still, if things don’t go well, it’s you that will face the music.
So how did I solve this dilemma? I tried to influence productivity, right from the early stages of sprint planning where we would argue endlessly on the most difficult tasks and features; right down to encouraging the developers to work weekends (I’m a wicked soul don’t worry); answering calls from Sadiq by 2AM, and always asking how far in the most subtle (yet obvious) way possible.
And mind you, you’re also the jury, mediator and attorney whenever your team members get into conflict with themselves, so just prepare to resolve disputes along the way.
9. Presenting perfection
Show me a product manager that sleeps on the eve of a product demo, and I’ll show you a true cultist. After months of sleepless nights and a series of how fars, it’s about time to show what you said you’ve been building!
Thank God for the lockdown last year and the emergence of Zoom, it really helped because no one could see my sweaty palms and shaking hands. Or notice when I’d message the lead developer if the errors on production have been debugged while also presenting the finished software simultaneously.
After all is said and done, you really don’t want the development team to be jobless after your demo, because their jobs literally depend on how perfect you present your product to be…
Epilogue
If you made it here, that means you didn’t get caught (yet), you still have a job and your baby product is out in the wild, killing it with impressive metrics! You can relax your nerves a little by drinking a cold bottle of beer and listening to Burna Boy sing 23.
You’ll get it right the next time…
You think?? 🌚
