Guest Post by: Vivek Karna (Mentee, Session 11, The Product Mentor) [Paired with Mentor, John Masterson]

1. Introduction

As one transitions from being a follower to a leader in any role, the amount of leverage that person has on the organization increases manifold. Hence it is critical that one is aware of the best practises of the role and develops his own philosophy which results into maximum positive leverage for the organization. This is my motivation behind writing this article. As I strive towards becoming a product leader, I wanted to understand the best practises in product management and in the process develop my own product philosophy. 

This article explores multiple aspects of product management. I hope this can act as a ready reckoner for the Product Management community which they can use to manage their transitions well as they grow in their roles. Primarily there are 3 major aspects to understanding and performing well as a Product Manager, which are as listed below:

1. Understanding the Role Definition
2. Hard Skills required for the Role
3. Soft Skills required for the Role

Let us explore these 3 aspects in more depth in the sections below.

2. Understanding the Role Definition

2.1 Definition of PM role

Relative to other standard roles defined in an organization such as Ops, Marketing, Tech etc., the Product Manager role is a rather recent phenomenon.  As a result, there are various different approximations that are made about the role in an organization depending upon their experience with building products. Often, this is due to resource constraints rather than a lack of understanding of a PM role. Product definition thus varies from organization to organization which causes confusion and frustration within product organization. Mushrooming of training sessions and certifications on PM reflects the situation quite well. 

Below is a list of various approximations to a Product Manager role that exists in an organization:

1. Project Manager/Project Coordinator
2. Business Analyst
3. Customer Experience Manager
4. And many others…

In my understanding, there are certain basic principles that a PM role should adhere to:

1. Understand the Company’s objectives and market(s)
2. Understanding Customer Problems in the defined Market (More than stated, the unstated)
3. Building up product vision (near, mid and long term)
4. Prioritizing the product features
5. Solutioning the problem
6. Championing the product within the organization (requires stakeholder management)
7. Ensuring the execution is as per product specifications
8. Rollout planning
9. Ensuring Product Market Fit

If you are not performing the above activities, your role may be an another approximation to a Product Manager role. A PM may receive help from specialists in the organization such as Researchers, Project Managers, Product Marketing etc. Ultimately the accountability lies with the Product Manager. I will be covering certain aspects of the above stated principles in the sections below.

2.2 Specialist PM Roles

In the above section, we discussed the competencies of a Product Manager. The competencies vary as you grow in the product organization from a Junior PM role to a VP, Products. As you climb the ladder, primarily the focus changes from solution and execution to strategy.

Also, in various organizations which have grown in product maturity, customer base etc.,  there are specialist PM roles created to focus on depth rather than breadth. Few examples:

1. Growth PM/Growth Hacker – This role focuses on increasing the top of funnel and ensuring lower drops off during the conversion. This role also focuses on increasing the retention rate for existing customers. Sometimes this role is being entrusted upon PMM (Product Marketing Managers)
2. Platform PM – A platform PM’s mandate is to ensure that Platform is built in a way that it’s easier to scale, add new features/applications to the platform and there is a consistency to the experience. A Platform PM also concerns himself with stability and safety of the platform.  A Growth PM is also part of Platform team as the focus is to improve the experience to increase top of funnel and optimum onboarding experience. 
3. Data PM: organizations dealing in data products (building AI/ML based products) prefer a PM with data science background so that they can appreciate the problems well and being able to work with data engineers/scientists.

3. Hard Skills Required for the Role

There are many frameworks available on building products and the approach varies individual to individual. This section sets out my philosophy on how to build products. It contains subsections with steps that one should go through while building products. 

3.1 Product Strategy

As a first step, PM needs to define the strategy for the product. A well defined product strategy provides insights into the deep customer problems that your product is trying to address. A product strategy should align to the organization OKRs as ultimately you are building a product to achieve a business goal while serving the customers. 

Product strategy does not have to exist only as a long term strategy, it can also exist as near term and mid term strategies. Product strategies frequently have to be changed depending on the market conditions and changing business goals. A well defined product strategy needs deep understanding of the market, customers and competitors. This is not easy and requires the following:

