Product Management 101
Tech products have subsumed our lives to such an extent that we have become heavily reliant on our devices and apps/websites for most of our needs. The process of building products (product management) and the people who lead this effort (Product Managers) have thus grown to become highly valued commodities in today’s world.
For people wanting to understand product management, this post provides a brief introduction.
What is product management?
In simple terms, product management is about managing the different aspects of a product.
Product can mean anything from a feature on the app to entire software or even hardware.
The different aspects encompass the planning, designing, development, launch, marketing, sales and the financials of the product.
And managing is about taking full responsibility for the product and doing whatever it takes to make it successful.
The interesting thing is that a PM is expected to get all this done but doesn't usually have direct authority over anything or anyone.
Roles of a Product Manager
Let's do a walkthrough of how products are built and what role does the PM play at each step. This process might differ from organisation to organisation basis their size, scale and style of working, however, the following example can serve as a good illustration for the same.
Supposing that you're a PM at WhatsApp and you look after the Chat feature. We'll take the building of the 'swipe right to reply to a message' feature as an example to go through the process.
Phase 1: Ideation and Planning
You're engrossed in a serious WhatsApp chat with a friend that is changing context rapidly. By the time you reply to a question, your friend has posed three more questions. The replies lose track of the questions and there is commotion all around. You then spend some time clearing the air. The pre-'swipe right to reply to a message' era was difficult.
As a PM, you come across this pain-point and decide to address it. The source of such user problems can be anything—your own experience, Play Store reviews, conversation with a friend, user interviews etc. You then work on a pitch for the senior leadership. This group usually consists of the Product leaders (such as VPs, SVPs, CTO) but can also include the other concerned stakeholders and C-suite members. The pitch broadly consists of the following:
- Objective What will this change achieve? How does this align with the broader product/company roadmap?
- Data backed reasoning for the introduction of the feature - Product development doesn't work on whims. You need to have solid analytical backing. At times, data will be giving you this sense quite clearly. For example, if you remove a redundant screen and reduce the number of clicks in the check-out flow of an e-commerce website, the median check-out time will reduce and the conversions will increase. This can be modelled and estimated. But there'll also be situations where quantifying the impact would be difficult at the onset. We design experiments in such cases to collect data and validate our hypotheses. A minimum viable product is released to test for its usefulness and it is iteratively improved. Our change falls in this category because although we intuitively know that this will make life easier, we need to validate it with data before making it live for billions of users.
- Team dependencies, time and effort requirement estimation - Which organisational functions will need to be involved? How much time, manpower and effort will each team require to put in to launch the feature?
- Basic mockups or wireframes to illustrate your idea - This section needs to have a rough diagram of the user flows and how will the feature be structured on the tech stack. The mockups and wireframes will assist you in clearly presenting your ideas. draw.io, Figma and Balsamiq can be used for designing these.
Once this presentation is done and the necessary approvals are obtained, the work on the actual product starts.
Phase 2: Design, Development & Testing
The PM now collaborates with the Design and User Experience teams to come up with various use cases/conditions of the feature. Post this, the designs are developed. We now have a perfect sense of how the feature will look and work.
While more thinking goes into the idea, the pitch document is made exhaustive and converted into a Product Requirement Document (PRD). The PRD is the reference guide for everyone working on the product. It is a self-serving document with all the relevant details of the product.
Apart from the items already mentioned in the previous section, the designs are now added to the PRD.
The PM also needs to come up with a detailed plan for tracking the analytics at this stage. What signals need to be measured and at which points? How will this data be stored? What will constitute success? This is also added to the PRD.
As the ideas have crystallised now, there is clarity over what needs to be built. The tech team is now ready to be involved. A meeting with the tech leaders is organised by the PM to decide on the technologies to use, integrations with the existing infrastructure/building new capabilities and for coming up with a timeline.
The developers then get to the coding job. The role of the PM now becomes that of a facilitator. They help the developers with any doubts that may have and form a communication link between teams in case some implementation challenges arise.
Once the feature is built, it needs to go through multiple rounds of testing to ensure that there are no bugs and it is working as desired. Big organisations usually have a Quality Assurance team that writes test cases and performs this task. At startups, the developers, designers and the PM might team up to do the testing themselves.
Phase 3: Marketing, Launch & Evaluation
After the testing is done, the product is ready for launch. The next step is to plan for the launch. The PM needs to work with the Marketing & PR teams to come up with a strategy to market the product. There can be social media campaigns, email marketing or inside the app marketing using banners/blogs or dedicated pages such as this.
In our case since we are testing the hypothesis that the 'swipe right to reply feature' would enhance the user experience, we need to control the launch of our product, collect some data and then make a decision on its rollout. There are different mechanisms for doing this (A/B testing being quite popular).
A good way to test our feature can be a Beta rollout. Beta is a small group of registered users who receive updates before everyone else does. The data collected from them and their feedback form the backbone of the subsequent product decisions. As a PM you can work with your Analytics/Data Science teams to come up with a predictive data point that can help you ascertain the success of the feature. For example, let's assume that we come up with the following metric for measuring the performance — if the median number of messages that are swiped right for replying in a day is > 50% of the total messages in group chats and is > 30% of the total messages in personal chats, the feature is successful.
The next step is data collection and asking the Beta users for feedback. The usage by real users might uncover bugs which then need to be resolved. After examining the data, fixing the bugs and speaking with users, if everything is in favour, the call to release the feature to the entire population is taken and the same is pushed through an app update release.
While the product has been released, the PM's job doesn't just end here. They need to be on top of the feature in terms of tracking how it is doing, being on the lookout for potential bugs that might hamper user experience and constantly thinking about improving it further. As the owner of the product, anything and everything related to it is now their responsibility.
Have thoughts on this piece? Drop me an email.