PM at Microsoft: Comparing Program Manager vs Product Manager Roles – Part I

Listen in to a fantastic chat with Dhananjay Mahajan! He has over 25+ years of experience in working in tech. He has had a long career at Microsoft for 20 years. He worked as a lead engineer for 5 years and as a Program Manager 15 year. And over the last five years has been focused on program and product management areas. Technical Product Management Interview: With Dhananjay Mahajan

• Part I
• Part II
• Part III

We discuss :-

• What is product management?
• How does Product Management differ In an agile vs a traditional organization?
• What the core fundamental skills a Product Manager should have?
• What does it take to be a product manager driving a technical product?
• How is it different being a B2C Product Manager vs a B2B product manager?
• What are the primary difficulties or challenges for most Product managers?
• How the Product management role is evolving in the near future?
• As a product manager, how do we look for product – market fit?
• How can you promote a culture of innovation?
• General Product Manager advice and tips ?

Dhananjay goes into great details and explains with great anecdotal stories. Feel free to add your comments below and also tell of other topics you might want to hear about.

Thank you,

Mario Gerard

Ps – I am contemplating the need to add the transcripts to these podcasts. Like the one found here .  If you believe transcripts would be useful to you do leave a comment below.

See also: TPM Interview questions

Mario Gerard: Hello, and welcome to the TPM podcast with Mario Gerard. Today I have a very interesting guest, Dhananjay Mahajan with me, and he has over 25 years of working in tech and has a long career in Microsoft over 20 years, I believe. He’s worked as a lead engineer and as a program manager for 15 years. I know the past five years he’s been focused on program and product management. So, would you like to introduce ourselves?

Dhananjay Mahajan: Yeah. Thanks Mario. I’m really looking forward to this podcast. I’ve liked the podcast that you’ve done in the past. So, a pleasure and thanks for the opportunity. Dhananjay here, I’m a product manager been doing product management for over 15 years now called program management at Microsoft product management in other companies. 

My primary focus started being a bit on the consumer side as I started working on windows 95 and windows media, and then switched over pretty quickly into distributed systems. And what’s now called cloud computing. So, I worked and released many products as a program manager, as well as a lead software engineer arranging from windows Azure, most recently.net. And after that, I started working more on enterprise solutions and that are targeted towards IT operations and developers. What sometimes is called as devops to help enterprise, you know, accelerate the cloud adoption. That’s where I had the pleasure of working with Mario at Oracle cloud infrastructure. 

And most recent, I was the head of product at Heto a startup, which recently got acquired and we worked on making Kubernetes ubiquitous in the enterprises. So really looking forward to this discussion and the exchange of ideas on product management and program management with you, Mario.

What is product management?

Mario Gerard: Cool. So, I think what we kind of pinned out for today is more you know, giving the program managers of the TPMS, a flavor of what product management is all about. So, what, in your opinion is product management and how does it defer to program management?

Dhananjay Mahajan: Yeah, great. Question and for the start there are several similarities between both roles and as you apply noted at Microsoft, it was called program manager. They still call it as program manager. And there are aspects of it which go into product management. The job of a product manager in the pure sense is to discover a service or offering that is usable of value to the customer and is feasible something that can be delivered as a package service. It is the, you know, I look at that role really as having a three-pronged approach, one is having a customer or user empathy. 

The second one is having a good sense of technology and technical aspects that make it accessible to the customer. And then the third aspect is business acumen. And so those three things melt to make a product manager. So let me go into a few examples of how those interact. 

From a customer empathy standpoint, a product manager has to understand and own the entire customer experience, how the technology that you’re providing impact does it provide value to the customer, understand the customer journey. It involves activities like talking to customer, understanding what they want or translating that into needs as we call it. And then coming up and helping the team understand what is the minimum viable product, or what’s the minimum lovable product which customers would like.

Mario Gerard: So, basically you are the voice of the customer, right? You are, you are, you are putting yourself in the customer’s shoes and you are the voice of the customer. And you’re trying to make sure that whatever you deliver is going to be used by the customer.

Dhananjay Mahajan: Exactly. And I like that voice of the customer to translate also with my engineering teams. So that they can start understanding it. So, I look at myself as the first voice who understands the customer, translates it, but I want all my engineering teams also to understand and start becoming an echo that voice.

