Daniel Kahneman, a psychologist and economist notable for his work in the psychology of decision making, noted that “true intuitive expertise is learned from prolonged experience with good feedback on mistakes”. And let’s be realistic - any human makes mistakes, in both professional and personal matters. It’s a part of everyone’s life, regardless of your socio-economic background or the range of skills and abilities you possess. And just like with any skill or ability, one can make less mistakes over time.
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?
In several conversations with individuals that I help mentor, the same question seems to be coming up more often than others - what are the skills necessary to be a good product manager? This seemed like a great opportunity to provide a more persistent outline that can be referenced by others in the future, hence this post. I should mention that this list is, of course, not comprehensive - depending on the company, responsibilities and the product one is working on, additional skills might be necessary (or even the same skills, but in a different context).
I will preface this post by saying that it’s not about quantifying the education of those that already went through coding bootcamps, but is rather a point of view (i.e. opinion) for those that are considering whether they need to sign up and pay for bootcamps that will teach them how to write software. I am sure there are quite a few people who found success going down the bootcamp path, and I am extremely happy for those that found it to be their preferred approach.
When things go wrong, it’s human instinct to jump to the nearest possible solution and execute. The goal is to rectify the problem as soon as possible, to ensure that it either never happens again, or the chances of it happening again are slim. This hasty response, however, more often than not leads to suboptimal solutions that merely put a band-aid on the problem and do not address the underlying root causes.
If you are a product person, you’ve probably heard this numerous times - “fail fast, fail often”. To many, this often might sound like an invitation to just ship whatever comes to mind, test it and then assume that there is some “learning” happening afterwards that is going to help one come up with a better solution to a user problem. Photo by Quino Al on Unsplash. Let’s say that we take this scenario outside the product world.
As a PM, one of the most important skills that I learned in the past couple of years is the ability to collect, query and analyze data. No, really - data is fascinating to me almost more than any other part of the product. Data can inform any future decisions and either validate or invalidate your hypotheses around the direction of your work. Before joining Microsoft, I always thought that working with data is something that only data scientists and analysts do - a PM sets out the path for the product, the data science team provides the numbers and insights, and then engineering drives the implementation.
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.
You are getting started as a PM - what are some of the tools that can help you be productive, organized and just overall effective? That is a question that I asked myself when I first started as a program manager. There are so many things to stay on top of, and just no clear guidance as to what I should use to do so. In this post, I am outlining just some of them that helped me not lose track of the million and one things a PM needs to work on.
I remember the day when I got my first internship at Microsoft as a program manager. It was such a new concept to me at the time - months before my interview took place I was hastily doing my research, trying to figure out what does a PM do. One of my first explorations in that domain was through a post from Steven Sinofsky - PM at Microsoft. One part stood out:
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.
As a program manager (PM, for short), I had and continue to have the pleasure of working on a number of features across a range of products. The scope and feature direction can change fairly frequently, and it’s our (PM’s) core responsibility to re-adjust and make sure that we design and develop a solution that helps our customers be more productive, efficient, and successful. In Ben Horowitz’s 15 year old post, he states that good PMs are “mini-CEOs” of features and product segments.
I’ll spare you the tacky quote that one could put at the beginning of an essay that tells you how important focus is and instead jump right to the content. I thought some time about writing this - reading Deep Work by Cal Newport pushed me to formalize my thoughts a bit more, the output being this blog post. There is two definitions to focus, each with its own direction. One is related to an inherent ability to segment one’s attention in a way that produces the best outputs.
August already flew by and it’s a good time to finally post the presentation I delivered here in Vancouver, BC, at the Open Source Summit North America 2018. This year, it so happened that I had the pleasure of doing two rounds on the same topic - Docs as part of the product: open-source documentation at scale. The two rounds were: A lighting talk, giving a high-level overview of where we’re going with open docs.
Remote work is something that is near and dear to me, because, well - I am myself a remote worker. My core team is located near Seattle, I am myself located in British Columbia, Canada. While it’s not that big of a distance (only 2.5 hours of a drive, depending on border wait times), working remotely poses an interesting set of challenges and makes you re-assess your perspectives on collaboration.
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.
THE new adventure This past month marked an important milestone in my life. Several milestones, at that, but all in the right order. Starting with the important ones - I FRIGGIN’ GOT MARRIED! Hands down, the happiest moment of my life! My wife Tiffany seems to be happy about that decision as well, so we’re diving head-first into the intricacies of adult life and all decisions that come with it.
This October marks a year since my switch from working on client software to working on the unified Microsoft documentation experience. Throughout the past year I had to learn a tremendous amount of absolutely new (to me, at least) things that totally changed my perception of what the importance of documentation is.
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.
As someone who is almost (and by almost, I mean months away) from finishing my undergraduate program and starting as a full-time Program Manager at Microsoft, I feel like the past 4 years have really been life-changing for me, both from personal and professional standpoints. It’s been a rollercoaster, and I happened to be lucky every second that I’ve been on it.
Back in the day, December 8th, 2008 I decided to join Dream.In.Code. What was the reason? Just for fun, in the first place. I wanted to see how many people I can help with programming issues, how many articles I can write and how many pieces of reusable code I could submit.