Product management has seen a lot of takers in the last few years. This field is so varied and versatile that putting bounds to it is a daunting task. Nevertheless, based on my experience and knowledge gained from the circles of product community; I have listed down 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. Lastly, these are listed in no particular order and I believe all of these are equally important for ensuring that a PM is making beneficial decisions while building a world class product. Product Discovery Product Analytics Product Development Product Roadmap Project Management Stakeholder Management Pricing and Revenue Modelling source 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 synthesised and mostly aggregated from different teams, stakeholders, customers etc. Following are the crucial activities performed under Product Discovery. (i) User Research / User Study: For understanding what your users want, you need to be as close to the users 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 and 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 that you get real insights from such sessions and not just validation of what you already hypothesised, but we should perhaps discuss that in some other post. (ii) 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 how much maximum revenues can the product earn for the company. With extension of this definition, when we are analysing the value of a new feature, we try to gauge how many users would be impacted with this feature (for making it time bound, say in an year of launch) and how much would the revenues increase because of the change in users’ behaviour. The analysis done should be as much close to reality as it can be. (iii) Business Case Presentation: Whatever have been 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. So, 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 ideating the solution needs to be neatly presented as a business case. 2. Product Analytics (i) KPIs and Metrics: KPI stands for Key Performance Indicators 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 that you would work in. Some examples are as follows. We can do a separate blog only focused on fundamental metrics, if required. : The rate at which users on your platform convert. The definition of convert can vary in each product. For example, in Evernote, conversion perhaps can 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. As you can see, you would be monitoring the KPIs at different time intervals, in this case we considered 30 days. Conversion Rate As the word indicates, retention rate is the rate at which users are retaining on your platform. This is perhaps one of the most important metric in any product. Retention Rate: 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 Let’s look at an example for clarity: (ii) Data Analysis: Data analysis is a key skill that a PM needs to have. As we discussed about the KPIs and Metrics above, just having an understanding and monitoring of those is not enough. As a PM you should have the skills of using the data platforms such as MixPanel, Firebase Analytics, Amplitude etc. and should also have basic querying skills (SQL etc.). Whenever you would be validating a hypothesis (an assumption which if proven, can be tested and eventually converted into a product feature); you would need to look at how many users are getting impacted, what is an average user’s behaviour (w.r.t your hypothesis). This would also help you figure out how much would be the revenue that 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 pattern etc. (iii) A/B Testing and Experimentation: As a PM you would constantly be improving your product. The way you do this is by running experiments. This is how that would look. : You would build a hypothesis to be tested. Hypothesis is nothing but a proposed explanation of some user behaviour which can be leveraged. 1. Build a Hypothesis : Being sure that 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. 2. Test and Validate the Hypothesis : This is where A/B testing comes in, when you are testing a hypothesis you would not make the proposed change available to all the users. You would rather split the users so that you can see if there is any difference in users who were exposed to this change versus users who were not exposed. This is why A/B Testing plays a crucial role in validating the hypothesis and concluding the experiment (proposed made change in product). 3. A/B Testing In this way, a PM is constantly creating hypothesis, testing them and then building them into features for further optimisation of the product. (iv) Data Science Basics: Having an understanding of data science certainly comes handy but we cannot say that 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 basic understanding of data science concepts would help. Whenever Data Science team creates a data model which is useful and generates some crucial insights about users, as a PM you should be able to understand that and should be able to create a product feature that would be using such a data model. 3. Product Development Actual product development of course is not done by PMs but in each area of product development PM is expected to have some knowledge so that PM can provide the input if required and can prioritise and take decisions as and when required keeping the users in mind. (i) Technical Skills: Irrespective 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 the engineers go through in building the product. This would also help you gain 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 prioritise better. This can / cannot become a must have depending on the product that you are managing. For example, if you are a PM of a product which consists of APIs to be used by other developers (developers are your customers) then it is crucial that you understand APIs so you can have a better role to play in the product features decisions and you can understand what issues and challenges your customers (in this case developers) are going to face. To begin with, in case of Digital Product Management, basic information about 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. (ii) 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 which you need to know as a PM. : UX is how your customers interact with your product. In case of digital products (apps, websites) how are the interactions between the app and the user 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 of these crucial anecdotes are built and improved upon in UX. As a PM you need to put yourself in the customer’s shoes and figure out if you find any difficulties in using the product. 1. UX (User Experience) User Interface is the the actual interface (with buttons, colors, sliders etc.) that the user interacts with while using your product. This is easily confused with UX. In UX we decide the interactions such, as should it be an animation on the same page or it should be a new page in itself, while in UI, 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, text boxes with which the user is going to interact with. 2. UI (User Interface): 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. (iii) 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 entails each and every information about the product to be built. This is the document that various teams such as engineers, quality analysts etc. refer to; to understand in detail as to what needs to be built and how it is going to interact with various other systems which are already present. The format of a product specifications document really 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 Impacted 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 (iv) Product Tracking and Reports: While technically product tracking and reporting requirements are covered in product specifications in detail; I have still considered this as a separate pointer because it is that important. In today’s world every product that gets build is supposed to be data driven. We must gather as much information about the users using our product as we can so that we can use that data to figure out how to improve our product even more. Product tracking consists of all the minute data points that we would like to track in the feature being built. Product reports are all the reports that 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 you are not even aware of. All the funnel reports, interaction reports, impact on revenue etc. needs to be looked into once the product feature goes live. So, reporting requirements consists of all those report formats. 4. Product Roadmap Product roadmap is a crucial artefact for your product because it entails the details of high level plan of what all would be worked upon, what all features are planned to be built in the next foreseeable future (say 6 months, 1 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, by Matt LeMay. Product Management in Practice , Roadmaps are strategic communication document and not an actual plan for what we will execute and when.Roadmap 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, retrospect on it and explain how and why we are using a roadmap. (i) Product Prioritisation Frameworks: In the process of creating a product roadmap, once of the vital decisions to be taken is around prioritising; which product features should be built when. Prioritisation in itself is a very challenging process and it is more art than science. In each product organisation prioritisation is done in a different way and this depends a lot on the kind of product organisation 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 that you should know and you can choose to use any of these depending on your product org’s needs. product prioritisation frameworks 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 that a PM has to completely own but honing your skills for project management is going to be crucial to be successful 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 enables 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 backwards to achieve a potential release date. There are multitude of tools and practices already available that you can use and even a simple google sheets can get the job done. (i) Self Management: This is perhaps a lesser discussed area of Product Management albeit IMO is still a crucial one. Since, now we 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. that a PM would go through while navigating through various phases of product development lifecycle across all the different stakeholder teams in the company. Hence, a PM needs to know how to mange oneself, align all the priorities and still have time to do critical thinking that is 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 solve for them. (ii) Time Management: Time management goes in sync with self management. We have mentioned this explicitly just because this is extremely important. Time management is a skill that would go a long way for any professional and not just product managers. aTimeLogger is one of the tools I use to many my time better, have explained it in . detail here 6. Stakeholders Management A PM needs to communicate across all the different teams such as engineering, product design, marketing, retention, acquisition, program management, operations, business intelligence, senior leadership etc. Also, a PM has no authority whatsoever on any of the team members in these teams. Hence, it is crucial to know the skill of stakeholder management so that a PM can lead by influence and ensure that the product being built has the customers’ needs at the very core. Following are some of the anecdotes one needs to be mindful of. A PM can’t succeed if there is no clarity among senior leadership about company’s strategy and vision. In such a scenario, a PM should try and assist in creating the goals together. A PM needs to have the skill to push back and have challenging conversations with the stakeholders assisted with customer advocacy and prior product knowledge. If you get directions from stakeholders which don’t make sense, explain to them why is that, explain the trade offs at play and the downstream implications of it. When communicating with engineering (and other teams) always walk them through about why such decisions were made. Providing transparency goes a long way in ensuring that the teams have a shared ownership. Whenever it comes to decision making with stakeholders it is better to walk them through individually and get a buy in; rather than introduce this for the first time in a group setting. (This might not be true in each product organisation, depends a lot on the company culture as well.) When communicating with stakeholders, a PM always has to advocate customers’ needs over and above stakeholders’ requirements. 7. Pricing, Monetisation and Revenue Modelling As a PM you may or may not be involved directly in pricing, monetisation and revenue modelling; depending on how the product organisation is structured and to whom does it report but it is still crucial to know that these skills are also that a PM should be aware of. The terms are really self explanatory and as a PM you are expected to understand business really well and hence must know the various revenue sources that your product currently has and how you can contribute to improve those. In a way, revenue is the primary goal that you are trying to achieve by building product features also. Conclusion There are a plethora of skills that a PM is expected to have but I believe this is what makes this profession interesting. Also, this is one of the reasons why product managers come from varied backgrounds — engineering, design, marketing, business anlaysis etc. Every PM mostly has a few core skills that have been acquired in their previous career and then all the other skills are learnt on the job (and by self education) while progressing through their product leadership roadmap. Hope this article achieved its goal of making you familiar with all the different elements of effective product management .

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Scoping Out The Elements Involved In Effective Product Management

Too Long; Didn't Read

Ayush Jain

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Scoping Out The Elements Involved In Effective Product Management

Too Long; Didn't Read

Ayush Jain

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES