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).

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.

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

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.

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.

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.

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.

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.

Related posts:

Since the invention of the wheel, we have seen many creations change the world we live in today. And plenty of them successfully became part of our daily lives. But some inventions are questionable…

Isaiah is a Media and Communications professional. His interest span from leadership, personal branding, public relations, youth development, governance and more.

Why Is SEO Essential For An ECommerce Business? With techniques such as link building, bookmarking, content optimization, and mor