My First Month as a Product Manager

Time flies when you’re having fun, or going through a steep learning curve, or both. The past month truly felt more like a week! I’ve always believed reflective journalling is beneficial for personal growth… Without reflection after action, how do you truly know what you have learned? I decided to do some journalling and share it with the world, so here it is: my notes from the first month as a product manager. My experience is in online streaming/ media entertainment so some aspects of this article have a heavier focus on that.

PMing at a large corporation = a lot more needs to meet than at a startup.

I had a PM-esque role in a startup context with a team of 7, so this is the first thing I realized: the underlying process and considerations are similar, but at a larger firm, it’s on steroids.

Similar to a startup, you get delegation of work, discussions, balancing needs between design, engineering, business, and external stakeholders. This startup context is only a microcosm of what it would be like at a larger firm though. Comparing these two personal experiences, there are more complexities in:

• External stakeholders: at the startup, the only external stakeholders were investors and partner brands. Here, we’ve got platform providers, content providers, providers of stuff you integrate into the app, providers of software you use to aggregate stuff into the app… and because you’re bigger, you’re a more valuable partner/stakeholder for them too so they care more than if you’re a tiny player.
• Internal processes: at the startup, we’ve only got 7 people. Want something? Just give them a shout. Who’s in charge of what? We all know that, because it was a tight-knit team. It is the same case for the immediate team currently, but there are many more internal stakeholders within the company in charge of more specific pieces of marketing, data analytics, operations… because of the SIZE of everything.
• Customer feedback: being a big player in the industry means always being in the spotlight. Customer feedback is always key to improving one’s service, but it genuinely is so hard to make everyone happy. If there’s a 0.1% chance of someone getting upset over an action the company decided on — having 100 customers means statistically nobody gets upset, and having 100K customer means 100 are going to get upset. If you think about it, 100 people is kind of a lot of people for being upset at you xd
• Legal requirements: with great power comes great responsibility. This piece ties into both partnerships with external stakeholders and interaction with customers. Perhaps due to the fact my startup experience was still quite early-stage, I did not experience the impact of this as much!

I must note the difference I felt in levels of complexity is also affected by difference in the industries the products were in. (ad-based social media vs subscription & paid online streaming)

The easier it is for the user, the harder it is for the team.

Coming from a user perspective, as someone who frequently uses streaming applications (and I mean FREQUENTLY… I’m pretty sure at least 75% of us have binged an entire season of some show in a day at some point in our lives) I definitely came in feeling super excited to bring about new changes and features! And I 200% still am! What I did not have was a genuine sense of appreciation for everything that’s behind the scene.

The title for this section is one of my favourite quotes surrounding product, I must say “harder” is not necessarily accurate, it’s more accurate to say “more effort” or “more levels of thought”. If the user has a ton of ease navigating (great design, frontend, and user testing) successfully playing the content (great backend), the team must’ve put in lots of effort and every second of work is worth commending. If the user finds everything confusing, everything error, I can’t say it’s necessarily easier for the team — but something like a tight timeline for whatever reason out of the team’s control, or lack of feedback before decision-making may have happened. Sometimes, it could be a legal/contractual requirement that makes it harder to understand the way things are presented in the application.

The “play” button placement? Someone thought about that for hours. Error message that was displayed when payment did not go through like 1% of the time? Someone also thought about that, curated the message, and discussed with the team on how to present it. There’s a new row for Christmas movies? Who knows, the team may have had a few back-and-forth debates on that. The list goes on — and I must appreciate everything behind the scene more as a user, now that I have first-hand experience with an amazing team.

Everyone has a different focus for the same project. You must provide the entire context to everyone involved.

A lot of teams call themselves “cross-functional”, but I don’t think you can get as cross-functional as a team of people that has entirely different backgrounds in education! CS, business, design, sometimes data science, three/four very different disciplines coming together means everyone has a very specific focus for the same project. This means if you are someone who is coordinating and leading a project from start to finish, you need to give everyone the entire context. Moreover, after providing the entire context, you need to provide more emphasis on what they should care about — not only the “what”, but also the “why”. Yes, you are the one who knows it from start to finish, but you are also the Jack of all trades who doesn’t know the specifics of one piece. To get the specifics, you need to provide team member the ability to give you feedback by allowing them to know the “why”.

Thanks for reading! I’ll write one for 6-months as well :-) TTFN