Does Product Operations deliver a return on investment? | Amit Godbole

In Episode 8 of Talking Roadmaps, Phil Hornby interviews Amit Godbole to explore whether Product Operations delivers ROI. They dive into how Product Ops supports data-informed decision-making, roadmap facilitation, and scaling without chaos. Amit shares insights from working with top-tier banks and B2B enterprises, highlighting the balance between process, tools, and intuition. From compliance alignment to co-creating with early customers, this episode offers a deep dive into evolving product practices.

Amit is a fractional CPO and product & pricing enthusiast, helping organizations build segment-winning products. With over a decade of cross-functional  Product leadership, he uses data-driven strategies to help teams quickly adapt and succeed. Passionate about product communities, he also coordinates about 50+ ProductTank's in APAC. 

Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).

In the next episode we are talking to Graham Reed, Head of Product Ops @ Helios. So watch out for Season 2 - Episode 9!

• Transcript

  - Product management teams are required to ask the why. They work around the why part or the problem side of the world, trying to work with the customer, trying to work with stakeholders on understanding how they can deliver value to the customer consistently. While the product management team focuses on that, the product ops team ensures that the product management unit is running like a well-oiled machinery. And if you are able to run it like a well-oiled machinery, that I think is biggest proof or ROI that product ops is a success for you.

  - Welcome to Talking Roadmaps Season two, where we're here talking about product operations. Today, I'm joined by Amit. Amit, tell me about yourself.

  - Everyone, this is Amit and I'm excited to be your guest, Phil. The years being into product management, coaching, consulting and communities, passion aligns in creating product culture where everyone, from leadership to individual contributors, are building towards common vision. Definitely thrilled to kick off this discussion and what lies ahead of guests, and I can't wait to hear your perspectives.

  - If you're enjoying the channel, subscribe, hit the bell and give us a like. Well, then I'm really pleased to have you. I mean, Amit, I think you downplay yourself a little bit there. I know how heavily involved you are with the product community in Asia Pacific through Mind the Products where we met. And I know that you're doing some great fractional work these days as well and building a whole product organisation out. So I'm sure you're gonna bring some awesome insights. I'm looking forward to it.

  - Yes, I feel product ops roadmapping, product roadmapping is important and one of the crucial aspects of every product management journey. One the reasons why I feel why do we need product ops or roadmaps is that we want to centralise our processes to standardise workflows. We want to have better collaboration and we wanna build data-driven decision-making. Product ops helps do that by standardising metrics, by tracking and analysing things, ensuring product managers have the insights they need. So I feel that why do companies need product ops is as they grow, as they scale, A, product ops lay the groundwork for consistent product development practises. Without it, growth can lead to chaos.

  - I mean, Amit, you've got ahead there. You've answered my first question without me even needing to ask. Why do we need product operations? I totally agree. I mean, I think we hit three of my favourite things there. We hit roadmaps, we hit decisions. Like I'm a big believer in decisions, although you did use data there, Amit. That to me is a little bit of a interesting one. I tend to use the phrase evidence-informed these days. And the reason for that is because I think there are three aspects: there's both the data, the anecdotes or the feedback, the qualitative and the quantitative. But I think we also need to remember as humans, we've got our intuition that we've gotta think about as well. Like the reason that we are product people and that we do this work and we bring some of that skill, sometimes it gets covered up in this phrase of product sense, which I hate, but it's ultimately, it's like bringing that intuition, that kind of even critical eye that we bring as a product person to looking at those two different types of evidence, and thinking about what should we really do as an organisation. But I think we're really saying the same thing, it's a taxonomy thing sometimes or semantic thing.

  - I like what you say, as evidence-informed, and I have been advocating good product teams are the ones that make decisions faster and more often. Good decisions can come based on absolutely data for sure, but also based on intuitions. I think as Jeff Bezos or somebody famous said, that we are waiting for 100% of information to make a decision, we're already late.

  - In fact, that sounds similar to wisdom of Colin Powell, I think it was, who was U.S. Secretary of State. Said, "Act when you have 70% of the information you'd like to have, but not less than 40. 'Cause if it's less than 40, you're just guessing, and over 70, you're just going to wait too long." So I totally agree. So you're kinda framing product decision-making is a central thing that product operations supports. Is that right? Is that your thought process?

  - I think product ops, product thinking must revolve around how much of data we use and how much of integrations we use. What is a healthy mix of these, while building roadmaps or while building entire metrics. Companies tend to, growth companies that I have seen, to grow into analysis paralysis where you are looking for too much data before making a decision, and that slows growth or that kind of leads to even missing out on opportunities. I feel building the mix of intuition-driven decision-making helps you get into the right mix.

  - One of the phrase you used there earlier as well was a good decision. Do you know you're making a good decision in advance?

  - Interesting. And we talked about one of the clients I worked with. We were working for one of the top 10 banks in the world and were asked to build an amazing piece of feature which we should, it was an on-prem feature. It was not part of our roadmap. However, we took a decision, build that feature for this particular client and see that if there were other customers who were wanting this feature. We had gone viral since, you know, reaching out first five customers who needed before even building it. We would've probably not been successful. So we co-created this with this one customer and then took it to five customer, which I feel was a good decision sense. Yeah, then the reference gave us other customers too.

  - I think you're hinting at some interesting large enterprise B2B, should we say patterns I also see. Reality is they're an oligopoly. The markets have as few large powerful players and you have to recognise that time to do as they ask.

  - That's another way to put that, yes.

  - I worked for best part of 25 years in automotive. It's the same, there are 20 car companies in the world, but they exert a lot of power when you're a supplier in that industry, and sometimes you have to do what BMW, what Tata, what Hyundai, whoever else is asking for. But the reality is you know that they are following trends as well in their market, and the chances are that the competition in their market are gonna have some similar needs. You go and look for those larger opportunities, but sometimes you've just gotta flex because actually winning one of those customers is probably still enough to make the business work. And it's probably an enhancement that goes around the broader products. So sometimes it can make sense, but also I think it was Daniel Elizalde in the third or fourth episode of season one. He talked about using the first 10 customers as your proxy for product market fit. I've seen industries where you can actually make that a much smaller number. I would say two or three in automotive is easily enough. And similarly, I've worked with a fintech recently where it's about three that they could use as that similar level.

  - This goes on number of customers, and I feel could be newer ways of working and while building product management or still ensuring that you have a product market fit. Co-creating with customers and then ensuring that you have one successful outcome with one customer is also an approach towards promoting your products or ensuring you scale up an existing market. I operate a lot in India and we have only about 20 to 30 major banks. That's our overall industry size. So companies takes building in this market have two only, that's our market size. Or maybe if it is Amazon or retail, there are just two or three big players.

  - So it's very similar to my experience in automotive. First question anyone asked you in the sales cycle was, they'd say something like, "Great, that looks awesome. Who else is using it?" That case study was the key thing. You had to get that first reference customer. If I could say to VW that BMW was already using, it's like tick, okay, big German company is using it, we trust it, let's get move on. If I could say Tata was using it, big international automotive company, yeah, we can probably trust it. Let's move on. Now let's get into the real interesting conversation. But that was almost like a gateway to have some of the conversations that somebody else was using it. And so that need to find that reference customer with a level of co-creation was useful.

  - I like how you say about automotive and then creation. After you've gone through this first part, that's where the real magic happens because there's a chance that you are not building completely, you're building completely different solution. Do you ever come across those things?

  - There was always a challenge. In that particular industry, we actually set our organisation up on what we call the platform and solution structure. So the platform, we built the Lego blocks, and the goal was to have 80% of any solution in the Lego blocks. And then the solution team could assemble a solution, go direct to market, and the platform team would support any conversations where we were going through the OEM market, so dealing with the large companies. And then we'd have a professional services team that could actually do that tailoring, that tweaking of that last 20%. So we had to set the organisation up to be able to serve that model to think about what are the layers of, you know, what's core, what's optional, what's configuration and so on. So we kind of, you have to design your organisation to deliver in it. We've just taken the risk and we've gone down a rabbit hole, which is decision-making, which is a particularly interesting one. I'm sure we'll circle back to it. But let's bring ourselves a little bit back to product operations. So we've kinda talked about why companies need product ops. How have you seen it set up differently in different organisations?

  - Varies widely. The short answer is some organisations have a dedicated ops department. Actually the larger ones, there's distributed product ops responsibility amongst existing roles. So I have seen for a while that typically APMs, yes, are doing a lot of work which product ops team have to do with the product. Although the common pattern is APMs or PMs who take care of work of product ops in smaller organisations and then the bigger ones are dedicated. Usually the reporting lines are towards the PM or the chief product officer or sometimes even to the chief strategy officer if you have a dedicated department. Yeah, that's what has happened in my experience.

  - Interesting, yeah. I mean, so I'm definitely seeing that rise of the more dedicated function, but equally for a long time it was something I recognised that I and members of my team used to do as organisations.

  - And yeah, yes, sure. Did you also kind of have for the red line to COO or red PO?

  - Yeah, I was the highest point in terms of product leader, and so there were parts of it that I was taking care of, like our ways of working through. So it was something I took care of as a product leader, whereas there were things like the data side that one of my team was doing. And so that was kinda like the distributed version of it, I guess, before we had a name for it, before product ops was a thing, should we say. And I think that's really the thing, it's a trend over the last, let's say five years, for it to be an emerging function, I would say, of being there to enable it. It's interesting that you mentioned APMs doing some of the work. So when you say the APMs often end up doing some of that work, what sort of work is it that they're doing?

  - That's an interesting question and that's something which we've been seeing work as well. But typically or the key responsibilities, what our product ops teams have is around process management, are finding what are the product development process we should follow and running a sprint rituals, having those product launch checklists, to some points even writing release notes and product. They work more on the tools and tech administration, especially managing Jira or any roadmapping software or analytics software like Hotjar and others, Amplitude and Mixpanel and Pendo. So ensuring that these tools, we are getting the analytics in timely manner, and particularly, is what typical product ops work would be. Also these teams, an integral part of governance and compliance, what you would call, especially around standardising how product team documents decisions, handles approvals, it's customer onboarding, working with internal different teams on roles and customer onboarding. So in one of the companies I'm coaching currently, product op teams works closely with the technical writers in the team and helps them manage the user guide or gives information on product features.

  - Interesting. So I wonder and this possibly is playing a little bit into something I see as a bit of a anti-pattern, but is there a risk that that people who are labelled as product ops are essentially being assistants to the product managers?

  - There should not be a risk as long as we have leadership ensuring that what a product ops team works and what product management teams works, and there is collaboration between these two teams. Though, I see that ops teams, if they over-engineer process or they ignore feedback, there is a good chance that they could overlap.

  - Guess I was thinking in particular in that context of the distributed responsibility, not something where you have a dedicated team, but where it's the APMs and the PMs taking on parts of it and potentially if it's more towards the APMs, are they essentially being used to do the work that the product managers don't want to do as opposed to enabling, what's your thoughts there?

  - Yes, we do run risk of that. Product ops, they can become mid management and vice versa over in the teams there where there is distributed responsibilities. And see this also as an opportunity for product ops team to learn about product management as long as understand that this is a part where they're collaborating and not part of still day-to-day job. Yeah, we do run the risk there.

  - I think so far I've heard examples of responsibilities of enabling better decisions through making data available and kind of ways of working. What else in terms of responsibilities do product operations look after?

  - Most important thing the product ops does is quickly improves collaboration, with product managers, with different departments, and be gathering insights for product successes, what are the ways a product and where product is running. They also top run cross-functional meetings or if there are any product rituals. Especially in small companies, take a lot of administrative and operational tasks of product manager's plate so they can, product management team can focus on discovery, strategy, execution or whatnot.

  - You talked about running rituals and things. Like does that then start to overlap with what a Scrum master might do?

  - Free is kind of a friction point of what a Scrum master might do, activities, product order might do, but then having clarity about roles, what a Scrum master does and what product ops does, vision, kind of crucial to avoid duplication of effort. And master does a lot of things around ensuring that strategy followed well and teams they have their own KRAs and KPIs. Products ops helps in writing some of those rituals.

  - Maybe you can gimme an example of the types of rituals that a product ops person might drive as an alternative.

  - I think definitely running the sprint, being in the roadmap planning meetings, taking up some of the administrative and operational tasks of cross-functional meetings with the stakeholders, with the sales team, or with the marketing and technical writing team is what product ops can do. Take off the plate of product managers.

  - It's interesting 'cause I'm hearing some of the things that I love doing as a product manager, and so I'm feeling that there's a risk of us ending up instead of collaborating, fighting. There's maybe some friction or overlap. What are your thoughts around that?

  - There is an overlap in what a product ops does and product manager does. I think the question you are asking is, how do we ensure that, and you can think of this as an overlap or you can think of this as a . Product management and product ops are working together to build a successful product. So that is a tangible ROI just having these two roles as separate, product management and product ops, so that you can have third product delivery, you reduce miscommunication and have less handoff errors that kind of benefits the company's bottom line as well. And there could still seem when mood switch can be played by product management, but having them and product ops taking up lead and streamlining processes, we can free up product managers to focus on, you know, high-value activities: vision, strategy, product mapping exercises.

  - Unless, I mean, I love that 'cause you've gone to where I was going next. You said there's an ROI for product operations as a separate function. How do we define that ROI? How do we really justify the existence of product operations?

  - Well, that's a very interesting question. Why do we need to have a product team when we can upload our product managers with some of the same work? Maybe let's call it, why do we need have a separate department of product ops? Because helps us increase our productivity. Product management teams are required to ask the why. They work around the why part or the problem side of the world, to work with the customer, trying to work with stakeholders on understanding how they can deliver value to the customer consistently. While the product management team focuses on that, the product ops team ensures that the product management unit is running like a well-oiled machinery. If you are able to run it like a well-oiled machinery, that I think is a biggest proof or ROI that product ops is a success for you.

  - I love it. And I loved the analogy of dancing. You wouldn't realise it while looking at me now, but I used to actually be a competitive dancer if we go back long enough. But yeah, so that kind of metaphor of thinking about it, it resonates well with someone who loves dance.

  - I am not a dancer, but my wife is a Zumba instructor, and yeah.

  - That's good.

  - I dunno whether whether it's... It borders dancing and exercising, so some days we do that and yeah, it's fun.

  - There's something very primal about moving with rhythm as a human, comes really to our kind of our core existence.

  - And I think this rhythm, when companies see that within the product management department, between product ops and product management, that can then be a little infectious and then there are other departments which start following the rhythm. Or maybe product ops is a department that tries to bring a rhythm within a company, within a product management, company unit, and within the company as well. Think of it as your zoomba instructor trying to tell everyone how to, you know, how to go into those moves.

  - So we're obviously a channel that talks about roadmapping, and road roadmapping has a rhythm and a cycle to it. And you've talked about possibly product ops helping facilitate some of those conversations. Really, let's go a bit deeper. How are product ops involved in roadmapping? Because I can't not talk about it with a channel called Talking Roadmaps.

  - Yes, and yeah, I was wondering, when would this question come up about roadmap? When are we going to talk about roadmaps? But, so yes, product ops, I have seen that they play a very, very important role in roadmapping, especially in data collection, data consolidation. These teams collect data not only from stakeholders but from tools like Hotjar. You get user information, you get your clicks, you get information about your product, and then is putting that to make those decisions and a roadmap prioritisation. They also would do that and, you know, existing roadmaps are aligned to what our customers needs are.

  - I'm a big believer that roadmaps are really an articulation of decisions, decisions on direction of travel and yeah, we need a lot of insight to help us form them. So I think that kind of role in product ops of bringing those insights and help to help us make those choices is absolutely key. Now as we know, product ops is relatively new and relatively nascent as a function. Just I guess that means it's evolving quite a lot in each organisation. Do we need a roadmap for our product ops function?

  - Product ops as you said, or as you said, roadmaps are direction, and I think everyone needs that direction to grow, so do product ops. And that helps even a product ops function set up their own vision, set up their own accountability, and maybe help them improve continuously. So having a roadmap even for product ops team reminds them to keep improving how the product organisation works. So yes, I think product ops team should have their own roadmap as well, which aligns with the overall company and the product roadmap.

  - So I'm gonna switch gears a little bit again for you. What's the biggest anti-pattern or bad practise that you've seen in a product operations function?

  - Well, I think we've spoken about it a little bit earlier, but product ops is about empowering teams with data, process, and tools too, and all of that is to deliver better products faster. When we see product ops teams becoming custodian of processes and processes over people, ensuring that ceremonies and rituals are followed for the sake of it, that is when I believe they're moving a bit away from the roadmap. Also, companies where the roles are distributed, if product ops team move into some of the other roles of Scrum and product owner, I think they would get themselves distracted. So having that sanity that product ops is there to remove friction and improve collaboration is important. And once you lose that, that I think is a chance that your products department is not doing the right thing or going somewhere wrong.

  - I love that, that kind of overall sense of, we exist to help the team, the product management function to be successful by bringing process, tools and data. But if by bringing process, tools, and data in an overriding way, we actually slow them down, that's an anti-pattern. So we're there to make it go faster, to make it home, and to really remember that it's people we're working with to enable.

  - Well, I think that's the crux of building a good product ops team, and also building a good roadmap is ensuring that we are removing friction.

  - Helping everybody not step on each other's toes when they're dancing maybe. So it's, we've talked about your thoughts on product ops. Whose advice do you listen to?

  - Well I do listen to you, yes. So of all the people, your advice on roadmaps and products is good, but I also like Rich Mironov and be a smart like everyone else. But Richard Mironov advise on, especially around enterprise product management is really helpful, yeah, and of course the Mind the Product. There are so many good speakers that find the product which you cannot stop listening to, and yeah, that has helped me a lot, in the last few years while I've been building some of these teams.

  - And in fact we obviously met at Mind the Product a few years ago, back in 2023. I'm looking forward to going along to it again in a couple of weeks time actually.

  - Well, I can't wait to meet you again. See you soon in London in about two to three weeks time.

  - So Amit, here is the penultimate question. This is the one that's maybe the hardest one to answer. After we've had all that conversation, if you had to distil your philosophy on product operations into one or two sentences, what would it be?

  - Ah, okay, that's a tough one. What would I advise? And then I think product ops is about building teams and empowering teams with right data, processes and tools to deliver better products and remove friction. Product ops teams, we connect the dots across the organisation and ensure that the decision which teams make, they're informed and they're aligned to our roadmap and to our organisation.

  - Absolutely, Amit. So I always have to end with my Steve Blankism, which is, is there anything else I should have asked you about product ops that I didn't?

  - Well, I think we have covered a lot and I'm as curious to know more about product ops as much as, you know, you are. But yes, as we go deeper, maybe topics around compliances, topics around how product ops intersect with user research, we could talk a lot about them.

  - What is product ops' role within compliance then? How does it factor in there?

  - I think a lot of products which are built these days have to go through multiple compliance checklist with various markets. There's U.S. market, there is ISO. So even in U.S. market, there is ISO 27,000, there is CCPA. Within Europe, it is GDPR, multiple compliances. And then there are compliances around personal data, personal identifiable data. If companies start building product without reading and understanding compliances, there is a chance that the product might not get launched. So bringing in legal early, product ops can ensure that there is alignment with legal and compliance team, and also be a pallbearer of some of those compliances while building product is something which they can bring their expertise on. I have seen companies building a product but unable to launch because they couldn't go past legal. And yes, somebody should have said that, hey, let's call legal before we build this thing.

  - Yeah, I mean, I'm still here thinking, as a product manager, I'd have been asking that question, but I know a lot miss it. I think there's some of those older school product people that think about that thing, those sorts of things and get ahead of it. I think there's a generation of product managers that are in a slightly narrower mindset, and if product ops is the way of breaking 'em outta that and driving that cross-functional alignment, then I'm all for it.

  - Yes, absolutely. Yeah, product ops is the way to go forward and we need to have more and more people in this, building this role and this function to, you know, reduce the chances of product failure, and in the end, of course, have better and more successful products.

  - Sounds good. Let's keep building products and supporting you with product ops then. So it's at the end I always like to just give my guests the opportunity to pitch themselves, to tell people where they can find them and how they can get in touch, over to you.

  - Yeah, well to our listeners, you can find me on LinkedIn, Amit Godbole, A-M-I-T G-O-D-B-O-L-E, or you could write to me at A-M-I-T-G-O-D-B-O-L-E@gmail com.

  - Perfect and we'll make sure those are down below in the show notes as well. Well, it's been a pleasure having you here today. It's let's, yeah, thanks for today and look forward to seeing you in Mind the Product.

  - Well, thank you so much Phil for having me. It's been lovely chatting with you about product ops and discovering that you were a dancer too. So yes, excited to meet you at MTP pods.

  - See you soon.

  - Bye.