I alluded to this a few days ago, but I have a new role. Starting today, I am back at Microsoft. I’ve joined the Microsoft Identity division as a Principal PM and will be helping drive the efforts to build the best identity Software Development Kits (SDKs) and tools for developers that use services such as Microsoft Azure Active Directory and the Microsoft Account.
Not too long ago, I was reading Charlie Kindel's "You're Thinking of Your Career Trajectory Wrong" and it reminded me of yet another trope that somehow is very commonplace, at least in the tech industry - your career is not a sprint, it's a marathon. It comes from a well-intentioned desire to communicate the fact that careers should be looked at through the long-term lens, which makes sense - we rarely hear the story of someone being right out of college and then becoming a Vice President of Product at a Fortune 500. It's all about the long game. But it also sets a lot of folks for failure early on.
If you asked me 20 years back as to what I want to do with my life, I'd probably answer with something like "build stuff with computers." From the early days of my career, to some of the more recent adventures, I tried to find teams where I can be very hands-on with the tech stack and build, build, build.
Talk about making some life changes in a short period of time! I am genuinely pumped to be coming back to something that is near and dear to my heart - developer relations.
In the past couple of months, folks asked me how I got into product management. While everyone probably wants to hear an overly romanticized story about how this was my passion from an early age, the reality is much funnier - it was an accident. I never had any plan to be in product management, and yet, this is how I built my career. This essay is a story of how I got to be in the role I am today.
Last week I mentioned that after six year at Microsoft I was leaving the company to pursue a new adventure that would push my growth and skills to new levels. To me, learning can only be done if I constantly push myself outside my comfort zone - I think today’s decision does this. I am happy to announce that starting today I will be joining Amazon Web Services as a Senior Product Manager, Technical on the Amazon EventBridge team, making serverless and event-driven infrastructure more accessible and developer-friendly.
Jeff Sandquist, CVP of Developer Relations at Microsoft, once said that “change invigorates the soul”. Working with Jeff’s organization was one of the highlights of my career - collaborating with some of the smartest folks in the industry, shipping things that have an impact (also known as docs.microsoft.com) and being very closely aligned with developer needs. I’ve been at Microsoft for close to six years, and I always felt like I am never the smartest person in the room - the sheer caliber of individuals that I had the honor of working with speaks volumes for the kinds of organizations that exist within the company.
Yes, you read that right - my good friend Courtny and I launched a podcast, dubbed “The Work Item”, where we talk about everything that comes to mind in the product development and design space. We even have a mascot, named “Peppy the Post-It” (Courtny is the creative mastermind behind the art and the mascot name, by the way). Two episodes of this podcast are already out - the first one being on remote work (check it out on YouTube), and the second covering our career paths (also on YouTube).
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.
All the way back in 2013, Paul Stamatiou wrote a blog post on how he simplified his life. It’s a relatively short essay that I highly recommend everyone read. I personally find a lot of value in simplicity. It’s all about focusing your time and effort on things that matter, and reduce the friction in making decisions (which take a non-zero amount of time and mental effort). I try to make a conscientious effort in bringing the philosophy of minimalism and simplicity into everything I do, so you can use this post as an encouragement to do the same.
Here’s a statement that covers an often overlooked reality - as a product manager, you are in sales. Now, you might be wondering - you’re not putting together sales plans, you are not knocking door-to-door to sell a product, you’re not even part of your marketing department. How is that you’re in sales? In this article, stop focusing on the idea of sales being an exchange of goods for money, and instead, focus on the following definition:
The other day I had a conversation with my skip-level manager about what it means to be a leader in an independent contributor role, that prompted me to sit down and write this out. I’ve always been fascinated about ways in which I can multiply my impact, so this seemed like an important conversation to have. A lot of times product managers assume that just because they are in an Individual Contributor (IC) role, that means they need to focus only on their immediate areas - things that yield positive outcomes in projects and initiatives that are directly related to one’s line of work.
I’ve recently had a chat with my team on metrics - one of the key topics a PM needs to be well-versed in. Metrics are at the core of helping you define what you’re truly after. Having a deep understanding of what you are measuring is the only way to make sure that in the long-run, you’re able to build a product that truly satisfies customer needs. Consider this post a basic intro in just that - getting a grasp on quantifiable measures of the performance of your product.
I am big on figuring out ways in which I can spend time more meaningfully. Part of this is a strategy to automate as many of the routine tasks as possible, to make sure that I can focus on the big picture - building products that deliver value to customers. I should also preface this post with some context - I am a remote employee. Sometimes it’s hard to communicate what you’re doing and how you’re approaching the stack of tasks while hundreds of miles away from your team.
Ideas are an interesting beast - we tend to get attached to them as if they are the lifeblood of what we’re doing. It’s especially common in the world of product management - way too often PMs tend to think that the most important part of the job is to come up with great ideas, implement them, and see the product shine. I thought so too when I was first starting out - the onus was on me to come up with the right solution as the driver behind a feature or product segment.
What is the purpose of a 1:1 with your manager? I wanted to do a write-up to dispel a common misconception around what that meeting with your manager is, and how you can channel it into a much more productive use of time. Status Whenever I talk to new hires, and they set up 1:1s with me or their new manager, one thing becomes very obvious - a lot of people consider 1:1 meetings to be a forum to discuss everything they’ve done in the past week/month/quarter.
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.
If you haven’t seen Casey Neistat’s latest video, spend a couple of minutes (NOT during the work day) doing that, even if you are not that into vlogging. I wrote on this topic last year, but this is something that I kept encountering more and more - there are so many distracting factors that one needs to get under control to truly be on top of things. Randomization is everywhere, and it’s 90% coming from your shiny screen, mostly from social apps.
You talk to customers, you collect data, you got buy-in from your internal stakeholders. You lined everything up for a successful feature launch. And then you run an experiment, and the reality showed you that the implementation that you expected to be the winning one is actually not what moves the needle for the larger product. Now you have a dilemma - you have the option to launch as is (after all, you did the due diligence - maybe the experiment timing was bad and in the real world, people will love what you did) or go back to the drawing board.
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:
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.
Prompted by a Reddit thread, the question in the title seems to be a fairly common one among Computer Science undergrads as well as those that are just now starting up in the field - What programming language should I choose? Is there a possibility that I will choose the wrong one? Should I learn one or many?
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.
This summer I got an awesome opportunity, thanks to Dan Fernandez, Jeff Sandquist, and Clint Rutkas – I worked as a vendor/intern on the Channel9 Coding4Fun team. Now, if you are not aware of what Channel9 is about, then you are totally missing out on a portal dedicated to everything Microsoft (with a focus on dev tech), so check it out.
If you are using So.Cl, you have a great opportunity to help three students: me, Wilson To, and Alex Poms, in the monumental task of writing a research paper on the social network.