5 more learnings from a Product Manager
Product management is about steering. Engineers, data scientists, designers, and QAs make up the strong crew that operate the ship of the product.
However, without precise steering, it will float without a direction, risking to never reach its final destination. A Product Manager is a captain, who navigates through undiscovered waters in search of hidden treasures — the next El Dorado. On peaceful days, the captain steers using maps and compass. During wartime, a good captain adds own experience and intuition. The same is true for a Product Manager. Quantitative and qualitative data help us in our everyday decision making, but it certainly takes more than that when it’s time to tap into uncovered market opportunities and being the first to come.
In my last article, which is the first part of this article, I went through 5 learnings I gained while working as a Product Manager at PicsArt Inc. Here I continue the list with 5 more learnings. All of them are based on my experience as well as some books read (such as The Lean Startup, Hooked, Blitzscaling, Positioning).
#1 Stories help to prioritize features
While designing a new product we often jump right into defining its features. After estimating execution times, we get a scope of several months. To minimize this scope, we need to define the scope of the MVP that will validate the leap of fate assumption behind the product. Usually, this assumption states that new functionality should be able to do a certain job for the user and do it well. After successful validation, we invest more time in adding all the missing features and delivering the fully-fledged functionality.
But what is the force that pushes us to include more features in the MVP? One of the reasons is that we often think from the perspective of the existing alternative products and their features. What we need to do instead is to find real stories of users, understand why are they choosing to hire our product for a certain job and make that product do its job the best.
“I drive to the gym every morning and, because I get bored, I buy milkshake from a shop to drink it while diving.”
While doing user research, this is what a milkshake company discovered. They wanted to improve milkshake sales and needed ques from users for improvement. One of the research contestants told them “I once tried to buy a banana instead of milkshake, but I soon realized it didn’t do the job well because it ended too soon and I needed something that would last long enough for me to complete the commute”. Other participants told how the milkshake wouldn’t spill inside the car while hitting road bumps. So based on this story the milkshake company made improvements to the product and made it denser which caused sales to skyrocket. Top to bottom thinking approach helps a lot. Here is another example from a PicsArt user.
“I use PicsArt to Square Fit my images into Passepartout style so that my Instagram profile looks consistent and stylish.”
When viewing from a features point of view we need a tool that allows putting the image on a blank canvas and ability to use drag and pinch to zoom for precise placement of the image. But if we try to start from the user story, we will discover much more. For example, we could add presets inside the Square Fit tool to make repetitive use cases easier. And this feature would allow positioning PicsArt’s Square Fit tool as the most convenient for frequent usage.
#2 Avoid vanity metrics
In 1999 NASA lost a $125 million Mars orbiter because Lockhead Martin engineering team used Imperial units of measurement while the agency’s team used the more conventional Metric system for key spacecraft operation. If making wrong measurements led to such loss imagine how dreadful it would be to measure the wrong metrics. It is important to define which metrics to measure after the product goes live. These metrics must objectively represent success or failure.
Unfortunately, many companies pay little attention to defining high-level metrics. Such metrics can range from single most valuable metric that defines the success of the company — revenue, to more proxy metrics such as Daily Active Users, Number of Daily Core Actions (for Uber that would be number of daily rides completed) or feature retention (for Audible that could be retention on Wishlist feature). Positive changes in lower level proxy metrics should eventually affect higher-level company metrics to make sense.
After defining these metrics, a company can set a yearly goal on the main high-level metric and Product Managers can derive proxy metrics related to their part of the product. An increase in these metrics should eventually lead to an increase in the high-level one. As Product Managers, we should keep our eye on which proxy metrics to choose and which to avoid. It seems every team is inclined to believe that effort equals success. If the team invests 2 months on a project, then it should turn out to be successful.
To bake these assumptions and keep the team spirit high many Product Managers fall into the trap of measuring vanity metrics that misinterpret the real influence of the product. To better understand vanity metrics, we will go through some types of metrics and methods to drive them. We will evaluate which of those metrics are harder to drive. Let’s assume we have an app. Some metrics we can use to measure success are
- Daily New Installs — this metric shows the number of daily new customers, so it represents Growth. It can be driven via seasonality, trends, SEO, ASO and most importantly with Paid User Acquisition. In other words, we can spend money to buy users and drive the Daily New Installs metric. But if Customer Aquisition Cost is higher than Customer Lifetime Value we will be losing money. Some executives might just overspend investment money by the end of the quarter to show good quarterly results to investors. But such an approach will not lead to a sustainable business. Summarizing, we can say that Daily New Installs is an easy-to-drive metric. So when is it a vanity metric to choose? For the marketing team doing the Paid UA Daily New Installs is not a Vanity metric as it shows the performance of the Ads shown to the user. But for a new feature that is being released parallel to the beginning of the Paid UA campaign Daily New Installs will be a vanity metric as it is artificially increased.
- Funnel Conversion — After new users install your app, they need to pass through a funnel of steps required to perform the core action. Core action leads to a reward for the user or in other words, gets the job done. In the example of Uber new user opening the app should register in Uber by filling out personal data, set location for the taxi on the map, request it, wait until the taxi comes, locate it and enter, reach the final destination and pay money. All these steps compose a funnel for the new user needed to complete to achieve the reward — getting to the desired location. On each step, some of the users will be lost. Many of them might be confused filling out personal information while signing up. Eventually, on each step, we will lose some X percent of initial users and only Y percent will reach the reward or otherwise said convert through the funnel. So what are some methods to drive Y higher? We can do redesigns and simplify the registration flow by auto-filling users’ personal information from smartphone cookies.
Better UX leads to better conversions. In terms of vanity metrics, let’s discuss 2 scenarios
Example 1: We redesign the user registration flow and release it on December 1. In this case, the number of Daily Registrations will be a vanity metric. December is a high season and will attract more than usual users to the app. In such a case, even if the redesign does little to no change to the user experience, in absolute numbers we will see an increase in Daily Registrations. Conversion, on the other hand, would be an objective metric to use.
Example 2: We redesign registration flow and remove the step where we ask the user to choose 4 topics that interest them. As a result the registration funnel conversion raises to 10%. In this case, Funnel Conversion is a vanity metric. It is clear, that removing the interest step will increase the funnel conversion. But, what we lose is the opportunity to understand user interests better and to suggest personalized experience throughout the app. For this reason, many users can churn and retention can go down resulting in worse high-level metrics than before.
- Retention — shows how frequent is the job to be done and how well does the app perform it. Users confused by complex UX will churn and not use the app anymore. Users who don’t get their job done with the app will churn as well. Improving retention is a tough job. Pouring money in marketing or doing UI/UX changes rarely affects it. In this way, retention is tough to improve. From the vanity metric stand of view, some features shouldn’t have high retention. For example, if the retention on the Undo action is raising it means users are doing more mistakes while using the app, which might be caused by new complicated UX. We should also consider the nature of user needs and choose the right timeframe for retention. For an app that is used 2–3 times a month Daily Retention will show no changes.
- Daily payments — As the proverb goes: “All roads lead to Rome”. To achieve the company mission, growth is required. To fuel this growth company needs a steady increase in the revenue stream. We can do Paid User Acquisition and increase New Users, we can redesign the UX to make it as simple as possible, we can build addictive features that customers use every day, but what many products fail to do is to create value that will make users pay real money for. During the Dot Net boom, there were many websites attracting millions of users, but there was no practical interest from advertisers and thus the bubble burst. Daily payments is the hardest metric to move. From this perspective, we could think that Daily payments is the pinnacle of all metrics and can never be a vanity metric. But even this can be false. Imagine an app trying to trick users in paying money with the new UX. In the short term, this change should boost daily payments, but in the long run, this can heavily affect the product reputation and trust among users that, on its turn, can cause severe damage to the Brand and the company. In such a case one should also measure the number of complaints from users who accidentally pay to understand the line between flawless payment flow and tricking users to pay.
As Product Managers, it is our role to keep our minds sober and choose the most effective metrics when measuring the success or failure of a project. For the top management, it is their important role in embracing learning culture inside the company to minimize risks of anyone using vanity metrics.
#3 Know your data
Morning coffee with a 10-minute glance at your data is a good habit. You are fast to react to opportunities and errors. To get fueled with data in the everyday decision-making process we need our data to be in place, be correct and on time. Setting this up can be a complex and time-consuming process, but it is worth it. If we want to base on objective facts we need numbers. To get them we need to set up analytics flow to receive the data. There are many free tools like Google or Facebook Analytics that are super easy to start with and give many basic insights that are enough for early-stage products. There is a trap though. Bugs left in code, causing false analytics, can lead to steering the product ship blindly. So my advice — set the priority of analytics related bugs to critical by default. Other difficulties arise when misinterpreting the data. When given the same task to 3 data scientists there is a high chance to get 3 different reports. To avoid such cases it is really important to constantly train and qualify data scientists inside the company. Another good approach is to have experienced Business Analyst in at least the advisory board of the company.
#4 Delegate and Amplify
Product Management is a relatively young discipline. Ownership and focus of a Product Manager is the product itself. In reality, though, many companies, especially in their early-stage, seek generalist Product Managers who are not afraid of taking more responsibilities on them. You might take the role of a Project Manager, a Scrum Master, etc. based on the situation. Don’t get me wrong, this is not always a bad thing. It gives valuable experience in leadership and people management skills, helps you value scarcity of engineering resource and gives invaluable knowledge that can be used as an entrepreneur in the future. Coming from a software engineering background I saw myself slowly transforming from a Software Developer to a Team Lead to a Product/Project Manager to a Product Manager.
One important skill needed during this journey was delegation. An important lesson I learned from a college of mine is that delegation feels bad because you know that the assigned employee will perform the task worse than you do. The key important thing to understand here is that we need to be OK with the fact that delegation will cause lower quality or slower execution of the task, but in the short term only.
In the long term, by giving time and ownership to the right person, you will see how they excel in that job and more importantly you will have more time to concentrate on your own tasks. Delegation is a good technique to have an efficient team. However, if you want to have an extraordinary team delegation is not enough. The assignee should not only perform but also amplify. What this means is that we need to give the ability and the ownership to newer employees to not only perform existing tasks we delegate to them but to innovate the process, learn new things, bring all of that to the company and thus amplify the results for the whole team. By giving ownership and needed framework to the right people, we grow the next generation of leaders needed to scale the team and the company.
#5 Use your product constantly
We don’t build the product for ourselves. Yes, we might find pride and joy in building and using the product, but our job is to be the user ambassador and build a product they need. In my experience, I have seen different kinds of relationships between the product and the Product Manager, but every time I see a great product there is a Product Manager who actually uses the product. This certainly relates more to consumer products as I have little experience with B2B products.
Try using your product every day. Find use cases that interest you. In my case, I and other PMs created a Close Friend group on Instagram and started posting videos created with the PicsArt app. It made using the app for personal use cases entertaining process. During that process, I noticed many missing features, friction points, and bugs I didn’t see before and it helped me to better interpret user requests and comments.
Steering a ship requires skills and experience. The more we learn, the more we crave to learn. Product Manager is the Captain that steers product ship through undiscovered waters, tapping into new markets and opportunities, failing and learning, trying and experimenting until the perfect product is created, which in fact will never happen.
