Different Elements of Product Management
Product management has seen a lot of takers in the past few years. This field is so varied and versatile that putting bounds on it is a daunting task. Nevertheless, based on my experience and knowledge gained from the circles of product community, I have listed different fundamental elements of product management.
This also means if you are an aspiring product manager, following are the areas in which you would need to hone your skills, as you dig deep into this career. If you are a practicing PM, you might feel some of these are already your strengths, while others are areas of opportunity.
These are listed in no particular order, and I believe all of them are equally important for ensuring a PM is making the right decisions while building a world-class product:
- Product discovery
- Product analytics
- Product development
- Product roadmap
- Project management
- Stakeholder management
- Pricing and revenue modelling
1. Product discovery
This is the area of product management in which PMs are expected to figure out what should be built. Product discovery is also considered to be idea generation by many people, but ideas are not really generated; they are synthesized and mostly aggregated from different teams, stakeholders, customers, etc.
Following are the crucial activities performed under product discovery.
a. User research/user study
For understanding what your users want, you need to be as close to them as you can be. User research or user study is exactly what you can guess from its name. We basically arrange for the users to be present in a comfortable space; ask them to use the prototype or the existing product; then we either silently observe or ask them questions about their experience, as they use the product.
There are many guidelines around how this should be done, so you get real insights from such sessions and not just validation of what you already hypothesized.
b. Market sizing
Most people believe this is useful only when we are planning to launch a new product and not when improving an existing product. I believe that is not the case. Market sizing is nothing but the process of guesstimating the maximum revenues the product can earn for the company.
Extending this definition, when we are analyzing the value of a new feature, we try to gauge how many users would be affected by this feature (for making it time-bound, say in a year of launch) and how much the revenues would increase because of the change in users’ behavior. The analysis done should be as close to reality as possible.
c. Business case presentation
Your findings about a potential solution to the problem you are trying to solve (by the above-mentioned approaches) would need to be presented to stakeholders, management leadership, etc. As a PM, one needs to have the ability to properly build the business case and present the findings. All the effort that has gone in to ideating the solution needs to be neatly presented as a business case.
2. Product analytics
a. KPIs and metrics
KPI stands for key performance indicator, and metric means something that is a quantifiable measure. As a PM, you would need to know the fundamental KPIs and metrics of the product or product area in which you would work. Some examples follow:
- Conversion rate: This is the rate at which users on your platform convert. The definition of convert can vary in each product. For example, in Evernote, conversion may mean a free user becoming a paying user (of any plan). So, conversion rate potentially can be defined here as number of registered users becoming paying users in 30 days of registration. You would be monitoring the KPIs at different time intervals; in this case, we considered 30 days.
- Retention rate: As the word indicates, retention rate is the rate at which users are retained on your platform. This is, perhaps, one of the most important metrics in any product. Let’s look at an example for clarity:
D30 Retention = (number of users still active on your product after 30 days of their first experience of the product /number of users coming to the product for the first time)*100.
b. Data analysis
Data analysis is a key skill a PM needs to have. As we discussed about the KPIs and metrics above, just having an understanding and monitoring of these is not enough. As a PM, you should have the skills of using data platforms, such as MixPanel, Firebase Analytics, Amplitude, etc., and you should also have basic querying skills (SQL, etc.).
Whenever you are validating a hypothesis (an assumption that, if proved, can be tested and eventually converted into a product feature), you need to look at how many users are being affected and what is an average user’s behavior (with respect to your hypothesis).
This would also help you figure out how much revenue a feature can bring in for the company. This is especially important now, because all the product companies track and gather a lot of data, which is a storehouse of knowledge about users, their usage patterns, etc.
c. A/B testing and experimentation
As a PM, you would be constantly improving your product. The way you do this is by running experiments. This is what it would look like:
- Build a hypothesis: You would build a hypothesis to be tested. A hypothesis is nothing more than a proposed explanation of some user behavior that can be leveraged.
- Test and validate the hypothesis: Being sure the hypothesis is correct is called validating the hypothesis. You do that by making minor changes in the product and releasing it to the users.
- A/B testing: When you are testing a hypothesis, you would not make the proposed change available to all users. You would, rather, split the users, so you can see if there is any difference in users who were exposed to this change vs. users who were not exposed. This is why A/B testing plays a crucial role in validating the hypothesis and concluding the experiment (proposed change made in product).
In this way, a PM is constantly creating hypotheses, testing them, then building them into features for further optimization of the product.
d. Data science basics
Having an understanding of data science certainly comes in handy, but we cannot say it is a must-have for all the product roles. If your product collects a lot of data, and you already have an established data science team, then certainly, having a basic understanding of data science concepts would help.
Whenever a data science team creates a data model that is useful and generates some crucial insights about users, as a PM, you should be able to understand that, and create a product feature that would use such a data model.
3. Product development
While actual product development is not done by PMs, the PM is expected to have some knowledge in each area of product development. This is so the PM can provide input, if required, and can prioritize and make decisions that keep users in mind.
a. Technical skills
Regardless of whether you would be working as a digital product manager or a hardware product manager, having some understanding of the base technology being used in the product you are managing goes a long way. This is because you would constantly be working with the engineers.
So if you have technical skills, you would be able to understand and appreciate the challenges engineers go through in building the product. This would also help you gain the respect of the technical team, which is pivotal, since a PM can only lead by influence and not by authority.
Having technical expertise also helps you prioritize better. This can become a must-have, depending on the product you are managing. For example, if you are a PM of a product that consists of APIs to be used by other developers (developers are your customers), then it is crucial you understand APIs, so you can have a better role to play in the product feature decisions, and you can understand what issues and challenges your customers (in this case, developers) are going to face.
In the case of digital product management, basic information about the latest technologies and a high-level understanding of how different systems interact together to bring your product to life for your customers is a good start.
b. Product design
Product design is a vast field, but as a PM, you are not expected to know all the details. There are two significant areas of product design you need to know as a PM:
- UX (user experience): UX is how your customers interact with your product. In the case of digital products (apps, websites), how the interactions between the app and the user are happening, how many steps a user has to take to get something done, how easy or difficult it is to find something or navigate somewhere in the app. All these crucial anecdotes are built and improved on in UX. As a PM, you need to put yourself in the customer’s shoes, and figure out if you find any difficulties using the product.
- UI (user interface): User interface is the the actual interface (with buttons, colors, sliders, etc.) with which the user interacts while using your product. This is easily confused with UX. In UX, we decide interactions, such as if it should be an animation on the same page, or if it should be a new page in itself. Once the decisions on UX have been made, the UI team adds the actual interfaces, i.e., the actual colors, the actual animations, buttons, sliders and text boxes with which the user is going to interact.
As a PM, you should be able to appreciate and distinguish between good UX/UI and bad UX/UI. The easiest starting point is to use as many different products (preferably in the same industry as yours) as you can, and try to understand the pros and cons of each product’s UI/UX.
c. Product specifications
Product specifications is an area of product management in which PMs, potentially, spend quite a lot of time. Product specifications is the document that includes each and every piece of information about the product to be built. This is the document various teams, such as engineers, quality analysts, etc., refer to in order to to understand, in detail, what needs to be built and how it is going to interact with various other systems that are already present.
The format of a product specifications document varies from company to company, but at a high level, following are the headers to be covered in a product specifications document:
- Feature introduction
- Objective and context
- Systems affected
- Metrics to measure
- UX, UI and other assets
- Epics and user stories with priorities
- Tracking and reports requirements
- AB test plan/release plan
- Post-launch analysis plan
d. Product tracking and reports
While, technically, product tracking and reporting requirements are covered in product specifications in detail, I have still considered this a separate point, because it is that important.
Every product that gets built is supposed to be data-driven. We must gather as much information about the users of our product as we can, so we can use that data to figure out how to improve our product even more.
Product tracking consists of all the minute data points we would like to track in the feature being built. Product reports are all the reports you, as a PM (or anyone else who needs to understand the usage of a particular feature), would require to understand where, exactly, the user is finding it difficult to use your feature, or if your feature is being used for use cases of which you are not even aware.
All the funnel reports, interaction reports, impact on revenue, etc., need to be looked into, once the product feature goes live. So, reporting requirements consist of all those report formats.
4. Product roadmap
Product roadmap is a crucial artifact for your product, because it includes the details of the high-level plan of what would be worked on and what features are planned to be built in the foreseeable future (say six months, one year, etc.). Again, similar to product specifications, there is no uniform format of a product roadmap.
Following are some of the useful pointers from the book, Product Management in Practice by Matt LeMay:
- Roadmaps are strategic communication documents, not actual plans for what we will execute and when.
- Roadmaps should be open and shared for company-wide discussions about what is being built, for whom and why.
- There is always a need to explain what to expect from a roadmap, reflect on it, and explain how and why we are using a roadmap.
a. Product prioritization frameworks
In the process of creating a product roadmap, one of the vital decisions to be made is around prioritizing, or which product features should be built when. Prioritization, in itself, is a very challenging process, and it is more art than science.
In each product organization, prioritization is done in a different way. This depends a lot on the kind of product organization it is — whether it is engineering-driven, design-driven, data-driven or sales-driven. Sachin Rekhi has explained this in detail here.
Following are some of the product prioritization frameworks you should know. You can choose to use any of these, depending on your product org’s needs.
- RICE Framework by Intercom
- MoSCoW Method by Dai Clegg
- AARRR Metrics by Dave McClure
- HEART framework by Google
- KANO Model by Noriaki Kano
5. Project management
Project management is not, essentially, an area a PM has to completely own, but honing your skills for project management is going to be crucial for success as a product manager.
Project management is the practice of initiating, planning, executing, controlling and closing the work of a team to achieve specific goals in a specific time period.
Since a PM is expected to own the product feature end to end, some project management skills enable a PM to be able to plan the feature across different stakeholder teams in a better way, identify any risks in any of the deliverables, and work backward to achieve a potential release date. There are many tools and practices already available that you can use, and even a simple Google sheet can get the job done.
a. Self management
This is, perhaps, a less discussed area of product management, but in my opinion, it is still a crucial one. Since we now know the different areas in which PM is supposed to play a pivotal role, it is extremely important that you are able to always align your priorities and work on the most important things at hand.
It is quite easy to get lost in the sea of communications, emails, notifications, etc., a PM would go through while navigating various phases of the product development life cycle across all the different stakeholder teams in the company. Hence, a PM needs to know how to mange himself or herself, align all the priorities and still have time to do critical thinking required to be a problem solver.
At the end of the day, a PM needs to be good at identifying the problems in the product and solving for them.
b. Time management
Time management goes with self management. This is extremely important. Time management is a skill that would go a long way for any professional, not just product managers.
aTimeLogger is one of the tools I use to manage my time better. It is explained in detail here.
6. Stakeholder management
A PM needs to communicate across all the different teams, including engineering, product design, marketing, retention, acquisition, program management, operations, business intelligence, senior leadership, etc. A PM has no authority whatsoever over any of the team members on these teams.
Hence, it is crucial to know the skill of stakeholder management, so a PM can lead by influence and ensure the product being built has the customer’s needs at the very core.
Following are some anecdotes of which one needs to be mindful:
- A PM can’t succeed if there is no clarity among senior leadership about a company’s strategy and vision. In such a scenario, a PM should try to assist in creating the goals together.
- A PM needs to have the skill to push back and have challenging conversations with the stakeholders, assisted by customer advocacy and prior product knowledge.
- If you get directions from stakeholders that don’t make sense, ask them why that is, then explain the trade-offs and the downstream implications.
- When communicating with engineering (and other teams), always walk them through why such decisions were made. Providing transparency goes a long way in ensuring the teams have shared ownership.
- Whenever it comes to decision-making with stakeholders, it is better to walk them through individually and get buy in, rather than introduce this for the first time in a group setting. (This might not be true in each product organization; it depends a lot on the company culture.)
- When communicating with stakeholders, a PM always has to advocate for customers’ needs over and above stakeholders’ requirements.
7. Pricing, monetization and revenue modeling
As a PM, you may or may not be involved directly in pricing, monetization and revenue modeling. It depends on how the product organization is structured and to whom it reports, but it is still crucial to be aware of these skills.
The terms are really self-explanatory, and as a PM, you are expected to understand business really well. You must know the various revenue sources your product currently has and how you can contribute to improve them. In a way, revenue is the primary goal you are trying to achieve by building product features.
I hope this article achieved its goal of making you familiar with all the different elements of product management. There are a plethora of skills a PM is expected to have, but I believe this is what makes this profession interesting. Also, this is one of the reasons product managers come from varied backgrounds — engineering, design, marketing, business analysis, etc.
Every PM has a few core skills that have been acquired in their previous career, then all the other skills are learned on the job (and by self education) while progressing through the product leadership roadmap.
About the author: I’m Ayush Jain. In this blog, I write about my learnings as a product manager.
If you liked this article, you might also like. . .
