A no-nonsense guide on performing the basic duties of a Product Manager
A few years ago when I shifted my career from a Business analyst to a PO/PM, I did not know if the new title would bring in any additional responsibilites or work. I just liked the fancy new designation and went about doing the same work I did before. Little did I know that the PO/PM role was much more than I had imagined (and it still is…)
What I aim to do in this post is to keep it simple and explain what you should be doing (not limited to) if you just landed yourself in a PM/PO role.
#1 Understand the ‘Product’
How can you expect to lead a product if you don’t understand the product ins and out of it!
- Get credentials for sandbox environments and go on a mindless journey of testing the product. A fresh set of eyes always sees the most unnoticed things than the veterans who built it.
- Read the help documents of the product/services — they really help!
- Ask your peers to explain various use cases of who uses the product, why, and how.
#2 Understand the ‘Market’
- Does your product fall in B2B or B2C — Get the answer to this basic question.
- Once you get an answer to question 1, try to find out the market share of your product, market size tapped and untapped in this space.
- Find your competitors and list it down. We will come back to this at a later point of time.
#3 Understand the ‘Product Problems’
There are tons of ways to understand the Product problems. I have broken it down to two mediums — offline and online. Offline mechanism means not interacting with Clients or Partners and using all the other tools or info to understand the issues. Online medium is by interacting with Clients directly and gathering the product shortcomings.
- It is important to list down all the problems you faced while testing the system when you just started out. As mentioned earlier, the fresh set of eyes always notices the unnoticed.
- Get access to ‘Support tickets’ raised by clients. Organize them by features and see which feature is the most problematic. You just did a ‘Quantitative Analysis’ of issues by feature.
- Once the numbers from ‘Support Tickets’ or ‘Client Feedbacks’ tell you the most painful area, dig deeper into analyzing the tickets to see the exact pain point of the customer. This helps you build a hypothesis and a strong case of the problem you want to solve. This, my friend, is a ‘Qualititative Anaysis’ you have performed.
- System Failure Analysis — Your engineering buddies can help you get some stats on how many hits and failures happened in the pages or features. This adds ammo to build your case to enhance, fix, reinvent or even deprecate a feature. Tools like Log Insight, Splunk can also help in this case. This comes under ‘Quantitative Analysis’
- User Analysis — Tools like amplitude, mixpanel, google analytics can help you understand the user journey and provide valuable insights on feature usages, time spent on a page or features, conversions, etc. This analysis can be listed under ‘Quantitative Analysis’
- Interact with Clients — Schedule calls with your Clients and hear their woes of using the product. List it down under ‘Qualitative Analysis’. You can also post surveys to get some feedback!
- Interact with Internal team — Sales, Customer Success, Engineering, Product, Design, Customer/Tech support teams. They would give wonderful insights of customer problems or product shortcomings.
The below point is optional from the world’s eyes, but I like to point it out as I consider it very important to empathize with the engineering teams:
8. Understand the system architecture at a high level — have a basic understanding of how data flows between systems, how it is stored, how the system components behave and interact with each other. A basic understanding of the system and few technical components like an API, middleware, components, etc goes a long way to understand the technical debts of the product and how you can contribute to overcome it in some of your projects.
#4 Understand your ‘Competitors’ and ‘Current Market Trends’
I had mentioned above to note down who all are your competitors. It’s time to use that information.
Most of the companies have demo systems or product videos on their website or youtube. Make sure to consult your legal team when you are trying to sign up for a competitor’s demo systems to see their product.
Do a competitor analysis to see what feature they have and you don’t or which feature of theirs is much better than yours. This gives you a fair idea of what is lacking in your product and why the competitor has an edge.
Also, do not ignore the current market trends. If you are thinking of introducing a new feature, make sure it is not outdated in the market and it is in the current or future market trends.
Never try to copy exactly the same strategy or a feature from your competitor. Drawing inspiration is fine!
#5 Analyse the information from points 1–4 and come up with a ‘Problem Statement’
‘You can lead a horse to water, but you can’t make him drink’
You now have all the information you need to help you get towards understanding the problems of the product. You will need to do a qualitative and/or quantitative analysis to come up with the biggest problem or the easiest problem you want to tackle.
There are many ways to assimilate data and draw meaninful insights from it. You can always google the techniques to do the same!
#6 How to come up with a solution
You can sit inside a closed room and come up with a solution all by your own.
OR…
You can google an already existing solution and try to fit in your problem statement.
OR…
You can follow the ‘Design Sprint’ model to come up with a solution. To know more about design sprint, follow the link — https://uxplanet.org/whats-a-design-sprint-and-why-is-it-important-f7b826651e09
I recommend using the ‘Design Sprint’ but feel free to alter it to your organizations needs to come up with a possible solution. In my personal experience, many brains help to come up with many possibilities in these exercises. Also, the ‘Design Sprint’ is a great way to include your dev team or fellow PM’s and create a very inclusive environment and work as a team together!
#7 Gather Baseline metrics and OKR
The 2 most important things to do before you embark on starting your development activities are:
a) OKR Identification:
OKR stands for ‘Objectives and Key Results’ — This helps to show your bosses or your company how the new product or release or feature has fared.
So how to come up with an OKR? (Credits: https://felipecastro.com/en/okr/what-is-okr/)
Use this formula: I will (Objective) as measured by (this set of Key Results).
The complete example would be:
Objective: Create an Awesome Customer Experience
Key Results:
- Improve Net Promoter Score from X to Y.
- Increase Repurchase Rate from X to Y.
- Maintain Customer Acquisition cost under Y.
If you cannot measure or quantify a key result, do not have it in the list!
b) Baseline metrics:
In the above example, you saw a key result which says — Improve Net Promoter Score from ‘X’ to ‘Y’. The ‘X’ in the statement is the baseline number or the starting point number with which you can compare the future result ‘Y’ to show if it is a percentage increase or decrease.
Always make sure to plan and get your baseline metrics before the execution of the project.
#8 Prioritize Features, Write User Stories and Documentation
Prioritizing a feature:
A simple way to prioritize features is to estimate the cost of building the feature versus the value it delivers. Value can be determined in a number of ways:
a) Reduction of revenue loss or leakage
b) Averting security risk
c) Adhering to compliance
d) The estimated increase in usage, sales, NPS, customer satisfaction score, etc
There are other ways to prioritize features such as MoSCoW (Must have, Should have, Could have, Won’t have), Buy a feature — where everyone in the team is given money (not real one!) and they have to spend on feature they feel are valuable!
You can use any of the methods but always remember that the feature you develop must have an impact and it should be measurable!
User story format:
Now that you have prioritized the feature, it’s time to write the user stories. The user story format should be:
Persona: Who is targetted for this story?
User Story Format: As a user, I want to …<goal>… so that …<reason>…
Example: As a customer I want an ability to create a support ticket on xyz portal so that I can submit my issue and avail resolution.
Description/Summary: Elaborate the user story
Acceptance criteria: Given ‘a condition’, When ‘a user performs some action’, Then ‘the outcome is’.
Example: Given a user has permission to file a support ticket when a user logs in, then he/she should be able to submit the request.
Wireframes/Flow diagram: If required, you can use tools like visio or free tools like draw.io to make flow diagrams, pixlr.com and Figma to make wireframes so that the engineering/ui team can understand the flow better!
#9 Execute and Test
Now that your requirement is written and prioritization is done, it is time for your dev team to execute your vision. During execution your team may have doubts and it is your duty to clear them and provide a clear insight on the feature.
I would also recommend you to test the feature to satisfy your heart and check if the product was build as you had envisioned.
In some organizations, a Product Manager will need to support ‘user acceptance testing’ or ‘client testing’ by providing them sample logins and instructions to test, clarify their doubts and help triage a bug if any!
#10 Product Feature Communication
What good is your feature if you have not publicized it! Use your customer advocacy teams or Product marketing team to inform your customers of the new feature ahead of time and create the hype.
If you do not have a product marketing or a customer advocacy team and the burden falls onto your shoulders, try to make Product demo videos explaining the product, benefits, how to use it, etc.
It is genuinely not difficult to do make a good demo video. All you need to do is use video editor (inbuilt tool in windows)or use snag it a tool to record your screen/presentation and you can overlay your voice narration. The video editor has some fancy features like transition effect and background sounds for a better end result.
Alternatively, you can post the release of a feature on LinkedIn or make a poster/document with screenshots and notes to do the same.
#11 Post-release feedback and metrics
Once your feature is live, it is time to monitor the usage of it and gather the metrics to see how it is faring.
This helps to showcase the usage post-release versus baseline numbers.
It is also important to check the pulse of your customers if they liked the feature or not. This can be done by either sending a short survey post-release or having a feedback form on the portal which pops up and asks you to rate your experience!
A word of caution that every company may have different processes, but the above set of steps helps to serve as generic process guidance!
