Last updated on September 27th, 2022 at 02:24 am
Podcast: Play in new window | Download | Embed
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
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,
Core fundamental skills a product manager should have
Mario Gerard: Hi folks, welcome to the TPM podcast with your host Mario Gerard. This is part two of three with, of the interview with Dhananjay, where we talk about product management. So, keep listening in.
So, what do you think are the core fundamental skills of product manager should have?
Dhananjay Mahajan: Yeah. As we talked about Mario, a product manager has to wear several different hats, both inbound and outbound you know, making sure that they not only talk to customers can also talk to field, can talk to sales. Can talk to…
Mario Gerard: I want to ask you, I think a lot of people probably don’t know this, what’s the difference between inbound product managers.
Dhananjay Mahajan: Oh, good point.
Mario Gerard: I know it, but I think it’s very specific, right. Especially something that is used in the enterprise space.
Dhananjay Mahajan: Something in the enterprise space. So, so yes, have you been in couple of organizations where this was used? So it is inbound being product managers and it’s not strictly, I’m not professing that’s the right way to, but inbound are typically product managers who are more focused on working with the engineering teams and internally within the organization to coordinate both the product launch, as well as the readiness of the product, but also creating the product, whereas outbound are the product managers who are working more with the customers, and this is more true, like you said, in larger organizations.
Mario Gerard: And the enterprise space.
Dhananjay Mahajan: In the enterprise space where the product manager role maybe a little more expansive for one person or one functional team to do it.
Mario Gerard: And so, in this case, do you have, if supposing you have a product X do you have a counterpart, if you’re the inbound PM, then you have an outbound PM Counterpart?
Dhananjay Mahajan: In my opinion, the way it should be structured is focused on a key deliverable and function that they have to do. Not to say that, you know, Mario is the outbound and I’m the inbound for it.
Inbound should be more scoped based on, let’s say a key feature, key pillar key theme that is going to get delivered from the product. Outbound, maybe customer on how the customers, so the market is positioned. So, there might be a vertical, let’s say we are building a product, which is generally making and I’m coming from my background. Whereas we want to make cloud approachable infrastructure as a service for all kinds of customers in the enterprise, but there might be a vertical in government or federal, which has specific requirements. So having a product manager that’s outbound who understands how it works with federal, how their buying cycles work, how the customers are, they have their own unique requirements and can drive those requirements across several inbound product managers.
So that’s how I view it. Is outbound should be more focused on the target market segment, customer inbound. If you make that distinction should be more focused on key feature pillar technology that we are trying to deliver. But not strictly, so still a matrix to organization. So good point you asked me to elaborate on inbound versus outbound. Like, but it also brought up an interesting point, which is product manager role is not set in stone. As opposed to say software engineer or other roles that may have a specific…
Mario Gerard: You know, the last couple of months actually the more I think about the TPM role, the more I think about the product manager role, I think about them as more as job duties. And I think they’re fairly you can move either way. You can go to a product manager; you can do a TPM type of role. But it really is a spectrum. You can actually move on either side; you can be a product manager at one point you can be a program manager at one point. But it’s a set of duties and the organization, or the team need certain skills at certain points in time.
Dhananjay Mahajan: In a smaller organization that I’ve been at, you know, in a startup, I didn’t have the pleasure of having TPM, so luxury to having TPMS on my team. So, I was doing both roles. So, you’re absolutely right. If you have the inclination, you can actually move across those roles. So, I’m going to call out core competencies that I look for in building a product manager team, mainly for B2B enterprise focused products. When you bring in other product aspects or, you know, other aspects, you know, there might be other, but these are generally applicable to product managers in general.
One is customer focus, understanding customers, taking their requirements, translating them, you know what they’re asking for into requirements and prioritizing them that’s key and being able to present to them in a well-communicated manner, what value you’re bringing with your product is key.
Another aspect which is not looked on as deeply is the EQ as product managers, remember that we don’t have anybody that we are managing in sense, the folks who are delivering to us, yet we have a lot of dependencies. We have dependencies on the sales teams on the field teams, but we also have dependencies on the engineering teams and the engineering teams don’t report into a product management. I’ve not seen that in most cases.
Mario Gerard: And when you say EQ it’s emotional coefficient.
Dhananjay Mahajan: Emotional intelligence about how do you handle interpersonal relationships? How do you negotiate? How do you, do you, are you self-aware of what your boundaries are? What your strengths are? Can you earn the respect? I think that is key. You may be the best; highly technical product manager who can define everything. But if you can’t motivate a team, if everybody hates having you on their team, you’re not going to be effective at all. You can’t be isolated. You have to be the communicator, the glue between all of these things.
So, I think EQ is an important aspect I look for. And it’s hard to pin down as, oh, how have you done, you know, AWS cloud or have you do you know, swift? You know, it’s not that check box. It comes out of the interaction that they’ve had. It comes through these stories that you built. On when, how you handle tough situations. And that comes through experience and that’s a hard one to quantify.
Technical, we talked about that a lot. Business working, understanding the business is key. One key example is how Redhat took open source and made it into a successful enterprise business by selling red hat, Linux, you know? So, it was not just the technology, the technology existed. But packaging it, offering it, having a go to market channel, you know, they really made that happen early on and open source. So having that business acumen is important.
Deep industry and market expertise is key as a communicator. You have to earn credibility within your team, as well as outside. When you talk to, when you talk to customers, and they have to see you as a credible resource. In fact, my marketing VP used to tell me he would always put me in front of customers. And I’m like, you are marketing, shouldn’t you be talking about, you know all, he says, no people trust, the customers trust product managers more Because we come both with a technical background and we are grounded and we are not, we’re not trying to sell something.
So, it is important to have that communication skills be a good listener and problem solver, but also have deep industry and market expertise that will help you stand up with your key talking points. And you have to be, I like my product managers to be creative, inquisitive, and innovative, you know, do they really, on a day-to-day basis, have they found an interesting product that may not be directly in their mind?
Can they give, you know, are they curious about finding out what the user experience is for that product? I think it’s important to have that curiosity because often we are on the front line of defining what a product is. So, lot of things are undefined and knowing. And being curious is an important aspect. You should learn to do that. And last but not the least is, a product manager has to adapt to the situation you brought this up Mario, right? I mean, depending on whether it’s a B2C product or B2B, or depending on whether the engineering team is highly technical or requires you to take up some of the technical acumen or dealing with different customers at various product stages, being an adaptable and being able to switch is really key for a product manager to have.
What is the competency level of a product manager?
Mario Gerard: So, I think you brought up one very interesting point of
The fact that product managers are in a very ambiguous world, right? You’re not like a developer, nobody’s told you what to do. You’re going there and you’re trying to figure things out. So, you’re in the center of ambiguity, right. I just wanted to like recap the core competencies which you spoke about one is the customer focus. You have emotional intelligence, the technical aptitude. Then you have the ability to work with your business, understanding your business.
Ideally if you’re in the enterprise space, you’re looking at somebody with some kind of deep industry knowledge or a kind of an industry focus, communication as a skill is really good and really important, being innovative, inquisitive, and creative, and the ability to adapt to your team and, and understand what your team wants, where
You really fit in.
So those are amazing probably very important core competencies that a product manager should have. What do you think like if you translate this to a PMT or product manager, who’s technical, what do you think the technical competency, or what is the competency level from a technical standpoint, you see for a product manager?
Dhananjay Mahajan: In terms of being able to help your team technically.
Mario Gerard: Yeah, yeah, yeah. From a technical standpoint.
Dhananjay Mahajan: So how much technical competency do you need to have is an important aspect.
Mario Gerard: I think we struggle as TPMS. We struggle with that, right. Where we’ve been interviewing candidates like we have like five, six open row and we’ve been interviewing like at least a hundred candidates in the last two, three months. And we always end up the debate of how technical do we need this candidate to be. And I think it’s very hard. So, I want to get your take.
Dhananjay Mahajan: Yeah. So, here’s how I think about it. Very true. And it’s not the laundry list of skills, technical skills that they list on their resume. But really can they translate the customer requirements for the customer and the target that they’re going after the solution or service that they’re providing into what the engineering team can understand and really express those in terms of problems.
Dhananjay Mahajan: One of the things that I’ve seen and I’ve myself done that
In the early, jumping into the solution. One of the worst things I did in my, my past life was trying to act smart and tell my engineering lead because I looked at his code and he had not looked at that code for five years, but I said, you have done this if statement and that’s why this bug has come up. Can you go fix it? And I did this in a public forum, which was not a good thing to do. I felt good because I was a new engineer just turned to be a program manager. I thought I must have helped him understand what his bug is. He actually didn’t like it at all.
Mario Gerard: Yeah. I think ideally you shouldn’t jump to a solution. You should what you said was just put the problem statement. Just give a problem statement, translate from a technical aspect, it comes down to the product manager needs to be able to translate where the customer needs, understand the complexity. And just translate the problem statement, all the while understanding what the developer is going to tell him of the complexity of the problem he’s trying to solve. But at the same time, it’s a very fine line. What is the other kind of technical…?
Dhananjay Mahajan: The other things that we need to do is prioritize based on understanding the complexity and the cost of what it would take. I brought this up in an earlier question and you had, which is like, when a customer gives you a laundry list of, I want this, I want this, I want this. At that point, you should be able to understand tease and unpack the assumptions. One of the customers told me, oh, you’re developing a cloud solution. Okay. Cloud infrastructure, I just want what do you call it? I want chargeback.
And chargeback is a big thing, you know, there are companies that…
Yeah, Beast of its own unpacking that assumption. It turns out what they just wanted to know was how much are they going to get charged? And chargeback has its own, you know, whole set of features. So, understanding those features, being able to translate that back to the customer was important for me. So, then I’ve, oh, you just want me to track how much you’re using and then tell you on a daily basis. But look, I won’t be able to predict, because the prediction model will depend on understanding and learning How you are using the cloud. So, it will take some time before I can do prediction.
Yeah, yeah. Just tell me if I go to the console today, how much is it going to cost me for the month. I say, okay, that’s a simpler solution. So being able to translate that sometimes as I mentioned, building prototypes, you know, your engineering team is off and fully staffed to build and deliver or understaffed most of the times to deliver what they have in the sprint. And they’re not going to build this prototype for you. So having that technical skill is really, and then important is to win that credibility back with the customer. So, when you present your solution to the customer, you should be able to stand up. And I said, I know Mario, you asked me for chargeback, but here’s really how this compares to other chargeback solutions. And this really solves the problem you’re trying to solve.
So having that credibility becomes important. So, it’s sufficiently technical to understand the user experience. I got, you know, I, myself been, and I’ve also hired other people who had no understanding of the technology we are building. And I often we are in disruptive markets. We are building something new that nobody has worked on. But it was, can this person translate those into helping deliver a solution? Can they take their background in the past and apply analogous problems and solutions to it, becomes really in important? So that’s how technical it has to be.
And it depends on the product. I’m talking more from an enterprise background, you know, feel free to add your ideas. If, you know, you think consumer product managers have to be, or TPMS have to be technical enough in what is that technical value.
Mario Gerard: Yeah. Yeah. So, I think it’s definitely a hard place, hard question, because you’re trying to assess whether somebody can get into a particular problem area, understand the problem, whether it’s technical or not, and then try to solve that problem. And sometimes you make sure that the person has some kind of an experience where he’s done something similar to the past. And if he’s done like something maybe 70% or 60% similar, then you take that and you say, hey, he’s gone, He solved something which is fairly similar. And though this is completely a different problem space. He can utilize that kind of knowledge that he brings.
Just make sure that he actually has solved that problem. And he knows what he’s talking about. And that’s why sometimes we ask candidates questions on, if you work in solving something, we go into the extreme depth, right. We have a one-on-one conversation on something you worked on, but we are talking about, you’re trying to put the boundaries of the candidate to try to figure out how much he knows. And we just try and push and see whether he’s able to talk the technical language that we expect him to know and talk about whether you have those conversations with developers, like we ask what’s the most technical problem, technically difficult problem you solved or do you help to solve. And let’s talk a little bit about that maybe for even 20, 30 minutes, right? Can you actually tell me the entire problem end to end? And can we go into like details on that?
Dhananjay Mahajan: Absolutely that is very key. Whether when there are certain areas where, you know, is he, or she technically enough to understand, for example, I’ve never worked on gaming. So, I’m sure if I go to a team that’s an engineering team that has built games, they won’t consider me a technical at all and I won’t be effective in driving the next gaming platform. So, the word technical depends on the context. And understanding you’re absolutely right. As we get candidates, he, or she should be able to translate those for the target, Product. As well as engineering team that they’re working with.
What are the differences between B2B and B2C product managers?
Mario Gerard: Yeah. I think that’s, I think that’s evolving as I think more product managers are trying to be more technical and the expectation is also changing. It’s kind of evolving that space. So, I think we spoke a little bit about a B2C versus a B2B product manager. Do you see a lot of difference between the B2B and the B2C product managers?
Dhananjay Mahajan: Mainly along the lines of you know, the product that they’re trying to deliver, for example in B2, in the B2B space the buying cycle is a lot longer. And then you have different personas, you have buyer, user, and manager. So, understanding that is different. Whereas in the B2C space, their, it be a specific target yeah. Audience, market segment, you know, audience, whether it’s age group or whether it’s gender or whether it’s the region.
Mario Gerard: And when you speak about the B2 B space, and you said that the buying cycle is longer. So, I worked, I don’t know if you know, I worked at Oracle sales for three years. That’s where I started my career. So sometimes the sales cycle, just for other people to know, right. Sometimes these sales cycles take eight months for you to close eight to 12 months is a very normal sales cycle to close one customer. That customer might bring in 8 million or 10 million of revenue or a couple of million, 3 million of revenue. But to make that full cycle, like qualify your customer, then talk to him, show him prototypes, make his management and his entire chain know about it. And to make that actual getting your order in is a long cycle.
So that’s, you know, that’s very interesting that you brought that up.
Dhananjay Mahajan: And you are spot on, that was exactly what I was trying to get that you articulated in much Well and as a product manager, you want to arm your, one of your key stakeholders, which are the sales teams with the right talking points that help them navigate this eight-month cycle, right? On what product and often as compared to B2C, B2B customers buy on roadmaps. Not on the product at hand. Yeah. So, you got to provide a vision and a roadmap that’s three years out. Be credible and realistic and pragmatic that you’re not over promising and under delivering. And yet have something that you can show today that shows that you are aligned in that direction. I mean, that’s one of a, a different challenge. I’m not belittling that B2C doesn’t have this challenge. So, it’s simpler. B2C has other challenges, which is a crowded market space.
In B2 B have a niche, but you want to make sure your niche is still valuable and be able to help your sales teams gate, because if they can’t sell your product and you don’t know what your, you know, go to market strategy is. It’s going to fall flat. And in all cases, it has to make sure that you are increasing the return on investment for the customer. Whether it’s a B2C product or B2B product.
What is a go to market?
Mario Gerard: But when you talk about go to market strategy. Tell me a little bit, I’ve not, I don’t know what a go to market strategy is. What is a go to market?
Dhananjay Mahajan: A go to market strategy essentially means once you have a product and there’s different definitions to it, the way I look at it is how are you going to have positioning for the product, working with marketing and sales, so it can be presented and you have the right sales, the right things for the sales. How are you going to make sure the right channels are enabled? Whether it’s a direct sales channel, where you have your own sales teams, which is possible in a larger organizing, or you’re going through a partner channel, and how do you enable the partners to do it?
And finally, you know, understanding how the customer interaction and the customer journey happens, making sure you have the right metrics in place to take a funnel of customers. Usually, the sales team will come with a funnel and ultimately that arrows down, understanding that funnel, understanding the levers You have to make sure that you can maximize the return on the funnel, how you can lower the customer acquisition cost and yet deliver value to maximize your profits. I think those are the things that make sure you understand, in some larger companies that I worked, I was not even worried about GTM. Because somebody else was taking care of it. I couldn’t even state what price I should put on my product because I was developing like the print button on something.
And there was another team which was doing all the sales analysis, all the, whereas in a smaller company when I was in a startup, I was doing all of it. I was making, understanding the funnel. What were the key drivers, the win loss what kind of you know, battle cards I should have ready at every stage? So that becomes more prevalent in B2B I’m sure In B2C, you also under need to understand, are you going to sell online or are you going to, Is it through a retail?
What are the challenges and difficulties for product managers?
Mario Gerard: A partner model, or is it a subscription model? Is it a direct B2C? And sometimes you can do a B2B, is it like, are there any affiliates involved who are trying to promote you? There are like N number of things I think it’s definitely different from B2C and B2B are fairly significantly different. I’m fairly new to the B2B space. I’ve been doing a lot of stuff in the B2C space, and I can see that they’re very, very different industries almost, and they kind of require a different skillset to some degree. So yeah, that’s interesting. What are the challenges and difficulties basically for product managers? What are the primary things, which you grapple with?
Dhananjay Mahajan: Yeah. So, as we talk to about, you know, a product manager role is kind of Diverse, as well as a TPM role. So, the expectations are different depending on the organization, depending on the customer segment, depending on the market you’re going after.
Mario Gerard: And the product. And the product life cycle. I always think this with TPMS and with PMs it really comes down to the life cycle of the product. Are you building a Greenfield product? Or are you going in and are trying to fix something which has been out there for 10 years? It’s a very different so yeah, it depends.
Dhananjay Mahajan: So, the primary challenge is that vary based on, so that’s why it’s kind of a long answer. But I’ll try to shorten it. It depends on the skills that you bring in and what you’re passionate about. So, some, I’ve seen some product managers being previous developers and engineers. They bring in a whole lot of technical skills, but the other two pillars are also understanding your customer and understanding the business. So, they have a challenge in growing on their customer interaction, their EQ, and he, or she may not have the business skills that are required.
Whereas somebody I’ve also worked with product managers who have come from a business background, they have MBAs, but they have not done technical. They’re great at doing some aspects like pricing, positioning, Communicating value. But they may struggle on the technical side of the product or look at that as an opportunity to acquire that skill. So that’s why I think of those three main pillars, customer facing, technical and business this Should be the foundation that you have and then realize that based on your prior experience, whether you come from an engineering background or you come from a business background, you may have certain growth opportunities where in those areas, in those areas and, and build those along those, you know, customer interaction, EQ, Being a leader for the team, when none of the team reports to and technical aspects in the field that you’re working on and being seen by field, by customers as an industry expert, and then also the business aspects, are you building something that’s going to be viable for your business and viable for your customer. Build on those. And those would challenges.
And I think one of the biggest challenges that is often underestimated by product managers is understanding your key stakeholders and what they need and fitting that need. And to me, the key stakeholders are basically your engineering team without them. You can’t build anything. Your sales team. Without them, you can’t sell anything. So, you can’t keep that engine going. And your leadership and customers who are without whom you won’t get the sponsorship for what your vision is, to make that as a reality.
So, understanding those three, understanding the gaps of where you fit in is really the biggest challenge I’ve seen and being a great communicator and a visionary leader at the same time, being able to do hands on stuff.
Mario Gerard: Yeah. Yeah, one thing you just brought up was that as a product manager, you don’t have a team. And I see that for TPMS too. We don’t have a team.
Dhananjay Mahajan: As in thy are reporting to us.
Mario Gerard: Yeah. Reporting, you might have a product management team within your delivering a large product, but you don’t own the engineering team. You are trying to influence the engineering team to March to your drum beat to a large degree. TPMS and PMs.
That’s a very interesting aspect of this role. Because people need to believe to come to work and do the thing you want them to do. And that’s an innate skill on its own. And that’s why I see the PM the product management and the TPM roles so closely linked. And I also see people kind of moving from the product management side to the program management side and from the program management side, back to the product management side, how do you this?
Dhananjay Mahajan: Yeah. So, you are absolutely right. These are very complimentary roles on some aspects. They have the same challenges, motivating People to work for, realizing your idea. That’s why, even if, I’ve typically been in organizations where I’ve had a product management team, but I work more on a day-to-day basis with my engineering team with, with the sales and marketing teams. And they didn’t reporting to you. So, they’re really complimentary roles. Product manager and program manager roles are overlapping more and more, especially in the agile development. And they kind of, I look at my TPM as my counterpart and we jointly have to be in it together to make sure we win.
Mario Gerard: Yeah. Yeah. When somebody, when people ask me about my relationship with the product managers, I feel it’s like, it’s like a marriage in some sense, right. I used to work with this product manager at a B2C company. And we used to fight tooth and nail because he’s always pushing, they are engineering team, which I’m responsible for to deliver more. His asks are always, oh, I want like a kid in the candy shop, pure example. The product manager is like, I want this. I’ve prioritized stuff for you, but I want all these things done. And I’m kind of pushing back because I don’t want to burn my dev team out. And I also want to be very full, which my team is carrying forward so that they don’t have too much on call.
So, I’m a shepherd for the team. He’s a customer’s voice. And we used to fight tooth and nail, but every day we’ll have lunch together. We had a; we still have a very good relationship. I still meet him for beer every now and then, but it’s a very push and pull kind of a, you know…
Dhananjay Mahajan: Healthy tension.
Mario Gerard: Healthy tension. It’s not a bad tension. It’s a very healthy kind of interaction where he’s trying to push and be the customer’s voice where you try to do the right thing from an engineering standpoint. And it’s a very interesting dynamic. How do you see this…?
Dhananjay Mahajan: I appreciated when I had TPMS to work with, because that healthy a tension, I believe in diversity, bringing in ideas and innovation happening out of it. So I always had my TPM counterpart, like you, Mario, who I could bounce off ideas and I can pull more and then He or she would pull in the other direction while scale agile treats some strict rolls around this, which I’ll describe, I’ll also talk to you about how that tension was actually a better way to do it than a strict roles and responsibilities.
In scaled agile Framework, The safe framework. Yeah. Yeah, yeah. They talk about product manager as you brought up being market facing customer facing delivers the roadmap, looks at the program backlog, kind of how do we license this product thinks about what are the objectives of the, you know, program increment and, and establish this acceptance criteria. Whereas program managers looked at more as somebody who’s technology facing builds, takes those, you know, program backlogs and builds to a backlog of tasks that the team does and delivers on those. And defines and priorities.
There are some good aspects of it because it’s a good clean separation. And especially in areas where they’re very expansive, there’s lots of customers in a large product. It’s good to have, you know, delineation of responsibilities, A B, the healthy tension that you talked about and C, a way for them to collaborate together and build a more collaborative model that will actually ultimately be important for delivering that customer value.
I mean, if I, as the product manager was not giving you and I actually like my TPMS also to interact with the customer.
Mario Gerard: Oh, okay. So, they feel pain.
Dhananjay Mahajan: Exactly. Otherwise, it becomes a waterfall model. They see the pain and then I just need to amplify it as the product is being built. It’s important for you to understand as the TPM, the problem that the customer’s pain point is so that you can work with your engineering to do it. And at periodic points, I think the program manager and product manager often collaborate on reprioritization. Nobody starts with the waterfall days are gone, right? So, what I’ve done more effectively working with the, my product manages or TPM is as a product manager, I would come out with at a high level. These are kind of the key goals for the next sprint. Let’s work on an end-to-end flow of a demo.
And then my program I manager would take that demo, build, use cases out of it, build feature lists and tasks lists, and then at midpoint of the sprint, and at the end of the sprint, we would try to build that demo together to present to the customer. And at the end, we would present it to a customer to say, this is what we built.
I think having that concrete collaborative, single goal actually helped. Even after doing that back and forth, I need you to build these three. And you’re like, no, I can only build you one, which is that one. Let’s get down to that one. Let’s build an end-to-end scenario. Flush it out. That’s our agreement. That’s our contract.
Mario Gerard: Hi folks. Thanks for listening in. I hope you really enjoyed that. This is the end of the part two of three podcasts with Dhananjay, do keep listening. Part three has been posted. Thank you so much.