Mario Gerard: So, a couple of things that you just brought up, right. One is talk to the customers. In my previous roles, I’ve had product managers who do like surveys, right? They do surveys with different customers, understand what the needs are, or you do some kind of focus groups, and you figure out like, you know, whether that’s what the customer wants, or you’ve already identified a segment of the market and you’re going after that particular segment. And then you are basically trying to see what that segment actually exactly wants. 

Because sometimes we as even as product managers, right. You think the customer wants X, but actually he wants Y. And that’s the most, I think, difficult job of the product manager to articulate that very clearly and make sure that what you’re being the voice of the customer is very, very critical. And I also think one other thing is that you got to get that right. 

And I think that’s why I personally have never moved to the product management side is because if you get it wrong, you might spend like a year or six months or eight months with a dev team of 20, 30 people maybe. Yeah. And you build something out and the product doesn’t fly after that.

Dhananjay Mahajan: Yeah. And you’re bringing up a very interesting and important point. Mario is understanding what is the minimum lovable product for the customer is important and you are getting into some discussion we may have later on, which is the difference between the newer agile model, which is more iterative to the waterfall model where, you know, I’ve worked on products, which I worked on for two, three years, and then released it to customers and then found that customers didn’t want that. 

So, talking to the customers is important. And that could be through, like you said, surveys, but what I to also do is that echo effect. So not only do I do surveys, not only do I have my teams get involved in a customer engagement program where we are constantly trading and talking to customers, but I also leverage my field, my sales and services teams who are constantly engaging with customers to also become the voice of the customer. 

So, I’m in constant touch with what the customer needs are. And in the recent, you know, changes that are happening in disruptive markets, those things change a lot, which brings me to the second point, which you made, which was very apt, which is, customers will ask you for one thing as what they want. But what they need is different from what they want. 

And I’ll tell you an example when I was working on a product, which was a cloud platform broker, which simplified deploying applications into the cloud for enterprises, whichever they wanted to go, whether they wanted to do AWS, or they wanted to do Azure, or Google cloud, or even Oracle cloud. And they kept asking me like, hey, make this simpler, make this simpler. So, I was focused on making things simpler. But what ended up happening is it, the simple caused a side effect where there was a sprawl of all these cloud resources being used and it showed up in the customer’s bill. This was back in 2014. 

So, customers, I started chasing down what customers were asking me to do, which is simply them consuming the cloud, which was great for cloud providers. But what ended up happening is that they got these huge bills, and they were shocked. And that caused a negative effect in them stopping working with the cloud. So, what they wanted was not just simplicity, but also controls. And sort of a targeted way to make sure that they’re not overspending on the cloud.

So, after having realized that, and that came through because of the customer interaction Is that the customer said, wow! We went from being able to deploy a hundred you know VM resources to the cloud to now I’m getting 6,000 a month. And I don’t know where these 6,000 are coming because you made it push button simple to deploy them. So, I think it’s a very important point to keep in mind, as we make those lovable products, we want to make sure that they don’t become hateable products, even if they’re viable and keeping an eye on what customers want, but also keeping on what they need. So, as you make things simpler to do you want to also make sure that they have proper controls in place, especially enterprise products so that it doesn’t get out of control

Minimum Viable Product

Mario Gerard: And you also spoke about the minimum viable product or the minimum viable product. How do you decide where that kind of…? Is it like six months or is it going to be eight months or is it like, in terms of features, you can either look at it in terms of features, or in the term of time, right? And how do you draw that line? Do you have any, like, if you can say it like two, three lines on how.

Dhananjay Mahajan: Yeah. So that is always an art. And there is no simple formula. There is a bit of science, there’s experience that you bring in and it all goes down to understanding the customer. Understanding the business, you are in making sure that you are aligning your product offering with the vision, with the brand that you’ve created. And making sure that you have metrics and controls to validate what you’re doing. In an iterative fashion. 

So, let me go on there, understanding the customer it’s important to understand, are you solving what they’re asking you to do or really identifying the problem under the covers? You know, that’s what takes the experience product manager to not just ask, would you like to use feature X versus Y. But really understand what problem customers are facing. 

Secondly, it is important to understand, are you solving a problem that’s pervasive and something that the customer is willing to pay. So, their customers will tell you all kinds of problems. And especially you brought up a good point of segmenting your customers and looking after different segments.

