How does Product Operations support the engine of your business? | Dan Dalton

In Episode 21 of Talking Roadmaps, interviewer Justin Woods sits down with Dan Dalton to unpack how Product Operations keeps the engine of a product business running. They explore when product ops emerges, how it differs by company scale, its role in roadmapping, and why first-principles thinking beats framework fundamentalism, especially as AI reshapes product teams.

Dan Dalton is an award-winning product leader, advisor, and coach. He's built his 13-year career scaling high-performing teams and driving explosive growth at some of the world's most innovative B2B SaaS companies.

Dan is currently Director of Product Management at Sage, leading their portfolio of cloud Payroll products. When he's not scaling products, he's sharing his product-led expertise as a speaker and advising early-stage companies on their journey to product-market-fit at scale.

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).

How does Product Operations support the engine of your business? | Dan Dalton

Dan Dalton and Justin Woods

In the next episode we have Jonathan Sheffi, VP Strategy & Product Excellence @ Clarivate Life Sciences & Healthcare. So watch out for episode 22!

• Transcript

  - I'm getting a bit of a name as sort of like the anti-content or the anti-process person at the moment, but you know, my whole philosophy over the past couple of years has been very much about how do we get back to the basics of your first principles? There is so much content, there is so much, you know, the right or the wrong way to do product, I think it's very easy to lose sight as to what the core, you know, what the core point of the rule is, which is to understand customer problems and then generate business value out of solving those problems. So, the way I think about product and that extends to design, product management, product operations, which is what is it you're trying to achieve and what is the easiest route to get there.

  - Hello, everybody, and welcome to the "Talking Roadmaps" channel and Series Two, we're talking about product operations. My special guest today is Dan Dalton. Dan, give us an introduction and tell us who you are.

  - I'm Dan Dalton. So I am a director of product management at Sage, as I've been in product management for about 15 years. Been at Sage for just under a year, and I lead all of Sage's cloud payroll products across every region that we're in. A team of about 10 at the moment. Obviously, a big organisation, but experience across product organisations, both big and small for a very long time.

  - Very cool. And of course, you're a speaker and a coach as well, and actually, I recently saw shortlisted for the Product-Led Alliance Award, so congratulations.

  - Yeah, thank you. I'm all of the LinkedIn buzzwords as I like to-

  - If you're enjoying the channel, subscribe, hit the bell icon, and give us a like. Well, we're very excited to have you here today. I know that you're connected with a lot of the previous guests that we've had as well. You know, you come to this with a plethora of experience within product management and product directorship, but I know you've got a lot of thoughts around product operations and kind of AI as well, so I look forward to unpacking some of that today with you. I wonder if maybe we start just with kind of the high-level questions, which is why do companies need product operations?

  - It's a very existential question. I think every company needs product operations for a different reason, but I think the core tenets of why product operations exist is because product management or product as a function, whether it's design, you know, user research or management, it's a big job, that there is a lot going on and it's very different for every organisation. And I think when product gets to a point of where they start to scale, you have a few people enrolled, whether that's design or product management, the cracks start to appear 'cause, you know, you read, reads hundreds and hundreds of books about what product manage is and the value that we deliver, it's a very, very broad, broad spectrum. There's a lot for a product manager to do. Probably why, you know, product managers are one of the most burnt out, burnt out discipline around. Product operations evolve for a need to fill the critical gaps that exist with busy product people, you know? It's an enabling function, you know? You look at things like RevOps is the, whenever someone asks me what is product operations, my first analogy is, we'll look at RevOps. The reason revenue operation exists is because pipeline forecasting is incredibly important. The tools process, all of the analysis, the way you do lead gen, the way you do lead hygiene, the way you go over everything that is critical to do the job should not be neglected, but you want your salespeople to go out and sell. Product operations emerges from the exact same problem of our product managers have to constantly look at their data. They have to constantly maintain the pipes. They're voice of the customer programmes. They have to constantly provide sales-fit roadmaps. They have to constantly communicate and keep people up to speed. They have to constantly go through and manage all of their launch procedures whilst doing all of their day-to-day job, you know? So, you know, product people are, in effect, you know, superhuman. And I think product operations emerges when product managers are inundated and are operating in all of the things that their role is deemed essential in that business. Product operations comes when everything else that is essential also needs, you know, people to tend to that garden as well. So, you know, looking back at some of the people, you know, I'm incredibly grateful to have worked for, you know, when I think about the product ops lens, that's some of my favourite partners because they were effectively my lifeline. When there was something that I thought, ooh, you know, I haven't spent, you know, as much time as I should have this week looking at our conversion funnel or looking at our voice of the customer programme, your product operations, you know, superhero immediately comes along saying, "Yep, we've got you covered. Here's the digest." You know, I think back to a lot of sessions I've been in with the likes of Christine at our time at Pendo of where, you know, I'm sitting down feeling slightly neglectful that oh no, I haven't gone through our NPS responses, I haven't gone through any of our feedback submissions and, you know, break glass in case of emergency, here emerges a complete analysis of everything that is important. Here is the pulse of your customer this week. So I think it emerges at the point of where product management is an essential function within insider businesses that have reached a level of scale of where you realise, actually, one person cannot completely fill all of this need across, you know, such a large spectrum of what product management is. That is when you need product operations, whether that's people or process or tools, in order to plug those gaps and keep feeding the machine.

  - Yeah, well said. And I think you of many people have seen that the most working for some of these companies that have scaled very quickly, you've very much seen the need for product operations, and that's accelerated within those teams 'cause you are almost growing quicker than you can even cope with sometimes. And so you need those functions to come in and help.

  - Yeah, I think organisations have such an ebb and flow of the different stages. You know, you think about a company that's scaling fast from a technology perspective, then, you know, it's all about roadmap alignment. It's all about making sure we have the right processes so that engineering, product, and design, and you know, all of the engaged or product-facing functions are working well together, that the processes, the way you engage are all streamlined. You know, not as many meetings. Making sure that how you account and how you plan and how you prioritise is all in the right way. You know, incredibly intense stuff. You think to then the completely different problems of an organisation that's scaling commercially, it's, well, okay, how do you make sure your sales team are effectively armed to go out and sell the roadmap for the next six months? How do we feed in the right closed lost information? How do we feed in the right voice to customer, the right revenue attribution towards the different opportunities that you could fulfil? So yeah, the needs are completely different and will be completely changing, you know, the scale of the company or the size.

  - Yeah, a hundred percent. And what I'm curious about is that you've worked for some great companies out there now, Dan. How do you see the product operations has been set up differently within them? Is it different? Is it similar? What have your experiences been?

  - Every product ops team I've ever worked with has been completely different, and it's been completely different in the sense of what the company demands or defines product management as has slightly changed. Now, I think to my current experience with Sage, we do have a product operations team, but that product operations team is very different to, you know, the one at, say, Pendo of where it's very commercially minded. It's very much about scale and much about the sort of the top-line activities we would do as, you know, a FTSE 50 company at Sage of where it is much more around the high-level tooling, the high-level ways of working. It's less hands-on in terms of the product management process because, you know, I think Sage has got about 250 product managers at this point. You know, we're an 11,000-person business, so them being very hands-on within the ways of working inside an organisation that has multiple different business units, you know, a Sage business unit is effectively, you know, 500 people. It could be a, well, a Series D company within itself. So they're much more focused on the high level, you know, it is about resource, you know, it's about contingent labour working. It's about resource planning, commercial forecasting, how we manage our budgets in terms of tooling, travel, you know, getting people together. Very high-level things. Now, when I think to, you know, product ops at Pendo and the team Christine built and led, they were much more hands-on in the sense of product people of where, you know, they were the product's people product people in the sense that they were very deep in the process. You know, they were experts in ways of working. They were the people putting in the plumbing of our voice of the customer programme because for them being front and centre with customers allowed them to effectively enable us to do the product management work, you know, to put our finger on the pulse of our customer facing opportunities to be in sales call, making sure the salespeople had the right narrative or the right assets or the right information in order to sell and generate interest. They were the people managing and measuring our beta programme, so we knew if the beta was going well or wasn't going well, whether something needed to change, or whether we could proceed to the next thing. So, you know, two companies incredibly different in scale and size and stage, the product operations function has been very different.

  - Yeah, that's right, and it is the classic product management saying, you know, it depends, but I think product management needs to exist where the gaps are. And the reason why it's different at every company is the gaps are different within each company. You know, some of them need robustness from a process to perspective, or a tooling perspective, or just how the company communicates. I think some of those are the key responsibilities. Maybe if we think about who does product operations help in the organisation, 'cause a lot of people think that it's just there, like revenue ops might be there just to support the revenue side of things. Actually, it's company-wide typically in that space. Is that something that you've also seen similarly in your experience?

  - Yeah, I think it touches it. If you are a product company, you know, if you sell a product, then product operations and product touches effectively everyone, you know, going from, you know, the example there of product operations managing beta programmes. So actually, before you even get to a beta programme, you need to do recruitment. You need to engage with customers to sell them on, you know, do you wanna take part or do you wanna, you know, help us work on this feature and be an early adopter and give your time right the way through till, well, selling roadmaps or support issues. And one of the things we have at Sage is our product operations team engages with our ways of work. And our ways of work can also include how do you roll a feature out to, you know, desktop products as still part of Sage's portfolio. How do you run the enablement of a feature or a product that only ships, you know, once every three months or once every six months? How do you then make sure you have the right support headcount of when something launches, you know? And when I think about the accounting world, we've got major changes in how entire nations are doing invoicing and accounting with e-invoicing in France, a project I was involved with, you know, sort of very early on in my Sage career. And that was a completely different paradigm for me, of where we were working with the support agents, we were working with our marketing team. So touching, you know, completely different areas of the business that you may or may not necessarily be involved in, you know? So I think it's a very, very it depends answer, but if you are a product company, then product operations is everywhere because product is everything.

  - Yeah, a hundred percent, and it goes back to the it depends, but I think it's, again, it's they're providing that help to the entire organisation. That's such an anti-pattern or an anti-belief that I think I've seen people think of before. Dan, I wanna talk a little bit about your experience from the product management side of things. You've been at some very early-stage teams and helped those to scale. Have there been always a product operations team available at the time you've built those teams up, or have you needed to scale a product function and then go, actually, I see the need for product ops, I'm gonna spin something up, or at least recommend that we do? What's been your experience there?

  - Yeah, so at very early stages, I think product leaders effectively become the product operations team. And what you tend to see is as that product leader's time becomes more and more condensed as the team starts to grow, that is effectively where product operations becomes that enabling function, or you sort of, not necessarily outsource, but you make it someone's full-time job in order to look and serve. You know, when I think about the job of a product leader versus a product manager, you know, the job of a product leader is to, you know, create the lens for the strategy. It is to look at team topology. It's to look at our ways of working. It's to look at, you know, all of the ephemeral things in order to make sure our product manager can focus on obsessing over the customer, obsessing over the opportunity, and ultimately building and delivering value. So I think that is, as I've seen and brought product operations into early stage organisations, is tend to have been of where the product management headcount gets to about five or five or above. And in that sense, that's where they become, you know, the full time consciousness of the product leader, which is okay, that person can no longer dedicate their entire time to understanding where things are or are not working because by the time you get to, you know, a couple of product managers, you've reached a level of scale you would assume, and everyone's gotta be going off focusing about different things. So that's what I've tend to have seen it. They then sort of pick up the responsibility of looking at the ways of working and being the agony aunt of the team, right? Because, you know, no process is perfect, every process is different, every company is different, but I think that's where you sort to get to the point of where you start to have someone focused full time on that ways of working.

  - Yeah, yeah, totally. And in fact, that kind of describes my path as well, as I was a product manager at Dell and then became a product leader at Vodafone. As I built and scaled the team, realised that I needed more around sort of the process, the underpinning tools, things like that. Again, not process as a dirty word, just stuff that meant that the team were consistent. Different teams had different roadmaps in different formats. It's like, how can we unify these? And that's what really got me interested in roadmapping tooling and tooling as a whole. And that's there where that saw me exit out of my leadership position and go and work for Aha! in fact to go and, you know, be passionate about this roadmapping tool that I found. So that definitely ties into that, especially when, often, as a leader, you are involved with things like ways of working because your teams are feeding back in organisational feedback surveys that we don't have the tools to do our job. So you jump in and kind of fill that gap, right?

  - It's a constancy that, there was a stat that I've used for a talk that I'm doing at the moment, which is like 60% of product managers, our product teams actively dislike the way that they work, but like barely anyone is actively doing anything about it. Now, I think that the number I pulled out was like less than 35% of product leaders when surveyed were actively investing in improving their ways of working, but then you had such a disproportionate number of product teams that are reporting. I don't like how we work. You know, it's one of those things where I think it's easy to get heads down. As a product person, it's easy to, you know, worry, especially at early stage. Are we delivering value? Will we be constantly shipping? Are we finding product market fit? But it's very easy to then take your eye off the quality of the inputs. You know, we all know the saying, you know, you put crap in, you get crap out. It's a very well-known saying, but when you look at it in terms of scaling team, you know, it's interesting you use the word like process as a dirty word. I always say to people, if I'm the person talking about process, there is a problem because I'm a very anti-process person, but I'm anti-process in the sense that I don't wanna be religiously tied to a way of working. My philosophy is we should have, you know, and this is something that was talked about at Pendo a lot, which is, you know, strongly held beliefs or strong beliefs held loosely in the sense that nothing will ever be perfect. When it is a problem, we need to fix it. And I think that's where the attention and the time and the investment should then come from, where we actively quantify it is a problem. But the overwhelming data and industry, you know, surveys will say with our ways of working are pretty much always an issue, but they're not actively being invested. And I think that's a really unique lens of product operations, you know? I always say it's the product people's product people of where it's I'm obsessed about that way of working, about putting that rigour and that finesse to how we work.

  - Yeah. Very well said. And one thing that came to mind when you were talking about that is I think that there is always a process, whether it's explicit or not. Like, if you don't think you have a process, you have a process that isn't a process, and it's probably messy. And so why not make that thing explicit, and kind of like just document it down and look at it and make it more explicit. And I think that's the problem, often, is that, you know, we don't have a process, but really, you do. Your process is not to have one, and it's unrepeatable and probably not optimal. So let's make that effort just to, I'm a fan of lightweight process, is kind of where I'm going with that.

  - Yeah, and I think that's a lot of pushback, or at least, you know, in some earlier stage organisations where I've suggested or looked at the concept of product ops, where I've received, you know, a negative response, which is, you know, the last thing we need is process people. You know, my response to that is this is not about process. This is about the cleanliness or the optimization of what we have today. You know, you look at, you know, data, you look at our tooling and our systems, you look at, you know, the cross-functional orchestration of how sales and product work together. If those problems are big enough, they will warrant an investment. And that is ultimately what the solution comes of, whether that's someone existing in the team who, you know, if it's a product manager who gets fed up of the way you engage with sales and you actively invest in solving that problem, well, you know, that's product operations. It's not necessarily human. It's a system that's of way of working, but as soon as you shift into solving those problems, you've effectively put your product uptown.

  - Yeah, very well said. I love that. So, being as experienced as you have been within product management and product operations, I'm wondering if you had kind of any good practise for product operations where you've seen it work well.

  - Yeah, I mean, another shout-out to Christine. As far as I'm concerned, Christine's like the mother of product operations, you know? That function at Pendo was incredibly influential as to how I look at product management overall. The best thing I ever got from working with Christine and working with product operations within that sort of team in that environment was the, I think Christine put it as the servant leader's servant leader, which is probably where my product people's product person comes from. But it was much more around how you have a designated function that is there to pick up where you can't. And I think product managers, again, one of the most, or product is one of the most overstretched, you know, capacity or resources in any organisation. Where it worked really well for me was, as someone who was building more of a new product line, so when I was at Pendo, I looked after the qualitative product. So being in and actually using our own product to do our product operations or the NPS, the feedback, the roadmapping tool, that was incredibly valuable feedback for me because it wasn't just them providing all of the insights, the voice of the customer, what we were hearing from the sales team, they were actually using the product as well. So, getting the firsthand feedback from a team that are using the product and are actively listening to the customers, it provided a completely magnified layer of validation layer on top of all of the feedback that they were receiving 'cause they were actually using the product to triage it. So, that is one of the things that I've taken from that experience and implemented at different products since, which is if you are someone who is, if you're a product person who is, you know, I've used Dovetail in a couple of organisations. If you are in Dovetail and you are listening to the customer talk through an issue or talk through, you know, a piece of the product that they don't like, then at the same time, we've all got multiple screens on another screen, you need to log into the product and you need to replicate or trying to replicate exactly what that customer's saying. Now it's live dog food in. So, you know, basically a position of where you've applied to put yourselves in the customer's shoes. As you're hearing, the words of the customer was something that I've taken and sort of instituted it, you know, three different companies since I was receiving feedback or receiving, you know, the synthesis or synthesised insights from a product operations team who were actually using the tool that we were building. So, you know, I think that just sort of the service or the capability of having all of those insights, the voice, the customer reports, but through a lens of someone who was also educated about the product is something that I've taken not only with people in product ops, but product management as well.

  - Yeah, superb. That really resonates with me, and I think it's something that just sounds so simple, but sometimes we try and make something too sophisticated, and it's about bringing it back to first principles, which I know you're a big fan of anyway. It's like, let's just bring product management back to what it is we are here to do is really important. And I think you've got a similar type approach with things like AI as well, so I wonder if you wanted to touch on that.

  - Yeah, I'm getting a bit of a name as sort of like the anti-content or the anti-process person at the moment, but you know, my whole philosophy over the past couple of years has been very much about how do we get back to the basics of your first principles. There is so much content, there is so much, you know, the right or the wrong way to do product. I think it's very easy to lose sight as to what the core, you know, what the core point of the rule is, which is to understand customer problems and then generate business value out of solving those problems. So the way I think about product, you know, and that extends to design, product management, product operations, which is what is it you're trying to achieve, and what is the easiest route to get there? And that comes from how we do roadmap planning and how we actually think about what solutions we bring to market, but also how we think about the process and how we do product, which is, well, if we're optimising for speed, you know, say in a Series A or Series B startup. I've been in a few of those over the years. Then everything you do, every process you put in place, should be obsessed about how you reduce time to value, how you increase the speed, or how you reduce your risk. In an organisation like Sage, well, we have a high price we put on compliance. You know, that is a core principle for us in the sense that a huge part of Sage's brand of being in business for 40 years and being a household name in accounting is actually when Sage does compliance, it does compliance. So when we think about creating systems or creating a product operating rhythm that puts such an emphasis on compliance and on making sure that when we release something, the core job to be done or the core, you know, guarantee we give to our customers is this is, you know, and level compliance, that has to be instilled into that. And the way I think about AI, the way I think about process, it all comes back to first principles. I think product operations, it's an offshoot or it's an offspring of product in general. Our obsession with creating abstraction layers, there are so many processes, there are so many things in which product management is now accountable for, so many best practises. You know, there's a stat in a piece that I've been working on, or I've launched over the past couple of weeks, is that the average list of frameworks that a product manager should understand has 16 entries on average. Imagine being in a role or being, you know, even new to product management, where you had to understand, in detail, 16 different methodologies and ways of working, and that doesn't even include heuristics like design thinking. Of course, product operations is going to exist because we hold ourselves to an unreasonable standard. Product management has no common definition. It is practised different geographically, as well as industry and different verticals, and in different companies at different stages. So to me, product operations is a logical solution to all of the noise and all of the unrealistic expectations that product organisations or organisations that have a product function. And still, there is so much to do, there is so much to think about. Of course, we are going to need systems, and of course, we are gonna need people who are obsessed about making that machine run faster.

  - Yeah, very well said. Brilliant. You know, Dan, there's nothing I could handle to that. I think it's 'cause like yep, perfectly said. And I think a lot of our audience will be agreeing with that as well. One thing that was interesting that you said is even how geographic it can be, right? So you've got maybe your theory-based, you know, Silicon Valley, this is the bubble that they exist, which is very different from maybe us in Europe. I've even seen differences even within countries within Europe. Germany approaches product management very differently. I know some northern European companies do, or countries do. And then, of course, you've got India and other areas. And each one tends to have a flavour of it. And it's weird that you can pick that up just from the geography, but you're spot on.

  - Yeah, they're like accents, you know? Like the most of my career has been spent working with sort of American companies. You know, a huge percentage of like percentage of my career has been spent with companies that have had either a very large presence or headquartered in North America. And I think it's very easy to come out of the sort of, you know, the SaaS top 100 companies and think this is the right way to do things, but then when you go to a startup in the Nordics, you know, high levels of fiscal responsibility, very straightforward communication, you know, we don't need this one. Well, actually, this is the value of this function. We might not call it a function, but you know, the investment in this problem, i.e., making sure we have a good operating rhythm, clean data, a solid handle on voice of the customer, everything that product ops delivers, it's a very easy investment to quantify. Sometimes you just need to call it a different thing. I'm a big fan of calling a spade a spade, which does get me in trouble. Being able to articulate it in slightly different accents is a really interesting dynamic, but it always ends with the same result, which is who do you have or what do you have that is focused on making sure that the engine powering this business is operating as effectively as it could be.

  - And so with that, with some of those best practises we've seen, are there any anti-patterns or bad practises with product operations that you've seen that's just like, look, if this is occurring within your company, you should probably think again about this.

  - I think framework fundamentalism is sort of a tenet or an anti-pattern that I've been quite passionate about. You know, I've said on a couple of different forums at this point, I think over the last few years, the product community in general has started caring more about how you're doing the work rather than the work you're actually doing. You know, whether it's following, you know, Marty Cagan and inspired to the letter of the law, or shape up or, you know, Kanban, or even slipping back into the world of waterfall because people are sick of hearing the word agile and not seeing time-based roadmaps. I think that the anti-pattern for me is why you have people who are obsessing over the process, but obsessing over the adherence tool process rather than the optimization of the process. I think, you know, product ops when done correctly is the antidote to that because it's pragmatic, it's about reduction, it's about removing friction, and it's about enabling speed or enabling quality. So I think that sort of framework, fundamentalism of where you have, it may not necessarily be product ops, but the way you have, you know, lifecycle management or you know, operations teams that are just broadly focused on adherence to a process that isn't owned or operated by the doers, I think that that to me is a huge anti-pattern. You know, I've said in a few different forums, I would not learn to fly from someone who wasn't a qualified pilot. Where you have people in roles that are sort of dictating how product teams and how engineering or R&D functions or even marketing or sales who haven't done the job, who fundamentally don't have the earned empathy and the earned experience to understand where the choke points might be, that to me is an anti-pattern. So, central function zoning owning process and sort of measuring adherence to the process rather than actual optimization or success. If you're celebrating the fact that you shipped every feature you wanted to ship this quarter, but those features were garbage and achieved no outcomes, you should not be celebrating that.

  - Mic drop, Dan. You know, it sounds like common sense, but we see it. And so, you know, very well said there. I think that was a very important point that needed to be made, and that's the point, right? Framework fundamentalism, I think, is a term that I'm gonna take away. I haven't heard it quite like that before, but I'm gonna put that one in my pocket. Let's move the conversation a little bit into roadmapping, if we may. And I'm not sure if you were prepared for that, but I'm curious at least from your experience, and you've worked for some companies that are actually in the product management tools, product roadmapping space. What is product operations' involvement in roadmapping? How have you seen that?

  - I think, I'm not gonna say it depends. What I've seen is an extra synthesis layer, you know, where you have product managers who are responsible for the strategy and who are effectively responsible for the roadmap. The way I've seen product operations engage with the roadmap is to be that sort of first line of defence. There is an interview tactic that I deploy, which is the first question I ask a product manager in any interview with me is explain your product strategy. And to me, if it's not automatic, if a product manager cannot just go straight into autopilot and tell you what their product strategy is, it means they haven't rehearsed it a hundred times, and they haven't, you know, haven't presented it a hundred times and rehearsed it a thousand times more. Your roadmap is a communication tool. You know, when we built the roadmapping tool at Pendo, the tagline that I used was, salespeople sell, engineers write code, product managers build roadmaps. It's the only asset you can get your hands around and say product managers are accountable for this thing. So, you know, the way I've seen product operations in giggers, they've been my sparring partner. You know, there are lots of sessions I've been in with various different people of where I've effectively given a dry run of it. You know, I've had feedback from product operations partners who've either said, you know, actually part of the pain or part of the pitch that we think would really resonate with the salespeople would be, if we frame it like this or you know, if the way we wanna add some of the quantification about the number of customers who have been interested or participated in a beta programme or how we best quantify the revenue opportunity, how do we break down, you know, if you have a feature on your roadmap, which is the most requested feature, actually, how do we drill into the demographic of that? What is the components? What is the percentage of revenue attributable to an enterprise customer versus, you know, maybe SMB or smart up stock? So, you know, the way I've always engaged with them from a roadmapping perspective is valuable insights and input into how we quantify that roadmap and how we pitch or position that roadmap. Then also just valuable feedback around actually how well do we think this roadmap addresses the business outcomes. How do we link that back to, you know, the information in the pipeline or sales targets? How do we bring all of the other bits of information or all the other bits of quantification from around the business to give them a roadmap or impact? So, a long way of saying, actually, it's an incredibly good sounding board. You know, there's been, like I say, lots of conversations that are flooding into my head at the moment of where I've sat down with someone on the ops team and just said, "Look, this is the way I wanna pitch this. How do you think this resonates? From all of your interactions with sales or with customers or with marketing or the execs, how do we think this message is gonna land? How can I best quantify this thing?" You know, treat them as an extension of your customer and as your sales team.

  - So, Dan, we mentioned Christine before, and obviously, a lot of people in the roadmappings or product operations space. I'm curious whose advice on product operations you listen to, and we should definitely talk about Christine in there as well.

  - Yeah, so as far as I'm concerned, Christine's like the mother of product operations. I'd never heard of it until I started working with Christine Itwaru. I think, obviously, Melissa Perry as well. There's a lot of great content out there, but I tend to try and engage a little bit more with startups, but one of the things that I'm very keen on doing at Sage, and when I am at a larger organisation, is how can we take inspiration from some of the more lean companies? You know, Sage is a very large company. It's been around the block. It's gone through a lot of change. A lot of the inspiration I take from is, especially in the business unit that I'm in, is it's more of an up-and-coming business unit. I don't wanna use the phrase start up in a startup because that gives me the chills. Well, it's more around how can we take what's working well at some of these smaller companies. So, within sort of the advisory stuff that I do, I'm always poking questions back, which is, you know, how are you looking at optimising your own framework? I'm still very active in the sort of the product tool space, so I do advising with a lot of companies at that earlier stage around the roadmapping of the voice of the customer space, and the type of conversations we always have in that space is always broadly the same. It's, you know, how responsive are executives with voice of the customer tools? How responsive are executive to, you know, roadmap ways of work and how we can bring tools to market that effectively enable product managers. My response is always the same. You know, it is a communication tool. It's about pitching business value. So any teams or any smaller companies that are really getting in and talking about that sort of stuff, that's where I tend to get my inspiration from. Smaller companies, while running lean, 'cause I think that's the thesis of the org.

  - I think that's the thing, isn't it? Is what can one type of company learn from the other, you know, whether you've got, you know, how can we bring more agility, I'm not using agile, but more agility, or the ability to change direction quickly to these larger companies. How can we bring more robustness and consideration of what the larger companies do to the smaller ones? But as we know, it depends on the maturity of the company, the maturity of the product, the maturity of the teams, how different departments within that organisation treat product management. And that's one of the things that it makes it such a wonderful and varied role in terms of product management, but it's also one of the things that makes it, to your point, very difficult to say, you need to do these one, two, three things because it's different for every single one.

  - Yeah, exactly. There's so much range, and especially with AI tools, I think a lot of the things that you can achieve with, you know, n8n or even with just sort of ChatGPT, is basic levels of automation. You know, like I said, I moved into a reasonably new business unit inside of Sage. One of the first things I did was set up a social listening bot. So every time one of our competitors posts something about the AI tools or the new features they're bringing to market, you know, an n8n integration plugged into Notion, nice and easy. If we were to actually scale that within the organisation, I would need someone to sit down and own that properly. That's obviously a product ops task, but I think the nature of that maturing still comes from, okay, I have a problem, it's competitive insights. How do you take it and get something running? The actual productionizing or scaling of that system needs someone dedicated to look after it. And I think that to me is the sweet spot of where, you know, we will see as AI and as the automation tools start to bed in, what we're going to realise is it's very easy to hack and to vibe code something together. You still need someone obsessed and dedicated to making that thing real and production and scalable and usable. That void will become a lot more obvious as we start to fall into the trough of disillusionment with AI tools. We start to see things, actually, you know, it's not that easy. We do need people to understand at the scale of this process.

  - Yeah, and is that something you've been seeing a lot in terms of your coaching and your speak engagements that you've been worked on? Is that something you're seeing a lot and think that's becoming a problem?

  - Definitely. I mean, there were multiple companies that I was consulting with two years ago that received a level of funding. A lot of them are gone because a lot of what they were doing was, I'll bring a product to market, it's based on the OpenAI API, and there was nothing defendable about it. It was just, okay, I've got an idea. Now it's easier for me to bring a product to market. I'm just gonna do it. A lot of that is now gone 'cause it wasn't defendable, it wasn't scalable, it wasn't unique, you know? There was nothing defendable about what it is they were bringing. So I think we're gonna see that with, you know, product ops with product management process. I think product in general and a lot of rules. You know, there's a really easy example as you think about, well, how realistic is it going to be for a junior engineer to get a job in five years' time? And this is a question that come up at a ProductTank meetup recently. I think a lot of rules, as we know it today, will still exist. They will just look different in the sense that it will all be about context curation. If we have AI-powered workflows that replicate or streamline the product development lifecycle, we're still going to need people to maintain the context and to understand when it's not doing something it's supposed to be doing, unless we get to AGI, which, whenever, you know, artificial general intelligence. If we're all self-reinforcing feedback loops and things like that, cool, but until that is a reality, we're still going to understand, or we're still going to need people to have the appropriate context in order to govern and to marshal whatever AI tools we're using. You know, I experimented with the Atlassian MCP of where I had my own, you know, my own agent that I had trained on, various different job to be done models, examples of PRDs, user stories, epics, all of the stuff that I've written in the past and took that and said, "Right, okay, generate my PRD for this idea I have." I'd have a nice, long voice conversation with my ChatGPT chat. That would then create everything I wanted it to create. Spit it to the MCP server. It would then create a confluence page of the PRD or the pitch deck. That would then break it down into epics. It would then break the epics we agreed with the right MVP into user stories. Those user stories would then go to Jira. I would then say, "Okay, you know, build a prototype for this." Downloaded the design system that we have, used Claude Code, put all of the components and stuff together. That, on the surface of it, looks like, oh, you know, well, at some point, you're gonna replace a product manager, you're gonna replace role X, Y, and Z, I still needed all of the context to understand what problem we're trying to solve and what was strategically important. Still needed the presence of mind to say, "Well, actually, I need to do this in whatever, you know, design language that we have." Still understand the core components. Still have my own design aesthetic to realise the first six iterations of that design were absolutely horrible and haven't been implemented right. And then still have the presence of mind to say, "Well, actually, I don't know at a large scale if some of the more advanced features I wanna do with this is technically complex." And so there is still a huge amount of context curation that will be applied to multiple roles, and I think that's where a lot of the conversation around, oh, well, will product ops or will RevOps or will any of the sort of operations-based functions still exist in three years' time? The job to be done will still be the same. The way that manifests in life will be different, but I still think the core premise of having people who are obsessed with, you know, context curation, we have that today. That's what product ops and product people are obsessed about today. It's just the vehicle in which that will, you know, be delivered to an organisation will be different. It's different tools. You know, it's waterfall to agile all over again. It's just got AI.

  - Yeah, exactly. And again, it's down to first principles. It's what are we here to do? We're here to deliver value. It's great to see these tools augmenting that, being a sparring partner, simplifying some of this or automating some of it, but the core fundamentals hasn't changed. And so, you know, AI is just an enabler or a tool that we can use. It's not going to replace everything. So, I think that's certainly the way that I use it, and it's been fascinating to hear what you've just shared with us, how you're using it to improve things, but still being in the driving seat.

  - Yeah, there's an interesting question that comes off the back of that, which was posed to me as well, which is if you're working in that way, does that then close the loops? You know, if you can be a, you know, in theory, a one-person product team, which I am absolutely not by the way, does that close the ability for people to feedback or people to get involved, you know? Does your development cycle then become so fast that you're then close to feedback? The answer to that has to be no because our operating model has to be feedback; it has to be validation. What we're trying to do is shortcut our time to insight or shortcut time to learning. Product operations is in a unique position in order to protect that because, you know, there is always a, and I imagine it is a seesaw. Okay, on one side of the seesaw, you've got technological advancement, and on the right side of the seesaw, you've got process in order to scale. And there's always gonna be a fight. There's always gonna be a, okay, now the processes has outweighed the technical advancement. You know, the new technology will come in, and we'll run fast, and we'll break things, but then, in order for it to scale, the process side of it has to come up. I think there's always going to be that product operations mindset or that product mindset in order to say, well, actually, that way of working, whilst it sounds cool and it makes for a good podcast quote, or it makes for a good blog post, actually really hurts because if you're just in that mindset of trying to run fast, who is then protecting the, well, is it viable, is it feasible, is it usable, you know? So that's where I think the product operations mindset will always be a thing, which is, okay, well, what is it you're actually optimising for? How can we make this process better? How can we protect the principles in which we wanna build product, which is, you know, unique to every organisation, but universally the same, which is, are you solving the right problem? Are you doing the right thing?

  - Yeah, big time, big time. And I think that's a nice segue into probably one of our hardest questions we can ask. So if you wanna take a few seconds to think about it, then please do, but if you had to distil your philosophy of product operations into just a couple of sentences, how would you describe it?

  - I'm thinking to my LinkedIn tagline, which is, you know, it is a philosophy on how to build and scale teams without the theatrics because I think that it's very easy for product teams to get lost or product people in general to get lost in the abstraction of it all, the process of it all, you know, the glitz and glamour of product. But I think it has to come back to that first principles thesis. A product operations is there to make sure that it runs well. It is not an explosive or a horrible situation to be in in the sense that you are drowning in things that don't make sense, unable to move, unable to move forward, or, as a product manager, unable to breathe. I think product operations as a system, as a discipline, as a department, as a way of thinking, is there to remove all of the drama and to help things move faster.

  - I'm wondering if there's anything that I should have asked you that didn't or if there's something else that you just wanted to share some parting thoughts on something that we touched on earlier, but maybe didn't get enough airtime.

  - No, I think we've covered a lot of ground, Justin. I think that it's certainly for smaller companies. I think when you are a product leader in, you know, a seed or a Series A company, every headcount matters, you know? So thinking about where you deploy that headcount, where you deploy the, you know, the funding in order to make life easier is always an existential crisis for a product leader 'cause there's never enough money, there's never enough people, and there's always too much stuff to do. I think embracing the product operations mindset when you are building a team is incredibly important. And if you don't have product operation headcount or even dedicated tooling, I think it's something that product leaders will have to pick up, are obliged to give more thought for. If you're in a startup and you have, you know, more of an IC focused in all of your individual product managers, and you know, you might not have enough runway for the company to exist in six months, making sure that you don't forget about the process optimization. You don't forget about, well, how do we make life easier? How do we make the tools, the data, the insights, the access to, you know, other parts of the organisation, the data we need, the insights we need? If you want optimising for that thing, then you're actively hurting your team because, you know, those smaller organisations, those product managers, I can say, are very prone to burnout. So, I think putting a name on it or moving past any sort of thinking you might have of product operations about being a team that only large organisations have, it's absolutely not. It is a mindset, and it is an obligation for those product leaders in earlier stage or smaller companies to put a little bit more value on because you know, whether they are newer or they are more time-stretched product managers, it's solving those problems in particular that will give you a bigger return on investment on your team because your team will be able to think more, move faster, and get more done.

  - So true. I'm doing a lot of nodding here as our audience will be able to see, and I'm sure a lot of people in our audience will as well. A lot of what you've said makes total sense, Dan. How can people get in contact with you to learn more?

  - Yeah, LinkedIn is the primary channel for me. Like I say, I am all of the LinkedIn buzzwords. So I'm a speaker, a coach, advisor. So the best way to get in touch with me is on LinkedIn. I will take every exception request, even if you are trying to sell me something I just might not buy if you are trying to sell me something. Yeah, LinkedIn is the best thing for me. I'm a semi-regular poster on LinkedIn, as I like to say.

  - Superb. Well, Dan, all that leaves me to say is thank you so much for spending some time with us today. I've really enjoyed learning from you. I think a lot of what you've said is gonna provide a lot of value to our audience, so thank you for taking the time. And to folks out there, thank you so much for watching or listening in. If you're listening into the podcast, please do remember to give us a like, drop a comment on something that Dan has shared that you really liked, that resonated with you. And if you'd like to take part, jump on the "Talking Roadmaps" website, get in contact with us there, and you could be in the hot seat as Dan is today. Other than that, it just leads me to say, Dan, it's been an absolute pleasure. Thank you for spending time with us.

  - Thank you for having me. It's a lovely hot seat.