Learnings from my first 6 months as a Product Manager
Being a Product Manager is not an easy job to do. I have had some rough days, but those are quickly overshadowed by the days when I’ve felt the satisfaction and fulfilment of solving real customer problems by understanding their pain points. Working as a new PM at a growth startup does bring in a steep learning curve, and I am glad to share my initial set of learnings.
1. Communicate, communicate & communicate
In my experience, I have never seen a PM getting the feedback of over-communicating things. Instead, I have seen vast benefits of communicating and aligning on every plan taken forward, even if repeatedly. It’s been best for me never to assume that the stakeholder would be aware. For one, it helps retaining information if communicated again.
One of the key drivers of this for me has been to document each and everything. I can’t count the number of documents I might have written, be it feature specs, Jira tickets, go-to-market docs, test results, emails, feature instrumentation, MoMs from meetings with stakeholders, Problem definition one-pagers, etc. Documentation is the bread & butter, and the primary output for a PM. The other aspect is to write clear, consistent, and crisp documents. Only when your team trusts you to provide clear and correct information is when you can drive successful executions.
This approach has immensely helped me execute complex features for user onboarding and features with a fair degree of technical complexity like referrals where engineers and QAs look up to me to provide context.
2. Empathy is a game-changer
It is inarguable in today’s product teams to be customer-focused to bring out successful outcomes. One of the key drivers here has been for me to empathize with my users, only after which I can understand what pain points they may be facing with my product.
But being empathetic doesn’t stop here. What about my core team with whom I execute each & every day? It is equally important for me to understand my team’s pain points too. Being an engineer myself in the past has undoubtedly helped me in this regard. No one likes a PM or a business stakeholder who comes in with a feature request to be built, which may be infeasible then. As a PM, it’s essential to be the voice of the customer when communicating with my team, while also striving to be the voice of my team when communicating with the business stakeholders. We all want to be in a happy environment with the best of products for our customers.
3. Being data-informed & not data-driven
This is something that I’ve learned the hard way. As an anecdote, there was an instance when we were focused entirely on quantitative data without focusing too much on the qualitative aspects. During one of the busiest times of the year, our acquisitions from marketing were almost 150% than the usual. Surprisingly, our D1 to D7 retentions had fallen by a couple of percentage points. Being in the onboarding team, the onus was on us to identify the root cause for it. We decided to experiment with a couple of other onboarding flows but to failure. Upon conducting some user research, we realized that due to increased marketing efforts, there was an acquisition spillover into a user segment that wasn’t planned and was not a part of our target users. Subsequently, we decided to exclude that segment from our numbers and surprisingly saw an increased retention metric for our target users.
The key learning here is never to take a metric on its face value and always to get a qualitative perspective on it. After all, we as PMs are serving human beings, and not every emotion is quantifiable.
4. Ideas come from anywhere; problems don’t
In my time as a PM till now, we have managed to build a tremendous backlog of features that seem fantastic when heard about. These ideas can come from anywhere, be it your customers, fellow PMs, customer service, engineering, designers, business folks, etc. However, there is a reason that they are still in the backlog and not executed yet. Not every one of those features will be suitable to solve a customer problem that is keeping us awake at night. As PMs, it is our duty to be the advocate of the problem and be in love with the ‘why’ and ‘what’ of a problem, not the solution. We need to dig out the problem that is keeping us from crossing the chasm towards growth, which is keeping our customers from realizing the potential of our product. Trust me, the engineers and UX designers are much better at bringing out and owning these fantastic solutions. But there is no one except us PMs who can really own the problem and drive towards solving it.
5. Learning should never stop
As a PM, there are tonnes of learnings that come in week in week out. With your product, the learning may come from the experiments conducted regularly, features shipped, customer research, prototype testing, etc. These are what translate into insights that help build better features & products in the future, and also iterate on the current set of live features. Establishing and utilizing this feedback loop is extremely important for any PM, and to drive outcomes for which we are the owners.
On the professional front, I’ve learned a lot in terms of the hard & technical skills and the soft side of skills to be an effective Product Manager. Frameworks & concepts like experimentations, iterations, A/B testing, feedback loops, Product roadmapping, handling data are something which I now live & work by but something vague to me in the initial days. One of the best things I’ve built upon is to read upon fantastic product literature regularly and look to apply the same in my role. I would highly recommend anyone to read through ‘The Lean Startup’ by Eric Ries, ‘Inspired’ by Marty Cagan, and ‘The Lean Product Playbook’ by Dan Olsen, if not read already. The next book on my list is ‘Crossing the Chasm’ by Geoffrey Moore.
With this, I am looking forward to an even more fruitful learning experience in the next six months and a fulfilling experience of solving real customer problems!
