What I learnt in the process of speaking to 50 Product Managers

Source: Product Focus

Product is still a relatively new function in a lot of companies. As a result, it is tough to carve your path in companies where the role is not well defined.

By the time I joined Scatter, I had gained a sense of what a Product Manager does, but the scope of my understanding was limited to what I had learnt in my last organisation.

I spoke to several experienced product management professionals in different organisations and read a lot of blogs to try and get answers to the following :

1. How does a Tech PM differ from a Business PM?
2. What should an ideal day of a PM look like?
3. What should a PM focus on before, during and after the implementation of a new product?
4. Why is it important to track metrics when building products?
5. What metrics to track? How does it differ for consumer products vs SaaS-based products?

The answers to these questions were not straight-forward and generally differ for different organisations. I will try answering these questions in my upcoming blogs.

In this blog, I will try to cover :

1. A regular day as a Product Manager
2. Tools used by Product Managers
3. Challenges faced in implementing a structure to the role

1. A regular day as a Product Manager

Based on the conversations I had, here is my understanding of the set of tasks that a Product Manager performs on a day to day basis.

1. Standup Meetings — Speak to the engineering team and update the status of the tasks in the current sprint. Identify any blocking issues and try to resolve it. Streamline the priority of the tasks based on the severity of the issues and time to launch based on market needs.
2. Writing PRDs — The next set of features that have to be built need to be drafted out in detail for the engineering team. It requires a lot of research, meetings, getting approvals from senior management. You need to define the pre-requisites, assumptions, short-term & long term goals and the success metrics for every feature.
3. Reading — Reading is a very important component in a PM’s day. What is the competition doing, what are the next set of market trends and how different organisations have solved certain problems. This information is quite helpful at the time of having a conversation with developers. It lets you can add context to certain features with facts and numbers and it is easier to convince the developers when you are defining the need for certain features.
4. Project Management — Although the engineering team updates the status of the daily tasks, it is important to keep track of how we are currently placed in terms of the overall project deadline. Also, if certain features are taking more time than estimated, as a Product Manager you get to decide if some features can be moved to the next release or if the deadline needs to be shifted to count in for the effort.
5. Tracking metrics — How I track metrics has evolved based on what stage the product has been in. Also, with time, I have become more informed about the various ways of capturing these metrics. This article on HackerNoon talks about the GAME Framework for capturing the right set of metrics and evaluating them. As per Cole Mercer, the five broad categories under which you could track your metrics are —Growth & Activation, Engagement, Retention, User Happiness, Revenue
6. Qualitative Feedback — Talking to customers, customer success teams, tracking the queries on your customer messaging platform and app reviews can provide a lot of insights on how you can improve your product or what new features you can bring in. If the scale of the reviews is too large and you cannot go through each and every review, you can use Google Cloud NL API to run a Sentiment Analysis on your user reviews and add a weight to each of the problem areas. Here is a video that demonstrates the same.

A regular day as a PM could be all or some of the tasks mentioned above depending on the stage of the product.

Bonus Tip | Tracking Metrics

Assuming that there is a transaction involved, revenue becomes the most important metric for most products. Here is one metric that almost every product manager needs to keep a track of :

Avg. increase in Revenue per month = (No. of new users — User Churn) * ARPU

*ARPU = Avg. Revenue Per User

*User churn = No. of uninstalls /No. of subscriptions cancelled

2. Tools that Product Managers use

Apart from interacting with different stakeholders, a Product Manager interacts with a number of tools throughout the day. Most of the basic versions of these tools are free, whereas enterprise versions might have a small fee.

Meetings: GotoMeeting, Mixmax, Zoom, MS Teams

Product Roadmap — Trello, MS Excel

Wireframing — Balsamiq, MockFlow

Prototyping — InVision

Internal Communication — Slack, Workplace by Facebook, MS Teams, MS Kaizala

Project Management — Trello, MS Excel

Analytics — Google Analytics, Omniture, Mixpanel, Segment

User Recordings — Smartlook, FullStory

Bug Tracking — JIRA, Bugzilla, Redmine

A/B Testing — VWO, Optimizely

Sentiment Analysis — Google Cloud NL API, MonkeyLearn

I came to know about some of these tools during my conversation with other PMs. According to them, it’s only when you have these tools set up, you can diagnose a problem faster when the product is being used at scale. Here is an example of a similar problem —

Suppose you are the PM of an e-commerce firm. You notice that the cash on delivery orders are higher than average by 15% on a certain day. How would you diagnose if something has gone wrong with the product?

P.S. — This is a very popular interview question as well. You can access a curated compilation of product problems and case studies here

3. Challenges faced in implementing a structure

In order to have a more defined role, I had to implement a few structural changes within the organisation, as we moved from a beta product to a product which had close to 2500+ users and 120+ customers.

There were a few challenges that I faced in the process, the most significant of them being - setting the right expectations.

It is true to some extent that Product Managers are perceived as engineers dressed in a business suit by the other teams, who are not completely aware of this job function. So while the engineering team is busy writing the code for the next set of features, it is the Product Manager who has to perform a lot of ad-hoc tasks in order to get things done.

A good example of this is setting up an account for a client at the time of on-boarding. Although PMs create multiple walkthrough videos on how to register for a new account, in order to on-board a new customer without any hiccups, sometimes I’ve had to register and share the login credentials for the client. The client just had to change the password on receiving the login details.

Initially, I encouraged the teams to tag me on everything related to the product. However, I realised that it is not a scalable approach and it was important for me to change this habit internally. Hence, I set up a process where the teams handling the clients were made owners of the client actions on the platform. If there is something that they could not handle, they would raise a flag to the Product/Tech team.

It took some time for the teams to get conditioned to the new process because the client servicing teams were too used to tagging me on everything related to the product. However, with time things got better.

This helped me set out time for talking to customers, keeping a track of the project better, prioritising bugs and helping the engineering team to make certain decisions on how to approach certain problems, based on my previous experience.

What makes me feel good now

I feel my biggest achievement has not been launching multiple products at Scatter. It has rather been changing the way the product is being perceived. From being once called a “shitty tool” to being referred to as the “game-changing product” by a top CMO, makes the entire effort worth it.