From Program to Product Manager

About 6 years ago, when I joined Microsoft as a campus hire program manager, a transformation for PMs to focus more on product management and less project was kicked off. I feel lucky to go through this journey and want to share some of my personal learning.

Keep thinking about your product's value-add

Today at Microsoft, tech lead has taken over most of the project management work like breaking down work items, tracking project status, communicating status with partners, etc. So PMs have much more time to think about their product. I have to keep thinking hard about the value add, the mission, the road map before writing a detailed spec to design the features. This means you have to regularly ask yourself questions like:

• Who are my target customers?
• What are their pain points?
• Is there any existing product that can (partially) solve their problems?
• What's our competitive advantage compared with other similar products?
• Is current proposal the only way to solve their problems or can I break some presumptions?

The answers may evolve as you spend more time thinking and practicing. I still remember when we were pushing hard on ourselves to figure out the value-add of a data product, we didn't find a promising answer but the thinking practice leads us to pivot to another product to address the hard problems in data consumption.

Set up a measurable goal for your product release

This is probably #1 learning I had in the past several years. Setting a KPI at the beginning of your product development will help a lot subsequently. This KPI (e.g. monthly active users) should be aligned with your product's value-add. There were many times my feature crew members debating among the priority of different features. But when everyone checked back with the KPI, we could come to a conclusion very easily on which one should be done first. On the other hand, setting up a KPI will make you measure the product success not just by "releasing it". You will learn how to build a useful product by keeping track of the KPI during the whole product life cycle.

Use "scenarios" to operate your product

As a product manager, we are always reminded as the "CEO" of our product. In the real world, if you run a startup, building good product cannot guarantee the success (or even survival) of your company. Operations including business development, marketing, sales, customer support, etc. all play critical roles. You might not be specialized in these areas, but you should at least learn and understand what they are and how they can help to build a successful product. I remember when writing my first spec, I found it really hard to write "scenario" section as I felt it was like writing a fiction story (e.g. one Tuesday morning, David comes to office with a happy mood...). But nowadays, though we write much simpler specs, we use more often the word "scenario", as it's not only related to designing the flow of how our target customers use the product, but also how they find the product, realize it and get support from us. For example, if our users' daily life is reading a data wiki before writing the query, then embedding some links to the wiki (which needs to partner with the team who owns the wiki) will help them more easily to find our product rather than just 1-off release announcement. If most people get to know what tools to use from word of mouth, then growing these "opinion leaders" to fans will help significantly in promoting our product. These "operations" are all based on a deep understanding of the customers and their scenarios (which a product manager should be good at) and will help you amplify the impact of the product.

Recently, someone asked me about what should be the core competency of a product manager. To be honest I don't have a clear answer as PM role is always quickly evolving. Maybe the only thing that keeps unchanged is the continuous learning and practicing. This article reflects some of my current thinking and welcome for any feedback or suggestion:)