One of the skills that I find to be indispensable for a product manager is the ability to learn new things quickly. The reason why this is important is because we operate in an environment where things change constantly, and there is frequently a need to jump in and help with a specific aspect of product delivery that is new. This raises an interesting question - what is the best approach to learn things quickly?
This question probably came up for anyone that ever worked as a PM - when should I use quantitative metrics, and when should I rely on qualitative metrics? It’s an important aspect of ensuring that the right data is used for the right aspect of product planning. Let’s start by distilling the terms. Quantitative data is data that is heavily grounded in numbers - how many users, what percentage of them are happy, what is the ratio of converted vs.
Last year, I decided to be more proactive about working on becoming a better product manager - I acutally carved out some time to learn about the skills that would allow me to have a bigger positive impact on the customers of projects that I am building. I’ve spent a significant amount of time reading through various books that tackled topics from customer empathy, innovation to practices on improving collaboration with my team and partners.
I’ve always loved technology - since the first 486 computer my parents got me, to the days when I discovered Visual Basic 6 with its revolutionary ability to build graphical user interfaces by just dragging the mouse around. I was fortunate enough that my parents were able to afford the tools that planted the seed of “Maybe I can be an engineer?” in my mind. Once I moved to the United States, I was, once again, fortunate enough that I got connected early with people that helped propel my career where it is today - from online community leaders to industry professionals.
Last year I started writing down a summary of some things that I accomplished and learned in the previous 365 days. It’s a good way to put things into perspective and compile a high-level plan for what can be done differently in the coming year! It’s time to re-visit this tradition for an overview of 2018, and set some goals for 2019! Now, I am not that big into setting resolutions because one should be able to do dope stuff on a rolling basis without some arbitrary time markers, but it’s nice to have a baseline against which you can measure progress.
2018 is (almost) upon us and many people are making new resolutions for what they want to achieve in the new year. I wrote about some of my high-level goals as well. The one piece missing in it is the how description, and for that I decided to write this post. Just like the overview post, I want to make this a yearly tradition - a set of tips on how to maximize productivity, based on learnings from the previous year.
The end of 2017 is almost here (and by almost, I mean there are less than two weeks left), so it’s a good time to look back at the last year, see what happened, and throw some ideas for the year to come. docs.microsoft.com Experiences This year, at least for me, kicked into full-gear at docs.microsoft.com. We’ve launched the documentation platform in 2016, and 2017 brought in the solidification of the product - we’ve consolidated many content pieces, and introduced a number of completely new experiences.
Before going any further into this post, I should preface this by saying that anything and everything below is purely my subjective view on what makes a Program Manager a great Program Manager. I consider myself lucky enough to have experienced what it's like to be a PM on a product team, and currently - on a content team, and this blog post is a reflection of my experiences across the two completely different organizations.