I’ve got one extreme of customer asking me to do X and another customer asking me to do Y yeah. And you have limited resources and time to do exactly. Would you pick X over Y that’s where you want to decide, you know, are these customers aligned with the target market you’re going after. And sometimes you may, some customers unhappy. And so, if they are in your target market, are you solving the real problems that they want?

I’ll give you another example. We had a backup product that would backup clusters. It was well liked by the developers who already had clusters set up in their own private test environments and with a push button, they could back it up. When we went to the operations users of that product, they were barely setting up clusters with those controls. Developers didn’t want controls. The operations folks wanted controls. They didn’t care, the operations folks didn’t care about a backup product. They’re like, I don’t even have a cluster to back up. 

Focusing on enabling them. And they are the buyers. I mean, developers are the ones who are testing it out, but the buyers are the operations folks. Enabling the operations folks is going to see much more acceleration in an enterprise product where you’re targeting first to enable them to set up several clusters and then back it up. So those are kind of examples that help you understand, are you focused on the right problem? 

Second thing is, is it pervasive? Is that something that they have facing right now? And are you providing value that they’re willing to pay for it? If you have a paid product.

Dhananjay Mahajan: Second thing you want to do, the third thing you want to do is make sure you have constant engagement with these, both these various customer segments, and you are collecting feedback on an ongoing product. So don’t wait for your entire product to be ready and then push it out. You know, I have had an engagement program where I had some trusted partners customers that I worked with. I would even show them prototypes That my UX team had built. We had not even created code out of it. 

Mario Gerard: Just mock prototypes,

Dhananjay Mahajan: Just mock prototypes and then get their feedback and it will be amazing what you learn from those kinds of things. So, making sure that that’s happening and once customers deploy your products have an active, especially in the cloud world, one of the benefits that we had even working in Oracle cloud is with the consent of the customer, we could actually track how customers are using the product. 

You have to act instrument the product to be able to collect the metrics. So important to keep in mind that as you build the product, make sure you instrument the product in such a way that you can collect usage metrics, analyze them. And then the reality is what customers are using versus what they’re telling you. If you do these things, you will be, make sure that you are using your engineering resources, your sales resources in the most effective manner and tracking towards an MVP. 

And sometimes you’ll have to make some wild guesses and bets. But validating that with the follow up really helps you [14:31 inaudible].

Mario Gerard: Yeah. So, you spoke a lot about B2C I come from a, B2B, right, I come from a B2C market. And one of the best things I think we did was use something like amplitude and a mixed panel, but basically those are built into your app, and it actually tracks what a user actually does. So, supposing you take a user session, a users on any app, Facebook or anything. You then see every button he clicks and can you do it across like a hundreds of thousands of users and see whether they’re loving that new feature user is launched or they’re not loving it. And then if they’re loving it, you go and you invest more to make it more durable, make it more scalable and, you know, add more features to that particular new feature you already added and then come back and, you know, reiterate to see if it’s actually you know, doing well. And that’s why you see a lot of Google does this right. Where they launch beta programs. 

And Google’s probably on the extreme, but they launch a beta for like many years. I think Gmail was on beta for a long, long time. But you’re trying to test make sure that it works really well. So cool. And then you were going to the other thing, right, Tech, we started with what is product management and we got sidetracked little bit. 

Dhananjay Mahajan: No, but it was an interesting conversation. Do product managers have to be technical. I think it depends on the product on one X, and we have companies like Mario, you and I have worked on, which are, you know, cloud and distributed computing and your customers are fairly technical. They’re either developer, or IT operations folks or architects or working on the cloud and technical aspects help a lot. 

And then you have certain other products where I’ve never worked at apple, but I’ve heard that apple actually employs non-technical yeah. People without a technology background to design their products. So that they are more user friendly for the non-techy folks. But I feel like, especially in the area that we are working on technology even for consumer products helps a product manager. In these follow aspects, one is you have to win a lot of credibility with your engineering teams, and you know, having a technical background and I’ve been a developer in the past, helps me have empathy towards what my engineering cost is going to be, what my engineers are going to go through. 

I may not be having a full understanding of the implementation. Yeah. When a customer asks me, can you do X, you know, customer is like a kid in the candy shop. And they may ask all kinds of requirements. Having that technical background helps me translate that customer and business requirement to what the technical requirements would be. And also get additional details from the customer, from sales teams, from field, so that I’m armed with all the data we need to make the prioritization decisions. 

