Definitely, Maybe Agile
Definitely, Maybe Agile
Product Manager Impact with Shobhit Chugh
In this insightful episode of Definitely Maybe Agile, Shobhit, CEO and founder of Intentional Product Manager, shares his journey from engineer to McKinsey consultant to Google product manager, and now to coaching others in building fulfilling product careers. The conversation explores the challenges of breaking into product management, the critical differences between product managers and product owners, and how to demonstrate true value in an increasingly competitive field.
This week´s takeaways:
- Master the "What if I wasn't here?" question - The most powerful way for product managers to stand out is by clearly articulating what wouldn't have happened without their involvement, moving beyond just keeping engineers busy
- Prioritize product-market fit above all else - If you don't have at least 40% of customers who would "crawl to you" if you took the product away, that should be your only focus until achieved
- Balance execution with strategic thinking - Use the three horizons framework and deliberately make important long-term work urgent by creating commitments and deadlines, while leveraging AI to handle routine tasks faster
Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello, it's nice to be here again and I'm with Dave and Shobhit and it's going to be another exciting conversation. So we normally like to start these off when we have a guest by having our guests introduce themselves.
Shobhit:So Shobit over to you A quick introduction, Absolutely Hi. My name is Shobhit. I'm a CEO and founder of Intentional Product Manager, where we coach product managers towards a fulfilling career. Past background is I was a product manager at Google, at many startups, spent two unfortunate years at McKinsey I'm just kidding and then was an engineer prior to that.
Dave:Sorry, Peter, as you're doing that description, you just snuck in engineer at the end. And so how do you move from engineer into product management and would you say you spent more time as an engineer, more time as a product manager?
Shobhit:I spent a decent amount of time as an engineer, but then I went and got my MBA and that's when I went to McKinsey and after that I moved into product and, to be honest, I thought it'd be like cool, you know, former engineer plus MBA, plus McKinsey everybody would want me as a product manager. I divide pretty hard to land the role, especially because I wanted to target startups, not like big, huge companies at that point in time.
Dave:So, and that also sounds to me like why you have such an affinity for identifying as a product manager and making yourself kind of hireable as a product manager by the sound of it.
Shobhit:That is the yeah. That's sort of the origin story of how I ended up as a coach, because it is a role that it's sort of coveted and it's sort of like, you know, unless you are already a product manager, people are like, oh, can you really do the thing, yeah. And and other people are like, oh, you can't move into product management. I'm like, well, how come there are more product managers like Like, that's you know, just logically.
Dave:Where did they?
Shobhit:come from. Exactly, exactly. And the number of times someone has said, oh, I don't have a typical background as a product manager, I'm like, okay, cool, I've heard that all the time. Because there's no typical background.
Dave:Right, exactly, there's also been a shift, because I can still remember years ago working with organizations where they didn't really have anybody in product. I mean, the whole role of a product owner on a scrum team kind of came out from the fact that there is nobody that we can go and kind of sit down and have a conversation with who really understands product. Let's create that role and of course that's changed over the decades that that's been up and running. But there is a shift now where product management seems to be. I mean, are you seeing that Like everybody's looking for product managers or do you still see scenarios where there's really no product manager in sight?
Shobhit:No, I actually see increasing number of product managers, including at some highly tech forward startups where, like their higher number six was a product manager, and you won't expect that because, like I would say, less than 20 people, either the ceo or the cto, as a product manager, like one of them is, is leading the charge. In this case it was different and I do think it is because ai is making engineers very effective and so you actually can move faster, so you actually need more product management input. So lots of interesting stuff going on in the world of product management.
Peter:I mean, that's definitely something I've seen in organizations some quite large organizations, where the bottleneck isn't even technology. The engineering can get things done, albeit maybe not as effectively and smoothly as they might be able to, but their bottleneck is they can't get to a product owner or a product manager who can help guide them or give them insights or be there to answer questions. There just isn't enough of them to go around.
Shobhit:Yeah, that's quite interesting.
Dave:Can I maybe drill in? So we spend a lot of time working with product managers, product owners, product groups, and maybe I'll just start with a really like a question that's on many people's minds when we start looking at that, which is do you see a difference between product managers and product owners?
Shobhit:Yes, I definitely do, Although the titles are all over the board in the sense, like the core difference I see is there is somebody who's making a decision on at a high level what the product roadmap would be, and then there's the execution of that and translation of that into features and user stories and other things, that decision on what the high level roadmap would be. If you're making that, you're sort of in product management. If you are not making that, and you know business is making that decision, then you're sort of more in a product ownership role. But I've seen enough cases where somebody has a title of a product owner and they're doing everything, and somebody has a title of, like director of product and yet they're not really really doing that. So that's all over the boat.
Dave:Yeah, it's a peculiar market, isn't it? Because you've got to dig in to find out a little bit more about what the role entails and what the expectations are.
Shobhit:And it's quite tricky because the hiring manager or something they really want to hire you if you're good, and so it gets sold as oh, yeah, you have all these things and everything's going to happen and it might not.
Shobhit:it is tricky, I often feel, for people who are going into an unknown organization and then you know you're like they're putting the best, best foot forward whatever the best show and and it doesn't turn out well, we started this conversation with you just before we were recording about the idea of what makes some product managers stand out and why some get overlooked, so do you want to talk a little bit more about that?
Peter:introduce the topic.
Shobhit:Absolutely. Let me see the common thing I hear Anytime you hear a product management talk about them, let's say, in the job market it's number of years of experience. And while I truly believe that you learn and grow a lot with the experience, it's really the quality of experience that counts. And I think when number of years of sort of number of years of experience is sort of a commodity not exactly, but, but still um, it's how you position yourself makes the most difference. And, like for me, the single most powerful question for us man just can ask to do really well, to stand out, is what would have happened if I was not there?
Shobhit:I think, peter, maybe you mentioned that they would like they used to be. You know you could have teams without product managers and true engineers will build something, designers will conduct user research and something will be designed so product can get shipped without you. So somebody who's really good at explaining why their role was that critical and what would have not happened without them, I think stands out above anything else. So yeah, I just find that quite interesting. I don't know if, peter and Dave, you see similar things or you see something different.
Dave:I'm kind of reflected just thinking about that question, because it's very humbling, I think, in many cases, because of course you've got a backlog, Perhaps the roadmap is pretty clear as to where it's going. There's a strategy and you've got a few years to implement something. As a product manager, you can keep very busy with a lot of that information coming in and do a bit of customer experience work or user experience work to tweak a few things. That's very different to really keep very busy with a lot of that information coming in and I do a bit of customer experience work or user experience work to tweak a few things. That's very different to really leading a significant sort of either leap forward or identifying and serving an underserved market or whatever it might be. You know, just extrapolating beyond that roadmap and the original vision that you may have inherited.
Shobhit:I mean, it seems what you're saying also, that if a product manager is seeing their job is keeping the engineers busy, it's just not going to work out well. Yeah, so that's going to be a challenge for sure, yeah.
Peter:The broader sort of product management role of understanding what are my customers' needs. What are the more valuable pieces for me to building out? How does this align to what the business strategy is and the objectives? Are all of the stakeholders in the organization aligned to what I'm trying to build out? A lot of these sort of key functions and capabilities? I know that Dave has all sorts of materials he teaches people on how to build good product management practices and capabilities. What sort of things have you seen that are really key elements? Shubit?
Shobhit:I'll probably say three things. So number one you mentioned about alignment there is sometimes overemphasis on everyone needs to be aligned. Sometimes overemphasis on everyone needs to be aligned and you might really need to be the person who says, ok, I cannot get everyone on board, so let's, let's make sure a decision happens and we move forward and we sort of get, you know, use enough organizational influence to sort of get to the disagree and commit aspect of it. Otherwise, I mean I experienced this quite a lot at some decisions in Google like it just would drag on forever. And you know Google's fantastic in many things, but sometimes things work quite slow. So I think that's a critical element of that.
Shobhit:I also do think that there is like a term called alignment decay that I sort of reread today and the idea being that you know you can like people just forget your product roadmap is not top of their mind. If you're not constantly communicating why you're doing this, why is it really important? What does it lead to? There will be that misalignment. And I also found it interesting is that your engineers would be less productive because emotionally they're less bothered A misconception. Is that cool, you know? You tell them this is what needs to be built and they'll sort of get it done. But when you get your team really emotionally bought in on, really like actually like part of it is, you get out of the way and you get them in direct contact with customers and have them see the customer pain points and sit in and customer interviews fantastic things happen when that happens I'm just smiling because I I'm picturing in my head the times when I'm sitting there right next to the engineers whose face has dropped as they're looking at the customers trying to find something.
Dave:They're going. It's obviously here. Why can they not see it? Or whatever it might be. I mean, it happens so many times when you get those two groups together and have them observe what's going on.
Shobhit:Yeah, that's quite interesting.
Dave:I think you mentioned three things, and I interrupted at the end of the second.
Shobhit:Now I can't recall the third thing, but you know if it's good enough it will come back to my mind at some point.
Dave:So if you're talking to an organization and describing what you expect the product manager's role to be maybe they're about to hire or they're looking at elevating somebody to that role what are the things that you really think are absolutely critical, that that product manager has to be able to demonstrate they can do?
Shobhit:The way I'm looking at it always is that the hiring manager wants to minimize risk. That's sort of the biggest thing, because a mishire is just months of wasted effort, time, a major dash to their reputation. So what I'm really trying to understand is actually the other side. What would make this person fail? Is it certain organizational dynamics that they need to be really good at working with? Is it a very complex area, like somebody getting into healthcare, where if you don't have prior knowledge, you won't be able to succeed there? Is it a personality thing, like, hey, you're in a small organization with the CEO is extremely strong? Is it a certain way of working? So that's what I try to figure out, plus combining.
Shobhit:You know, when you talk of, like, a product manager coming in and trying to succeed, everyone knows the first 90 days are very useful and you know you've got to do quick wins and whatnot. But the core challenge I see is actually not so much that people are not going to have impact, is that they try to change things without getting enough context, you know, and it sort of becomes oh, we've heard this idea a million times. It didn't work. I use the analogy of you got to roll the ball downhill and build some momentum before you start to push things uphill. So you know, figure out ways of going with the flow and then succeeding. And one of my mentors used to say in your first few days, if you're a good anthropologist, cultural anthropologist and a historian, you're trying to understand the history of the product, you're trying to see these people and understand how they interact. You will succeed.
Dave:If not.
Shobhit:It's sort of like yeah, just not going to happen. Those are some things I see in like when I talk to organizations.
Dave:Yeah I really like the way you're kind of spinning that. It's almost the the shape of the jigsaw puzzle whole, not the shape of the jigsaw puzzle piece you're really looking at what the fit is going to be. That's a.
Peter:It's a great, uh great takeaway from that there's a let's say this, I was just thinking about it chesterton's fences. Isn't that a example of it? The concept of chesterton's fences was that you need to understand why the fence is there before you tear the fence down. So it was to do with a historical uh piece of something about that, but it's basically the. If there's a rule or offense, that uh is in place, you've really got to understand what is the impact. Why was it put there? What were the reasonings behind it before you?
Shobhit:Yeah, how did we get here in the first place? Exactly, that's a really good analogy.
Peter:Sometimes, of course, we do run into the rules that well, why don't we want to do that? Well, because this one time, 15 years ago, it went wrong and now we have this rule and that's why it's here. Well, maybe things have moved on and we can change.
Dave:Can I? I just want to expand a little bit on the responsibilities of a product manager. So, as you can probably, I spend a lot of time working in that product area and one of the things that we talk about an awful lot is product market fit, and it's almost set as this easy goal, Once you you know your role as a product manager is to figure out product market fit, and then the world lightens up and it's pretty obvious where you need to go from there. And it's pretty obvious where you need to go from there. Can you share just a little bit about what your recommendation is, insight or experiences with trying to achieve product market fit and what the role of the product manager is in doing that? No, that's.
Shobhit:I mean, actually I agree with the overall statement that, hey, like, if you don't have product market fit, that's your only job. Nothing else really matters. But let's try to understand actually what it is in the first place. And the best definition I've seen is this guy, rahul Vora, who has built this email app called Superhuman, which makes people pay $30 a month for email, which is built on Gmail, and Gmail is totally free. They they managed to do it, but it's a phenomenal app says look, if you, if your customers are using the product and you tell them, okay, you can't use it anymore, how many of them would like crawl to you and like figure it out, like grab the product out of your hand? So if it's at least I think his rule is 40% of people are there, then you've hit something. If it's not, then yeah, there's no product market fit. But the thing is that and so I agree with that definition the way you get there I wish it was that straightforward, but it's like constant trying and pivoting and figuring out what really works.
Shobhit:Obviously, the big, the biggest fatal error is you just don't understand the customer context or the problem, and so you're building a solution for something that's that's you know, just you don't understand. Or there is the it's I think it's called spotlight fallacy where you you ask a customer, oh, like, keeping track of your workouts, how is that? Oh, it's really frustrating and whatnot, and so you build an app for that, but really like, in the context of their life, it's a minor problem. They're not going to even pay you $2 a month for that. So I think it's a problem. Understanding and really how important it is in the life of a customer is the first thing to product market fit, which is where often things fall short.
Peter:Yeah, Asking the question of would you pay me for that? If I gave you a service, what would it be worth to you? Right?
Shobhit:No, I agree, Would they pay? And I mean also, people love to please you, so they might even lie. So make them do something. We had this asset test where we were like, okay, awesome, we're going to have the demo ready on this date. We need an hour to walk you through this. When can we find time? And if they were like, oh, like, I'm not sure I'll get back to you, it was like a negative signal that, okay, while they're telling us it's awesome, they're not even willing to spend an hour walking through the demo. So, like, really making them do things helps quite a bit.
Dave:Now I'm sort of building on top of this and I think we see this less and less, but I don't know that it's really a headache. On the product management side, I'm going to talk about data and decisions driven by data, but sometimes it's not the product manager that struggles with that, but overall the leadership in an organization, Because product is one of those things that we all have a view on. Right. We see something and we go. We want to go this direction, that direction. So of course, as a product manager, we want to be using data, Any things that you look for warning signs around product managers or helping kind of hints on how to help them use data to make great decisions.
Shobhit:There is a time and place to use data and when you're early on, like trying to find product market fit right, you are limited in the amount of data. So there is a intuition-driven decision-making as well. Three best practices. One don't optimize for vanity metrics. Daily active users, something, something. Number of downloads Okay, got it Directly correct. Not very useful. Second measure what really shows customer success? If you're able to say, okay, this customer was able to, within three minutes, achieve this goal seven times awesome and counter metrics of that. And then third is I do think there's some obsession on like, hey, this is exactly the metric. Just find something that's good enough that is measurable, because every metric you put has an engineering cost to it. You need to log the right things and then build those out and whatnot, and so treat it as a feature that, okay, this is going to be a lot of work and maybe just semi useful as compared to something else. So you have your metrics backlog that you prioritize.
Dave:It's a lot of sense, yeah and getting buy-in from your stakeholders around that. Have you seen things that you kind of looked at and thought I've got to make sure we use that more?
Shobhit:yeah, no, no, definitely it's. Uh, I mean, getting a buy-in up front on those metrics is critical. I do feel you can convince them. Ultimately, I don't think anyone's going to care about your product metrics much at all, unless it translates to something good when they look at it.
Peter:Yeah, helping them relate the two, I think, is a critical part of that communication. It's like every time this goes up by one, we make more money. Yes, exactly.
Shobhit:Peter, you nailed it Actually, peter. I think that's a really good point. How does it translate to money? That should be the end question.
Dave:Well, and these are things that can be difficult. So what we're seeing a lot of the time is more and more at least in our experience more and more sort of customers have already bought and they're managing their experience with a company, so that's their account management portals, slash apps or whatever it is.
Dave:So there the the tie-in is through retention, through churn rates the churn rates low and so on, but of course they're maybe 12 months out, right. So there's this really weird chasing of engagement or involvement or active activity, which is, as you said, a vanity, towards an end goal. That's a long way away.
Peter:Yeah, that balance between well, it often depends on your cost of acquisition, right? Because if it's really cheap to acquire new customers, then you don't necessarily worry as much about the ones that you lose.
Dave:But that's I was going to say where do you find cheap customer acquisition costs nowadays? But anyway, yeah, depends.
Shobhit:Actually I think both of you mentioned this like the time, delay does kill a lot of things because it's easy to. I've made this mistake of okay, you know, customers are still happy, even though this is not working very well, let it be. And like three months later they were like really unhappy and like it had built up over time and I was not aware of that. One Probably one of my bigger mistakes as a product manager.
Dave:But it's almost like these things trend in and out as well, of course, because I have no idea. If you're doing tax software, then of course nine months of the year nobody cares because they're not using the tax software. So there's things like that which just can kind of trip you up. If you're not really aware of the year, nobody cares because not using the tax software. So it really, you know, there's things like that which just can kind of trip you up if you're not really aware of the cycles, that's in the seasonality well as via seasonality, and that can occur in lots of ways, even with, like shopping seasons, or how often do you go on thing?
Peter:are you on holiday? Is your app related educational sorts of things, right? You know this is reminding me of a funny story. Every how often do you go on holiday? Is your app related to education All sorts of things, right.
Shobhit:You know, this reminds me of a funny story. Every May or so, we used to see a huge drop in metrics in my last role and we would always wonder why it was. And there was some holiday in Europe that would relate to that. And every next year again we had forgotten that that holiday was coming. And again we are like scampering and thinking what's going on here?
Dave:And I just wanted to. I'm just thinking of the product owners and product managers that I'm working with or I have worked with. There is a tendency because if I think of agile delivery sprints, I've got the next two weeks and the next two weeks, so it's so easy to get dragged into execution, that focus on the next sprint, the focus on my quarterly objective and what we committed to, and so on that execution kind of cycle. How do you grow your career if you're in that world where you're really driven through execution which, of course, many of us are because workloads never go down, they only go up, it seems. So what would you recommend for product owners or product managers in that space?
Shobhit:Excellent. Number one you have to get ahead. I mean, sorry, that's the end goal. How do you question is, how do you get ahead if you're trapped in execution? Number one I have I was.
Shobhit:I've been always pleasantly surprised that all the things that I was wanting or I was wanting to not do, there was somebody on the team who really wanted to do those, and so getting time back by finding people for whom this job or this particular task is like the next step forward in their career. So you know, for example, very technical product we were building, we were changing our SDK and whatnot, and I really didn't want to get into like designing APIs and whatnot. So I just asked the team, hey, who wants to do that? And somebody who wants to be a product manager eventually was like, oh cool, I would do it. And this person did a fantastic job. So, realizing that there's probably more available in your team and people are inspired to do that work, I think it becomes really helpful. Then I think you also have to do the flip side, which is you have to sell the value of discovery and being one sprint ahead as far as discovery is concerned, sometimes by just selling the fact that you weren't ahead earlier on and that resulted in all these things, and you never want to avoid that. Dave, you were mentioning product owner and manager.
Shobhit:Like one of the things that you do want to work on is your long-term roadmap and, at the same time, anytime you put a do not schedule on your calendar, people are like cool, that doesn't mean anything, let's do a meeting because we got to do this. So you got to put very specific stuff like hey, sorry, I cannot meet. Urgent always beats the important. It's my belief. We don't want it to. So you got to make the important urgent, and the way you do that is, you know, you could just say, okay, awesome.
Shobhit:So I got to do this roadmap presentation to my manager because I committed to them and you commit to them, and so now the time is on your calendar because this presentation is coming up and then you can actually negotiate that time to do that. So that's just always a consistent activity and I do think AI can help quite a bit, like the amount of things now that can be done super fast. I am always pleasantly surprised, yeah, so I product managers sometimes take go to ai from a perspective. I got to know all the models and I got to know like everything like that and I'm like just use it to get your work done faster. That's the first thing. If you do that, you can like go from there.
Dave:So that's another thing I'm pausing now because peter's gonna have a perspective on AI. You've opened up the can of worms. Now Shobit. That's awesome.
Peter:Really, really. Did you see the one a couple of days ago? Absolute Zero, which can train itself, so we don't even need humans anymore.
Shobhit:I haven't looked at it we always drop that one.
Peter:That's where it starts to get interesting. But yeah, I mean, I think for a lot of people, just the capabilities that AI enables to help them solve problems and to remove some of the toil out of what they have to do on a day-to-day basis. It's phenomenal and getting better all the time. So it's very interesting to see where that goes, and I can definitely see how it fits into the product management space and helps you build out roadmaps, craft messages, communicate better, define requirements in a better way. There's lots of great things that you can use AI for.
Dave:I'm just thinking. There's an element, though. We're just talking Shobit about the responsibility of a product manager to look at their long-term roadmap and to think into the future, and the reality is most products that people are building right now are going to be shaken up in some way through the application of these AI tools, and you know all of this sort of changes that are coming through. So there seems to be or at least what we see a lot is ignoring that fact that the thing that I'm spending the next 12 or 24 months building out and creating this product could be turned upside down any time if we're not keeping an eye on it. So it's interesting and there's no obvious answer, of course but how you kind of balance that need to keep an eye on things that are going on, use the tools a little bit to be familiar, but also just being trying to think outside the box as to what it does to your product.
Peter:Yeah, can an AI do what my product does already?
Shobhit:I mean, but I do think that that's always been the case, Like in the sense okay, it's AI now, but it was cloud when. I was still with companies building on-prem software when cloud took over everything. It's always been the case. The next wave is coming.
Dave:Yes, yeah, well, now I mean, there's an argument that the timelines are shorter. Yeah, but even if that's the case and I think you're absolutely right how much time should that product manager be looking up and around and raising their eyes to the horizon or to what's just beyond the horizon versus? You know, they have many, many things that they could be building and they could get their head down and they can have a 12 or 24 month roadmap full of functionality that is of value. So is there something I mean, maybe, if you've got some experiences or something you can share about that, what does that look ahead, look like?
Shobhit:I. I think that's actually a very difficult problem to solve. Like you know how much time? Generally, the tendency is to keep that to a minimum because everybody's concerned about the, the current thing. But as innovation cycles go up, that like move faster, you just got to have longer time horizons. In some sense, probably what's worked best for us is thinking in terms of three horizons, using the three horizons framework. It's like okay, cool, not so much about timelines, but what is the next huge market or customer problem this product could solve? If we could undo a lot of the constraints right now and then, if we undid this even more, what could it solve or what could it grow into? And as long as there's alignment around that and you're starting to divert some investment towards exploration and creation of that, I think things work. I think it. You know, the problem is when there's zero investment there and then suddenly you just hit a tipping point where holy cow, now we're going to do something, yeah well, and then it's all my.
Dave:Then it's a whole different world of pain, isn't it so yeah, yeah, well, no, I think I think we're at time.
Peter:So, uh, it's been a pleasure, as always, and we always like to wrap this up with some points for our audience to take away. So I'm going to start with you, dave, what point do you want to take?
Dave:away. So maybe, as I'm just thinking through Shobit, you've covered such a range of different things and I think something that's very close to my heart I asked the question about it is around that product market fit, and I think something that's very close to my heart. I asked the question about it is around that product market fit, and what I really took away, or one of the statements you made around that is, if you don't have product market fit, that is your only priority and I think that's again I'm just thinking of a number of the product professionals that we've worked with where you kind of get the feeling they're definitely not going to get 40% of their product, of the customer base giving them a call if they said we're cutting it off next week. So there's definitely. I think that is a takeaway. That is is almost quite a sobering reminder of exactly those foundations that have to be in place.
Shobhit:Shobha, my biggest takeaway would be make sure what's really important for your product from long-term perspective and just figure out how to make it urgent and make time for it, because if you don't, things are moving really fast and your product will be useless and, you know, could be done by AI, as Peter mentioned in a little while.
Peter:Okay, I think for mine, because it reminded me about it.
Peter:I'm going to go with the Chesterton's Fence one, because the new product owner coming in and you need to understand what something is before you start to tear it down and that doesn't just apply to product management, that applies to practically everything. You really, before you start making large-scale changes, really understand why something is there, because it might surprise you. So thank you both. A fantastic conversation, as always, and people can reach out if they have questions feedback@ feedback definitelymaybeagile. com, and it's been a pleasure. So thank you, dave, thank you, thank you.
Dave:Thank you very much. Thanks, Peter.
.pdf.png)
