5 Learnings from 5 Years as a Product Manager

I had started writing about my learnings being a Product Manager after I completed a year of being one. At that time I had thought I’d write this every year.

Well then, procrastination took over and rest, as they say is history!

Picking it back up after another milestone year (and hoping I write more regularly now on), here are my top 5 learnings through these years —

1. 50% of a product manager’s learning happens at work and the rest 50% from the time invested in learning outside work

We often get so involved with our work-related deliverables that we don’t prioritise outside work learning. However, I’ve observed that consuming content unrelated to work (reading/listening about different industries, new technologies in all spaces) brings a fresh perspective to work that leads to innovative ideas and solutions.

Here’s how it works: Our current scope of work is always in the back of our minds and while consuming content such as how a new technology would change the world or how a particular strategy did/didn’t work for a company, we’re able to relate this subconsciously to our current work through a chain of ideas and there comes the lightbulb moment!

How to do it?
Start with a few highly recommended newsletters and podcasts such as The Ken, The Pragmatic Engineer, The Hard Copy, Lenny’s Newsletter & Podcast, The Product Podcast.

To begin with, one should slot 15–30 min daily into one’s existing schedule. What has worked for me is to slot 30-min reading in the morning while having breakfast.

2. Measure, measure, measure

If one is asked about the importance of data in the organisation, everyone would say it’s very important. However, when it comes to execution, this statement remains mostly as lip-service.

In the whirlwind of investors looking for stellar features, the sales team pursuing million-dollar clients, and a PM gunning to release feature after feature to get that coveted higher rating, we often overlook the fact that we’ve amassed numerous features with unknown impact.

The subsequent challenge arises when investors, the sales team, and company management seek impact and profitability, but the path appears elusive. This is due to accumulating features that we hesitate to retire, having invested considerable time and resources, resulting in an overly complex and unscalable product.

Hence, to define why we are building a feature/product is more important than building the feature/product itself.

How to do it?
a. Pre-development stage: Spend significant time on understanding the problem that we are trying to solve and estimate the impact for the same.

b. Product development stage: Dedicate time to constructing sample funnels for impact measurement, utilising established tools like Mixpanel, Zoho Analytics, or Google Analytics.

c. Post-development: After shipping the feature/product, promptly assess data and funnels within 2 days to ensure tracking accuracy. Then, iterate measurements weekly. Draw insights, form hypotheses, and make iterative changes. Continuously measure impact to definitively determine whether to proceed or revert.

While exceptions exist, particularly for nascent startups or features tied to external factors, embedding a culture of continuous measurement from the outset remains crucial.

3. Make time for Deep Work

I had mentioned this briefly in my previous article. Yet, this deserves a mention even after 5 years because this is the single biggest reason why some PMs are not able to achieve the desirable results.

Despite being constantly pulled in multiple directions, setting aside daily focused work blocks is imperative to ensure the quality of user research, design feedback, PRDs, and data analysis. Otherwise, these tasks are relegated to a perpetual fire-fighting mode, resulting in the bare minimum being accomplished.

While most meetings PMs are required to attend are related to projects they lead, allocating equal importance to focused, time-boxed deep work is essential.

How to do it?
Prioritise ruthlessly and communicate clearly. For example, respond to each Slack notification with consideration for the context switch between deep work and quick replies.

4. The Cost of a Buggy Release is Usually Higher than the ROI from Releasing it Sooner

If product managers would’ve earned a dime each time they’re pushed to release a feature on a certain date, they would’ve earned a hefty side income!

Jokes aside, being pressured for a deadline can stem from external factors or artificially induced urgency. Regardless, it’s crucial to recognize that thorough testing before release outweighs meeting deadlines.

First, we’re placing the responsibility on users to encounter and report bugs. However, consider this from a user’s perspective: encountering a buggy product or feature often leads to frustration, not immediate reporting. Thus, the user who does report a bug is either deeply dissatisfied or exceptionally loyal. While cultivating unconditional user loyalty is challenging, the consequences of disgruntled users can be severe.

Secondly, the turnaround time for resolving production bugs is typically longer. Bugs detected in lower environments can be swiftly addressed by developers and tested. However, when a bug is reported in production, there’s a delay between user notification and the development team’s awareness. Subsequently, the QA team conducts a sanity test, followed by code merging and other release activities.

Now, don’t misunderstand my stance — I firmly believe in the ‘fail fast, fail often’ philosophy. However, it should be reserved for experimental features and not serve as an excuse to compromise on quality.

How to do it?
First, closely monitor the project and anticipate any potential delays. Proactively manage these delays by unblocking the team, escalating for resolutions, or adjusting scope as necessary.

Second, while maintaining the focus on timely feature releases, also recognize the true drawbacks of prioritising quality over meeting deadlines. Clearly communicate these trade-offs to management when advocating for quality-focused decisions.

5. Failures are personal and successes are for the team

I’m sure you’ve read this everywhere and this is no new information. However, as a product manager, I cannot overemphasise its importance.

As a product manager, owning the product end-to-end entails bearing responsibility for any shortcomings within teams. While the direct accountability rests with the respective teams, the PM is indirectly answerable. Although failures aren’t solely their fault, PMs often shoulder the responsibility, which can feel personally challenging, especially after investing substantial time and effort into a project.

On the flip side, when a product flourishes, it’s the result of collective effort from developers, designers, marketers, salespeople, and others. While the product manager crucially orchestrates the process and maintains alignment with the overarching vision, success isn’t achieved in isolation. It’s the culmination of the team’s collaborative spirit, unwavering dedication, and collective expertise.

Navigating this balance is undoubtedly challenging for PMs, yet good ones exhibit resilience in the face of setbacks. They willingly accept accountability for failures while also recognizing and appreciating the invaluable contributions of their team members.

How to do it?
Well for this, nothing other than practising this for every new product/feature release and gradually internalising it.

P.S. In this world full of GPT-generated content, this is 100% original. (~_^)

Hit that clap icon below if you found this helpful. And drop your comment(s), I would love to know your thoughts.