Because ultimately the, the priority of what you will build for MVP, not only rests on fixing the per pervasive problem, but also understanding what the cost of the problem is. If the problem is per pervasive has great value for the customer, but the cost is so high that you’ll be working on it for the next three years. You may have lost the opportunity because the market has moved on. Your other products competition would’ve moved in and taken that. 

So, you want to work on pro you know, fixing the features or prioritizing the features that have highest impact and sort of lowest cost, highest impact on the value for the customer and lowest

Engineering cost or resource cost, customer acquisition cost. And so, the technical background helps me and thirdly, you know, often product managers get involved in doing proof of concepts. 

So, if I have a developer customer target, then writing a simple piece of code or an app actually helps me understand my customer better. And also helping my engineering team better.

Mario Gerard: So, yeah recently what happened was, so Amazon was the first company, I think, which launched the TPM as a role technical program manager. And now, if you look at Amazon, Amazon’s actually launched the PMT, which is a product manager technical, that’s a new role, which they have launched I think the last three, four years. And it’s that you see more and more people who are moving to the PMT role because one is because it’s about it’s because of AWS. Because AWS is, again going back to your customers or your developers. And the product manager, who’s building say database as a service is going to be really, really a hardcore database engineer who knows ins and outs of the database to actually be a product manager on the database side. 

And then it’s slowly kind of moving to other areas as well, where product managers need to know the intricate workings, supposing you’re doing an API platform or an SDK for customers. You need to know what the customer’s needs are and most of the time those needs are very technical. So, I think there’s a difference between being a B2C, maybe like something like Facebook, you’re doing very something very front end. They could be backend PMTs, but frontend PMT are not necessarily technical. They’re more like a customer’s voice, as you said. 

But when the customer’s voice and the customer himself is a developer or the development community, then you need to really be on the technical side.

Dhananjay Mahajan: Yeah. That’s generally true. Though, I also tell you from my background of working on windows media player. And we were building a new format. This was back in Early two thousand, new encoding format, and it was important to understand how we can protect digital content Yet make it simpler for the end user to use it. And I think these were the early days of MP3 and privacy and so on. 

And one of the bad things, which we did is have an engineering mind in digital rights which made it hard for a customer to use it. So, I feel like sometimes even you need to have a good balance of between the two, even for consumer facing in certain areas.

Business Acumen

Mario Gerard: Yeah. That makes sense. And the next one you were talking about was business acumen, right?

Dhananjay Mahajan: Yeah. So more and more, and now that you brought up, you know, PM technical being a role at Amazon. More and more companies are looking at product managers which is a hard role because, you know, you have to wear several hats, also understand the business and own the business. At the startup that I was working at, we expected product managers almost to be like business owners who are driving the business, not just doing the technology side of it. So, they own the P and L they own making sure that, you know, you have ARR or annual recurring revenue and that measured as part of the overall scorecard for whether a product is successful or not. 

And this is especially important for smaller organizations, startups that are moving into a disruptive market. And that’s why having that business acumen is required. Understanding how you can a product roadmap and yet accomplish your business goals, not just do technology for technology’s sake. What we used to call is building all this technology. Will a customer, not just will this, not only bring value to solving a customer problem, but also is a customer willing to pay for it is an important aspect. 

And if you don’t get that as, as a product manager, if you don’t own the revenue generation pricing, go to market, how you’ll help with the sales team, then you end up building products, which are more, you know, just because they’re fancy technology gadgets than something that’s solving a problem that customers will pay for. 

Mario Gerard: Yeah. I recently wrote a blog because I met a, I recently met a person who at Amazon and I was like, what are you doing? So, he was a product manager for a long time at Amazon. And then he picked up a new role where the title of the role is a single threaded leader. I don’t know if you’ve heard of this. So, at Amazon, they’re launching these new startups within an organization. So, he basically owns, I don’t want to talk about the product exactly. But he owns something where he owns entire P and L within a larger part of a team. 