1. Talking to experts
2. Customer Research – through Interviews, Surveys, FGDs, Observations etc.
3. Understanding competition including mystery shopping
4. Understanding your own company’s strengths and weaknesses

All of the above is required to define the destination of your product. The path and the steps to reach the destination is defined through a product roadmap. Hence roadmapping is a crucial exercise which can make or break your product. In my opinion, apart from  a bad culture, a bad roadmap can also have a devastating impact on your organizational strategy.

3.2 Product Roadmap

Traditional vs Theme Based Roadmap

Traditionally product roadmaps have existed in form of features list against a timeline. However, executing such a roadmap is practically difficult as a PM cannot define a roadmap so far ahead in time. Hence, a better approach to product roadmapping is to create theme based product roadmap where only those product features are committed to where we have enough clarity on its impact on achieving the organizational OKRs.

A well structured theme based roadmap includes the following:

1. Clearly  identify various themes for the product such as Acquisition, Onboarding, Gamification etc. Once the themes (aka feature groups) are defined, it becomes easier to think through the features that falls under various themes.

2. There are various tools that can be used for roadmapping such as Aha!, Airtable and most simply on excel. The tool matters less, what matters more is how a roadmap is defined and executed.

3. Generally, high level roadmapping should be done for a year. I have seen roadmaps projecting 5 years down the line, I don’t think this serves any purpose as the time frame is too long for any product with a lot of assumptions being made.

4. A year long roadmap should be high level. However, the upcoming quarter roadmap should be more detailed with exact projects being identified. This includes Tech estimates (at least T-shirt sizing) and resources identified for the projects. 

5. The quarterly roadmap should be done, signed off and socialized with the required stakeholders in management, product, tech and business.

6. For the projects identified for the 1st half of the quarter, product specs along with JIRA tickets should be ready before the starting of the quarter so that Tech is not sitting idle waiting for product specs to be delivered.

7. If OKRs are being followed in your firm, then all the projects defined should be mapped to one or more Company OKRs

Data vs Intuition

In context of product roadmapping, a topic which gets extensively debated in PM community is data versus intuition in building the roadmap. My personal take on this topic is that there is always a mix of these two in product roadmapping for any organization, however the mix percentages can vary from organization to organization depending on the product they are building and the DNA of the organization. I have never come across any organization which makes all product decisions entirely based on data or intuition. Extremities never produce optimum results !

3.3 PRDs

A PRD needs no introduction. Every PM would have written a PRD no matter which organization they worked for. However, what needs to be discussed is the relevance and structure of PRDs. As the product understanding has evolved, so has the structure of PRDs. Monolithic PRDs have given way to User Stories in today’s era. In future, this might give way to some other structure. 

The PRD is a PM’s primary communication tool with engineers. A well crafted PRD will require less back and forth between PM and Engineers and thus ensures faster delivery and low wastage. Even if you are writing big monolithic PRDs (not recommended), you should still break it up into smaller sections and ensure that the flow and language is proper and easy to understand to achieve maximum readability. Ultimately, its humans reading your PRDs and if not well written, requirements will get missed. Though I do not want to suggest a template for a PRD, following sections should be covered in one:

1. Problem Statements
2. Solution Considerations
3. Market Sizing
4. Success Definition (Outcomes/Key Metrics)
5. Functional Requirements
6. API definitions if its an API product
7. Non Functional Requirements
8. Instrumentation Requirements
9. Operational Requirements
10. Rollout Plan

3.4 Executing the roadmap

It takes one skillset to create a roadmap but an entirely different one to execute it as per the plan. There are many obstacles to successfully executing a roadmap. Some of these are listed below:

