Two Years In Product Management: What I’ve Learned

About this time last year I did a blog post on what I’d learnt after spending a year as a product manager. It turns out that I picked up some additional things in my second year of product management that I believe are also worth sharing. Learning is really supposed to be a lifelong process so this shouldn’t be too surprising right? Okay here’s what I learned:

1. A Product Manager’s Greatest Contribution To their Product Team is Customer Insights: While product managers can wear many hats (UX, project management, analytics, e.t.c), I believe that the greatest contribution that a product manager can bring to their team is customer insights, or knowledge of their product’s buyers and users.
There are two reasons for this. First, customer insights are essential as most great products start with great customer insights. Without a deep understanding of the customer, great engineering, UX and analytical skills will not result in a successful product. Therefore, product managers have to make sure that their product teams never lack this important ingredient. The second reason why a product manager’s greatest contribution to their team is customer insights is that within the product team, the product manager is ultimately responsible for customer insights, just like the software engineer is responsible for delivering amazing code, and the UX designer is responsible for delivering compelling and delightful product experiences.

2. You Cannot Outsource Your Product Strategy To Your Most Important Customer(s): We all know how important it is to listen to customers. What may not be as obvious is that it is possible to listen too much to customers. This happens when product managers develop their product strategy and roadmaps based on customer input alone. This makes sense at some level right? If you want to build what customers want then just go ahead and ask them! What makes this approach risky is that in most cases, the customers that product managers get input from may not adequately represent their product’s current and future customer base. Customers who usually talk to us are tiny segments like the really big customers, the really sophisticated ones, or those who really love or really hate our product. In order to create a holistic product strategy, we need to consume and distill additional sources of customer insight such as actual product usage data, competitive analyses, and – where applicable – feedback from customer support and sales.

3. Data-Driven Product Development is Hard: A few months ago I did a blog post on data-driven product development: a systematic way for ensuring that product investments actually deliver the right outcomes to customers and the business. What I’ve learned from helping other product teams become more data driven, and from the data-driven journey of my own product team, is that this stuff is really hard to do. Few things suck as much as working on a new, “game changing” feature for months, and then discovering that the feature did not impact any of your key business metrics after release. The very real temptation then is to go back to the old days of celebrating the release of a feature without checking the impact of that feature on your business. This will definitely guarantee lots of good feelings all around within your product team, but it will not guarantee the future of your product, your team, or your current job. 🙂

That’s what I’ve learned this past year. What have you learned in your own role?

 

Advertisements

I Want To Use Data To Improve My Product. Where Do I Start?

Most technology professionals will probably agree that data-driven business and product decisions deliver better outcomes than simply going with your gut, or worse: with the HiPPO. However, an important challenge remains for product teams trying to become data-driven: where do they start?

Below is a series of steps for navigating the path to data-driven product management. These steps could be applied to an entire product, or to a feature existing within a larger product. Also, while it is focused more on technology products, I believe parts of it could be applied outside the technology industry as well. Here goes:

1. Does your product work?: An awesome app that crashes every single time it’s opened is a worthless app. Therefore, the first set of data and metrics to be collected and analyzed should revolve around product health and operational intelligence. This will help you answer questions like how many hours in a day your product is available, what your crash rate is, and what your product’s performance is like during peak times.
Examples of publicly available product health and operational intelligence tools include Splunk and the elastic stack, or ELK.

2. Is it popular?: Once you get going with analyzing your product’s health, the next step is product and user analytics. This means collecting the data and developing the metrics needed to figure out how many people are using your product, and whether that number is trending up, or down. You also want to analyze your user base to identify your product’s user segments, and to begin understanding which segments are valuable, and what the valuable segments care about so you can tailor your product roadmap and marketing programs accordingly. This is not easy stuff, but getting it right pays huge dividends.
Publicly available tools for enabling product and user analytics include Localytics, Mixpanel, and Amplitude.

3. Are product updates changing key metrics?: Every update made to your product that results in no change in any of the metrics that you care about is probably a worthless update. On the other hand, increases or decreases in your business and product metrics may be as a result of external factors such as the weather or U.S elections. 🙂 One way to improve your certainty around what effects your updates are having on your key metrics is by running experiments. In very simple terms, this involves releasing product updates to a subset of your product’s user base, and then comparing the subsequent behavior of the users who  received the update with those who didn’t receive any product updates.
Publicly available tools for enabling experimentation include Optimizely and Unbounce.

4. Is your product Intelligent?: Artificial intelligence (AI) is all the rage today, as it promises to unleash a new wave of tech-enabled productivity on consumers and businesses. However, a critical ingredient for enabling AI scenarios is data. For example, the reason why Amazon can tell you that people who bought item X also bought item Y is because it has huge amounts of transaction data on both items. For your product to be able to support such intelligent scenarios, you need to collect and organize the relevant data sets, and then employ the right algorithms.
The process of enabling AI scenarios within a product usually involves custom development by software engineers. However, publicly available tools that can facilitate this process include Amazon ML and Azure ML.

Image by www.qubole.com

A Year in Product Management: What I’ve Learned

A few weeks ago, I celebrated my first year as a product manager. Much to my disappointment, I didn’t get a whole lot of congratulatory messages. Only LinkedIn remembered (thanks LinkedIn!).

Self reflection is something that I truly value, so I decided to take some time to think about what I’ve learned about the product management discipline during the past year. I came up with three key findings:

1. Wearing Multiple Hats is the Name of the Game
Before I became a product manager, my thoughts about the role can be summed up in this beautiful Venn diagram from the pm heels blog:

pm-ven-diagram

Now that I have a year’s worth of product management experience, I’ve modified this diagram to become something like this:

 

2. It is Important to Always be Working on the Most Important Things

From my product management Venn diagram, you can see that there is an infinite number of tasks that a product manager can be involved in. Yes those tasks can have UX, business, or  technology components. However, they can also involve random stuff like getting pizza for engineers who are working late (I haven’t had to do this yet but I happily will).

This brings us to the problem of prioritization. Since no one can do everything, product managers have to constantly check to ensure that whatever they’re working on has a higher chance of improving their product’s success metrics compared to other things that they could be doing. In case you’re wondering, there most definitely are some cases where the most important thing a product manager can do is get pizza for engineers who are working late. 🙂

3. Relationships Matter

I once heard someone describe product management as “the grease and the glue of product development”. It’s up to us to rally our stakeholders around a common goal, and to ensure overall progress towards the achievement of that goal. This means that we have to constantly influence our peers in design, development, and marketing. As none of these people work for us, it really comes down to influencing without authority.

What I’ve learned in the past year (and from folks like Robert Caldini) is that people who like and respect you are more likely to listen to and understand your ideas. In the same vein, you are more likely to listen to and understand the ideas of people that you like and respect. This insight has led me to always try to make relationship investments up front, before they were needed; by then it was usually too late.