There’s say there’s a team of say, like, you know, a thousand developers, a thousand people team, it’s a fairly mature product, but they see an initiative where there’s a third party outside Amazon actually trying to do something. They say, hey, why is he doing it? Why don’t we do it? So, it’s kind of a POC you have one year maybe to go and launch that you’re given a budget and a P and L, and he basically works. And his whole thought is to just launch that particular product within a product. It’s an independent entity, but which will help the bigger product. And it’s called a single threaded leader.

And he’s a product manager. And then he slowly moved to this more senior, I think it’s a more senior role where you own end to end, you’re allowed to hire your own team. And then you, you know, go in dev, it’s a very singular goal. The product PMTs have, [24:32 inaudible], single thread donors have a very single goal, go launch this in X amount of time. And you give an X amount of dollars to go to that. So that’s something which you were talking about, the business acumen, product knowledge to go do something like that.

Dhananjay Mahajan: And that’s also a trend I saw in my final years at Microsoft. And I’ve heard since leaving Microsoft that that’s become even more. Is that basically I was a partner program manager, not working with partners of Microsoft to promote Microsoft cloud. Yeah. And I was given, I won’t name the, you know, value, but budget to go pick my partner, the solutions and drive-up adoption of Microsoft cloud with certain metrics around it. That was the most rewarding experience.

Mario Gerard: Because you’re given a free hand. The organization a hundred percent trusts you. It’s all the decision are yours. You basically are given a problem to solve, and they don’t care how you solve it. Of course, you’re having like quarterly or monthly meetings they see in management telling how you’re doing, but basically you own that entire space End to end. You pick your own customers; you have your own budget and you’re trying to do X or Y. So, it’s very, as I said, it’s very, as you said, it’s very, very rewarding. So, cool. 

Let’s talk a little bit about how product management differs in an agile versus a more traditional and I think you worked on both sides, right? You worked on the agile side of the world, and you also worked on, I think you just mentioned like two years to do a product sometimes, right? And how does that differ?

Dhananjay Mahajan: Yeah, I mean, I used, I’ve been on the, there is a difference between working on a plaque form, an operating system, which, you know, is prolific and being used by thousands and millions of customers out there and making one change could impact, even if it’s 1%, a large number of customers. And that in, and even in traditional days, you know, making that one change, like I’m sure how they design. And I worked on a NASA project to the Casini space, mission. Everything was in a waterfall model where everything was tested to the end degree spec to the end degree before it was even handed off to the engineering team. 

Things have changed now. It’s much more of an agile model where you try something out as an experiment. If it sticks, it sticks. You know, you’ll have a few failures and there’s more, it’s about failing fast, exactly. And that’s where I think product management being the role that leads the organization into the change has to be most adapted, you know, that agile development. And that doesn’t mean just knowing scrum and New agile methodologies, but really understanding that you are not going to just build the final spec, you know, wrap it up and hand it off to engineering and not see it until it’s all done, but you got to be more involved in the day to day process of understanding requirements, helping engineering translated, be collaborative with field, sales, engineering, customers, and marketing, be in an iterative side where you’re actually coming up with the minimum viable or usable product and releasing it, validating it, and then failing fast. Like you said, using the feedback that comes from customers to make sure that you’re not going down a path, which is going to create a product, which is not going to be usable.

But it’s kind of like what in one of my organizations, we should, we would call it as let’s build a skateboard. Then we’ll build a cycle. And then we’ll build a car and then we’ll build a plane. Now, if you look at the skateboard, nobody will predict you are trying to build a plane in the long term. But you start with whatever is minimal, that can be quickly tested. And your customer, all they want to do is move from point A to point B. And they’re not looking for flying a plane. Yeah. Maybe eventually they will want to go across the continents. Then you build the plane. So having that mindset, focusing on the MVP and continuous improvement is really important. And with scrum becoming more popular, it has really given rise to that product owner, product manager and TPM and product managers working together in a collaborative environment to do this in an iterative fashion so that you can be more agile. 

And that makes you, I feel more customer focused. Like I mentioned to you, I’ve been on products in the past where we were heads down, building what we expect, and then didn’t see the customers for a year, two years, and then found out that customers didn’t want the us to solve the problem. That’s gone. So, this agile methodology and this new model is definitely making us more customer focused.

Mario Gerard: So, I see that Agile’s really taken off where you have a B2C pro where it’s like, you know, it’s an app or something like that is a website, an application on your phone. Do you see a change in the enterprise space as well? 