1. JIRA tickets not well defined. Details are missing leading to back and forth between product and tech thus causing delays. This could be due to lack of product, domain, system understanding and action should be taken to address such instances soon. This could also be due to stringent processes or lack of the same. Ex: Backlog grooming/refinement, Requirements review etc.
2. Ad-hoc tasks: This could be due to multiple reasons as mentioned below. Ad-hoc tasks should be tracked separately to analyze time spent on them during the sprint.
   1. Known system issues/tech debt not being prioritized leading to ad-hoc urgent production issues to be fixed which takes away engineering time away from development.
   2. Not correct prioritization done by PM when the issues surfaces. Not everything needs urgent attention. 
3. Scaling the team: As you scale the engineering team, it takes effort to onboard the new team members. If a proper onboarding plan is in place and is successfully implemented, then this should not cause obstacles to planned activities. However, if not planned and executed well, it can take a heavy toll on the existing members. Note: 1 + 1 does not always equal to 2. In such cases, it can actually mean 0.7 because the new joinee will not be productive but rather eat into the productivity of the existing team members.
4. QA + Rework

In most of the firms around the world, execution is done in sprints (most likely as 2 week sprints) and the sprint planning and tracking is done in JIRA. There are other tools as well, however, JIRA works well for most. Discipline is required to ensure that execution goes smoothly and can involve the following:

1. Daily standups – These can be physical or virtual. In case of co-located teams, physical standups are preferred.
2. JIRA tickets are updated during the standup. Note: It would be hard to track and then follow up engineers to update the JIRA if not in standups
3. Proper dashboarding and reporting to be done in JIRA so that required stakeholders are informed of the progress on a regular basis – at least on a weekly basis. 
4. Ideally, none of the tasks created in JIRA should be more than 1 day effort. The likelihood of wrong estimation and slippages are high when the tasks are greater than a day’s effort. 
5. Sprint retro should be done as part of the sprint planning meeting for the upcoming sprint. This ensures more participation as this is not a separate meeting on the calendar

Depending on the organization, the above activities can be taken up by a Scrum Master, Technical Program Manager, Engineering Manager or Product Manager. Ideally, Product Manager should not own these activities but should participate in daily standups to be aware of the status and address any blockers and make quick decisions to move forward. A PM, however, should explain the importance of process adherence to the team so that these activities are not looked upon as mere admin activities.

3.5 Rollout Planning

Note: Do not confuse this with Tech releasing planning. Tech release planning is owned by Tech and generally PMs are not involved in this activity.

To ensure Key Results are met and returns are maximized, PMs need to define the rollout plan for the features being developed. The major objective of a rollout plan is to ensure that Product Market Fit is realized within a well defined timeline.

A rollout plan can comprise of following:

1. Defining the order in which requirements should be built and shipped. This is critical for scenarios where the project has multiple functional requirements and thus cannot/should not be built and shipped together. 
2. How the features or sub-features shipped should be marketed to the desired customer segments – existing or new. If the organization has a PMM (Product Marketing Manager), PM would work with PMM on this aspect
3. Rollback strategy if the rollout experiences turbulence. Rollback criteria needs to be clearly defined in the rollout plan for quick action if the situation occurs. Not all rollout plan would require a rollback strategy though. 

3.6 Tech Grounding required for PMs

In a nutshell, a PM is a multiplier for developers. Engaging with Engineers is inevitable for PMs and hence tech grounding is required. However, a regular discussion topic in PM world regards the depth of technical knowledge required. This section addresses the topic.

For a PM working in a Tech company, technical understanding is expected. In such firms, there is a bias towards PMs with Tech background (who have been engineers before or have studied engineering). The hard truth is that engineers in a Tech firm will not see much value interacting with a PM who does not speak the same language to a certain extent. Hence for a PM with no tech background at all, such a place could be a little daunting.

However, for other firms where the tech focus is not so high, PMs come from various backgrounds such as Marketing, Operations, Sales etc. This happens because products can be internal or external and the SME knowledge helps. Think of a person working in operations starting as a PM in a supply chain product. Due to the SME knowledge the person would have, he/she will be able to make an impact quickly.

4. Soft Skills Required for the Role