Dhananjay Mahajan: Absolutely. Even that Oracle, as well as in my startup more recently, because that’s my experience. And even prior to that, as I was building a cloud broker, we engage with customers on a regular basis. Now true that the buying cycles in enterprises are much slower. They’re much longer. So, customers will be on a trial period much longer. Yeah. But you have more interaction with the customer, you know the customers, you can segment them, you can group them. 

So agile is done just a bit differently. And by the way, when I say agile doesn’t mean I’m expecting everyone to go get agile certifications. In fact, I’ve not found a single team I worked at, which used agile to the spec that I got trained on. It’s a flavor of agile. With enterprises, What I typically do is come up with the top two or three problems Customers have to solve, build an end-to-end scenario, which is usable for the customer. And then present that idea before we start working on it through a prototype to the customer, get their feedback. Work on it. 

And even if it’s not completely done, I have a, you know, trusted customer group, which I may release beta to. So, the cloud offers a great opportunity for enterprises to have small teams where I can release features and do AB testing, for example. Having those capabilities makes agile possible even in the B2B product world.

AB testing

Mario Gerard: Yeah. Yeah. So yeah, in the agile I was talking somebody at LinkedIn a couple of months ago. And I think they were saying at any given point in time LinkedIn, the LinkedIn app, the LinkedIn mobile app is running 600 to 800 AB tests. Just think about that. There are six to eight and they have a very beautiful way to segment customers so they can launch an AB test just in India, for example. Or they can launch AB testing for a particular segment of customers. And they just see, oh, how is it doing for that particular segment? Or how is it doing in this particular market? 

And that is the beauty of agile, right. Because you can go in, you can release something for 1% of your population. And then see how it does, and then you can roll it out or roll it back. If it doesn’t meet the target metrics. You say, this is what I want, I want engagement to go up. I want DAU daily active usage to go up. So, you have a certain metric and you’re trying to hit that metric. If the metric is defined before the product is started and launched, then you, when you launch it to 5% of your audience or 2% of your audience, you actually can go back and measure it and say, hey, this is what I did. This is the outcome. And because of the outcome, I think we should launch it and make it a more wider, you know, go to a wider audience. And the trial-and-error right, to do that is beauty is the beauty of agile. 

I feel, especially in the B2C market you have to have the AB testing framework built into your product and the, you spoke about metrics and collecting the usage. It has to be there because without that you cannot move forward. There’s no way of knowing whether your, whether your customers are going to love it or not. And to launch it to the entire population set does not make any sense because then you can’t roll it back easily. 

Dhananjay Mahajan: So, in the B2C market, if you don’t mind me asking you a question, you’re collecting some metrics from the back end. Do you actually active engage in direct customer feedback?

Mario Gerard: So, that’s what, if you look at product managers in in the B2C space they do the focus groups, you said trusted partners is one way of enterprise is doing it. The B2C does it with focus groups where you have like XY, you know, focus groups on this particular region or this particular geography or something like that. And then that’s before you even go into the product definition phase, so it starts with the focus groups, and then once you start defining it, then you send out surveys to a large group of your customers who have, you know, opted in to do some save surveys for you. And then you start building it and then you do the AB testing over a period of time. 

So, I think scrum, as you said, scrum, agile or whatever you want to call it is more of a framework. I think the framework has reached a point of maturity where you have a lot of other things, which a lot of people don’t talk about. If you’re looking at agile product managers that at companies like Facebook or LinkedIn, or where they have millions of users, you see that you have to be at this cadence where you’re defining your features properly. You’re talking to your customers, even if it’s a smaller set, and then you start launching it into the market with a small control population set. 

Because if you have a hundred different features, nobody’s going to like, it’s going to, your app is going to look, you know, busy and nobody’s going to use anything. So, it’s a continuous AB testing. And I see that, you know, companies like even Amazon, they do a lot of AB testing. Facebook actually launches you know, something new, like a code drop every two hours or every hour. You just don’t realize it because it’s maybe a, just a color change in one small button with somebody thought, okay, that might change things. Or it could be a, you know, a small feature somewhere, which normally which is one percentage of people use. So, it’s very interesting that way.

Hi folks, thanks for listening. And I really hope you enjoyed that. I’ve had to edit this podcast in three parts. So, this is the end of part one. Parts two and three have already been published. So please do listen in.