In case of PM role, it does not matter if you have direct reportees or not, you will still have to manage people (internal and external). The breadth of the people that a PM has to manage is very wide. It might involve managing a Junior Ops executive at one end to the CEO of the company at the other end of the spectrum. Hence, sound people management skills and the ability to tailor the communication are the keys to success in PM role. A PM needs to exhibit following behavioural aspects:

4.1 Behavioural Aspects

1. Influencing without authority 
   1. Build domain expertise
   2. Show ownership 
   3. Influencing senior stakeholders
   4. Build business case 
2. Stakeholder Management
   1. Identify all stakeholders which can impact OR are impacted by the project
   2. Preparing a stakeholder heatmap
   3. Understand the stakeholders and their communication styles, decision making framework 
3. Champion of Product within the organization
   1. Managing Cross Team Communication
   2. Work with Business teams to ensure your product gets the desired mindspace in business teams. This is especially important in the B2B space.
4. Being Productive 
   1. PM needs to have interactions with almost all the functions of an organization and hence naturally ends up in many meetings or ad-hoc interactions/discussions. Hence little time is left in ensuring that product specs/JIRA stores are well defined in time for tech to pick up and execute. Hence its important to be productive and utilize the time as efficiently and effectively as possible
   2. Many productive tools & techniques are available which can be used to be more productive such as Pomodoro technique, timeboxing the calendar etc.
5. Being Empathetic 
   1. PM needs to be empathetic not only to customers but also to the internal employees and stakeholders he/she is dealing with. This helps in understanding the constraints and pain points well and thus arriving at a solution which is unique and customized to the person and context
   2. Please also note that Scaling People is not easy. With more people in the team, it becomes difficult to maintain the culture and work ethics & discipline that you would like the team to have. Lack of this ultimately impacts the product delivery and hence though it may not sound as a problem that PM should worry about, it has an indirect impact on the success of the product, company & ofcourse you !
6. Being Trustworthy. Trust can be built through following means:
   1. By being transparent
   2. By being vulnerable

4.2 Communicating with Stakeholders

Having a strong communication strategy for stakeholders is critical to the success of a product manager. A product manager has to deal with a wide range of stakeholders – internally and externally. Product manager should approach the task of stakeholder communication as a marketer and keep communicating about the product as a broken record without worrying much about the information overload. In my experience, no stakeholder complains about over communication. However, one needs to be cognizant of the seniority of the stakeholders and should tailor the communication accordingly. Top management prefers concise summaries rather than details whereas mid and junior management would prefer more detailed communication.

Communication is done for various purposes and everytime one is communicating, the objective of that communication should be clear. For example: the purpose of communication could be (a) to get sign off on the product roadmap, (b) inform launch of the product, (c) seek additional resources to complete the project on time, etc. Having a clear purpose to the communication helps helps in deciding the audience and content of the communication. In case any decision/action is required from the recipient, it should be clearly called out in the communication.

There is a ton of materials which one can go through to truly understand the mechanics of a good communication strategy, however, a thumb rule in communication is that no one likes surprises, especially the top management so communicate enough so that the right message receives the right audience at the right time. 

5. Concluding Remarks

A PM is always a 10x role as he/she needs to interact with multiple functions within the organization and hence a Product Manager role is many times defined as CEO of the product. I hope this article helps you understand the various aspects of the role in order to be a successful  Product Manager. Would love to hear from the community on the same and contribute to a better understanding of the role. Hope we all can move away from approximations and truly understand and act as a Product Manager.

About Vivek Karna

Vivek is part of the product team at Razorpay and is currently building RazorpayX, which is the neo banking platform that Razorpay is building from ground up. He has 11+ years of work experience, out of which 7+ years have been in product development. He has been majorly involved in building products in fintech space. Vivek is an avid reader, meditator and loves trekking. Vivek has trekked to Mount Everest Base Camp and dreams of scaling Mount Everest one day !

---

More About The Product Mentor

The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

• Conducting regular 1-on-1 mentor-mentee chats
• Sharing experiences with the larger Product community
• Participating in live-streamed product management lessons and Q&A
• Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy