What does successful product operations look like? | Denise Tilles

In Episode 10 of Talking Roadmaps, Phil Hornby interviews Denise Tilles to unpack what successful product operations really looks like today. They explore the evolving role of product ops in enabling decision-making, how AI is shifting the landscape, and the balance between structure and flexibility. Denise shares practical insights on reporting lines, organizational models, tool misuse, and common pitfalls in scaling product ops teams.

Denise co-authored the book Product Operations, the must-read guide technology leaders have been missing.

Denise has ~15 years of product leadership experience, advising companies like Novo Nordisk, Bloomberg, and RedHat with:

• Product management training and assessment

• Setting up product operations

• Product operating model design

• Strategic planning for product teams

• Custom skills workshops

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

What does successful product operations look like? | Denise Tilles

Denise Tilles and Phil Hornby

In the next episode we are talking to Paulo Garcia, Principal of Product Management & Operations @ Twinkl. So watch out for Season 2 - Episode 11!

• Transcript

  - So if you heard the interview that Melissa and I did with Lenny on his podcast, he said something like, "You know, the things that you usurp or take away from product managers," I'm like, "Woo, there's no usurping." It's really symbiotic. And you know, it's about enablement. And I think a good product ops person is kind of got that servant leader mentality, right? So it's about enabling the things for product managers that, you know, setting the strategy, the vision, experimentation. It's about putting these things into a practise that starts creating that flywheel versus telling everyone what to do. So I guess what I'd like to do is break that down.

  - Welcome to "Talking Roadmaps" season two, where we're talking about product operations. And today, I'm joined by Denise Tilles. Denise I don't think in the product top space, you need an introduction. Well give us one anyway.

  - Hey, nice to see you, Phil. Yeah, I am Denise Tilles and product operations evangelist, I guess you'd say. And co-wrote the book about product ops with Melissa Perri. But the book's been out since late 2023 and we're just about to do an update on it. When the book came out, generative AI was kinda starting to rear its head. Now it's in full bloom, right? So it seems like it's a great time to sort of talk about the leverage that this technology has provided to product ops and hopefully provide some really applicable use cases that folks can learn from and hopefully grab ideas. So we're working on the audio book that will include those updates and then we'll go back and do a second edition of the book. So anyway, that's me. I have experienced product ops as an operating leader, experienced its power and the leverage it gives product teams and then also, as an advisor and coach to companies like Sam's Club, Walmart, Bloomberg, Red Hat, so number of enterprise level companies, and then also smaller European companies like Nordhealth. And really excited to be here with you.

  - [Narrator] If you're enjoying the channel, subscribe, hit the bell and give us a like.

  - You've got the defacto book on product operations. And I love the adding in of the AI piece 'cause I'm on my own writing journey right now. And I started it mid-'24 but I've done huge number of pivots and I've basically rebooted the start of 2025. And what I've literally just done an hour before we're talking is spent an hour talking to someone about the involvement of AI in decision making and getting their viewpoint on that. Because fundamentally, decision making is the core of what I'm writing about. Although I'm taking an angle about creating the empowered products environment or empowered product teams and how decision making is the core of that. And I realised, yeah, like yourself, I couldn't ignore AI any longer.

  - I don't know if we were ignoring it, it just hadn't really become the, you know, massive consideration that it is now and tool and opportunity, so.

  - And that's the thing, you can't really write about it in a book until it's starting to actually have, so you can start to join the pattern, do the pattern matching of how it's helping.

  - I think we have the initial use cases. I don't know of any patterns we're finding yet, but there's a few,

  - I mean, maybe we can get some sneak peeks as we go along here. Let's start with something really basic then. Why do companies need product ops?

  - Yeah, if I had to encapsulate it in just a super quick soundbite, it's about helping improve the speed and quality of decision making for product managers. And it's really about the efficiency and standardisation, making sure we're really supporting product teams in data-driven decision making, that sort of ways of working, I don't like to say process necessarily, but how can we stop talking about how we're doing the work and do the work? And usually, when I frame it that way, people are like, "Yeah, that totally makes sense." And scalability. So every company is under more and more pressure, right? To, you know, be able to show growth in terms of revenue and you know, Tam, so how do we get there? And product ops really is that secret sauce.

  - I find that the word "process" gets a bad rap. Process is just the way you do your work. Ways of working means the same thing, but it just seems to gain this position. It's almost like we're swearing when we say the word. It's just how we do what we do. And I think there was a quote from John Cutler a while ago that said, "Your process exists whether you acknowledge it or not." So let's acknowledge it and let's design it. Let's be purposeful intentful about how we work,

  - Right, and that's part of scaling too. And I think it's a little naive to think that what got you there is a pirate ship is gonna get you there as you scale to Navy ship. So there has to be some sort of guardrails or just sort of, you know, general agreement about how we're getting things done so that people can move more quickly. And roadmaps is definitely an area where I see a lot of companies really get a lot of blockage. And it turns out, you know, initially my theory was like, I'm guessing everyone has a really strong point of view o on how they wanna structure these. They don't just tell me how you want it and I'll do it. Let's all do it together in the same way and express the same level of fidelity. So I think there's areas where folks maybe are a little tentative to step, but I think it would provide a lot of leverage for product folks to focus on delivering value, delivering revenue versus am I doing this in a now, next, later or feature or outcome. So I think it gives them a lot of opportunity to focus on the things that matter versus how.

  - Although I do think you need still few pirates left in that Navy for doing some of the innovation work. I mean, I might literally be quoting the title of a book by a great innovation guy called Tendayi Viki who talks about innovation being about behaving like pirates in that Navy. Your organisation is set up for that big work that once you get large it's like, this is our core business, how we work. But the future probably isn't gonna get created by people working that way.

  - No, but there's the blend that all Navy or all pirate probably isn't gonna cut it.

  - And so, okay, we've got it to help us be efficient to think about those ways of working to make sure we're doing data-driven thing. What did the report into, how does this fit into our organisation?

  - Yeah, it was funny. I was just having a call with a client the other day. I did an engagement with them last summer and assessed the company. And you know, where are they over indexing? Where are they under indexing when you think of it from the framework of the three pillars of business and data insights, the quantitative customer market insights, the qualitative and process and practise is the operating model, the third pillar. And they were getting pretty tight with the business and data insights, customer market research, amazing team. They just needed to figure out how to sort of harness and funnel those great insights to the teams. But process and ways of working and the operating model definitely was an area to focus on. But we had a call about where this person would report into before they posted the job. And I said, "Well ideally, it reports to you SVP, you know, the leader the team." And he's like, "I don't have time for that." I'm like, "Okay, you're lost. But so we talked, he's like, "You know, maybe our head of UX." Maybe there's opportunities there in terms of them being sort of, you know, objective and neutral. But as I saw sort of the two heads of product talking about it, I'm like, these people have a good sense of respect and you know, no one's gonna necessarily monopolise that person. So in the end, we ended up coming to one of the directors of product. But typically I have to see the role reporting into the top leader of product. And a lot of CPOs, once they've had product ops, they won't go back and just say, take new roles. Like I have to be able to establish this key function. So I like to see it typically the VP, the SVP, the CPO, but I've seen it reporting all different types of ways.

  - Yeah, I know. When I reflect on it, the role didn't exist when I was leading but the work existed. In fact, as the leader, I was doing a chunk of it. Like all those ways of working things sat with me and it was a big distraction on my time. So as leader saying I don't have the time for it, is an interesting kind of attitude 'cause they're probably getting involved in it and by having someone direct closely related to them, they're probably gonna regain time. 'cause they're not having to deal with saying how it should be done. They're letting, they're giving the direction to that person who is really gonna get into the detail and figure it out.

  - Yeah, I agree. But you know what? If that's their point of view, I don't wanna disadvantage this new person coming on that's not gonna get sort of the onboarding that they deserve. So fine, we'll work it out.

  - Yeah, I mean, one of my clients has put it together with delivery, for example, in their organisation, they put it with their agile delivery leads. And you know what? I was first resistant of the idea, but it was the person, they had a great head of product, they had a great agile delivery or head of delivery. And that head of delivery, when the head of product ops left, the great head of delivery was just the right person, had the right attitude, and punched at the right way in the organisation to bring it under her sort of umbrella and actually worked out really well for them. So we're reporting ideally to the highest person in the product's tree, but we might be pragmatic about it. How's it set up? What capabilities have we got in this team then?

  - Typically, I've experienced mostly folks really focused in on what they do. So if it's someone who's maybe embedded with the teams as a product analyst, they're really focused in there. If it's someone thinking about ways of working, typically, you get more leverage in economies of scale in a horizontal way. So in the book we talk about more of a hybrid model of organisation of the team and sort of where they fit in. So that's typically how I see it. Most product analysts I've met are not necessarily systems thinkers in that way or have been product managers. So I wouldn't say that one person could do all of that. So I see more analysts and then someone's thinking about ways of working, optimising the economies of scale it.

  - So we've got an organisation and we've got 10 product teams maybe with, I don't know, six to 10 engineers and a product manager and a designer in them all. How big is this product organisation?

  - Well, it really depends how big your product team is. It's funny, I was chatting with a friend yesterday I had lunch with, and I was telling her about a company, I joined them for AMA around the book. And I was asking about how big the team was. And they said, "Well we have like four product ops peoples." And I was like, wow, this is definitely a software-enabled company. How many product managers do you have? And they said six. I'm like, "Almost a one-to-one? I've never heard of that." So, but then, you know, with companies larger sort of healthcare, EHR, you know, electronic health record companies, there's one company I've worked with that has 50 people on the product ops team, but they also have almost 1,000 product managers. So if you can make the case and there's the need, go for it. A lot of companies, especially in these later times, have one person. So you have to think about what's above the line in terms of capability and time and capacity, and then what's below the line. It would be great if we could do this that either means we're subtracting something or we're bringing on somebody else. So that's where I see success happening with a person of a team of one that they're really clear about what they can and what they can't do because especially with product ops being a new function, everybody sort of has their own projection of what that includes.

  - Oh no, there was a perfect segue there. You talked about if you can justify it. So how do we justify product ops?

  - If you're adding it or trying to keep it or?

  - I guess I'm just thinking about either. It's like how do we justify having this team of what might be described as unproductive people? I've heard those sorts of phrase used before when you're not delivering,

  - Let's be real, it's a cost centre. So we have to be proving our worth every day. I gave a talk at last year's PLA product ops summit and the topic was leaner times why we need product ops more than ever. So at least in the US, you're seeing all these kinds of, you know, governmental cuts of jobs and I kinda see, I think a little bit of pausing on companies either hiring or rolling back jobs or whatever. So people are trying to think like, do we need to be leaner? What's happening? Do we keep our gunpowder dry? This is where product ops makes even more sense. And the talk I gave last year was around Spotify. And that big letter from Daniel Ackabel. We need to get rid of people who are doing the work around the work. But as you have fewer resources and you're all trying to optimise for let's say EBITDA, top line, whatever, who's looking at this? And as you have fewer people who's actually making sure we're using the resources we do have in the right way and thinking about like R&D allocation, we've set a strategy. Is the work we've done actually executing on that. And I can tell you, probably seven out of 10 times, companies I've worked with where they've gone in and really done the work about looking at matching the allocations toward the strategy, it ends up being around 30% of the work is actually executing on this. And that's taking away like, you know, BAU, tech debt, all of that, the actual, let's say innovation work, 30%. So are you more efficient if you're cutting folks but have no visibility into that? I don't think so. So as we think about being more efficient, having more visibility, helping with change management too as teams sort of contract or expand product ops is more important than ever. So who's gonna be looking at this if you've got fewer folks overall, no one's looking and then you're sort of operating with the assumption, yeah, I guess we're executing on this, we don't know. So this helps you make sure the resources you do have are truly aligned towards your strategic intents.

  - So it sounds like they're there to almost grease the wheels, like, make the machine run more efficiently.

  - No, I mean, yes and, let's do that. Yes and. But also just to kind of hold a mirror up in a lagging sense, right? You're gonna check like sort of trailing quarters, but making sure that as we're doing the work, everybody's super aligned. Like this is the key strategy we're executing on. If you're doing skunk works or kind of thinking about this other product, no. So you don't wanna get to the end of the year and realise 30% of the actual resources went towards that. So it's managing to get a bead on and a read on what's happening there before you get to the end of the year and you're like, "Oh, we didn't actually do much of that." And we didn't meet the strategy and we're actually down in revenue. So it helps us be more efficient and be more data-driven. So as we do see companies contracting or roles sort of being put on pause, it's even more important.

  - So let me unpack that. Because there seems to be two aspects there. One is having the data to know that you're doing that and the second bit was actually kind of holding yourselves accountable to be doing the right things, to be making strategic choices. And surely the latter of those two is the product leader's job. The latter of those two. The one where it's making sure we're actually doing the right things following the, you're delivering against the strategies, the product leader's job.

  - I don't know. Typically, that ends up being on like the head of engineering, right? Where are, where is the work being actually resourced and allocated? Sometimes, they'll be measuring that, but oftentimes, most companies aren't.

  - Not where we're putting our chips in that respect?

  - Yeah, literally looking at the work we did, not only in Jira, but also getting sort of a sense from the eng leads, you know, what are the teams working on? I worked with a company that was trying to understand why they were not seeing much innovation and we started to dig in, the CTO was like, "Why are we doing this? I don't want to have my team feel like they're being micromanaged or every hour." I'm like, "No, no, no, we don't wanna know who just generally, what are they working on?" And they had offices in Sweden and Vietnam and like six different offices and it's like what are those teams working on and can we get any insight where the resources are going? So as we dug in, they ended up doing sort of a, you know, weekly assessment with their teams. Like what did we work on? And we had a couple of buckets, you know, innovation, BAU, CI/CD, bugs. And as we were starting to look at this, the CI/CD percentages were pretty high. I'm like, "This is interesting." So we dug in and asked the CTO and he spoke with his leads and it turned out that the exec team was pushing for just more things to be delivered every week just to, more was more. And as a result, that sort of increased velocity was introducing a lot of bugs. The engineering team felt embarrassed by that and they were tucking those into CI/CD versus bugs. And so this brought up a bigger conversation and it kind of dawned on the executive team finally, "Oh, because we're pushing harder, this actually has implications and we're not necessarily delivering value we're delivering." And it kind of changed the whole tone of the conversation, the more being more but really starting to think about focusing on value versus things coming out every week. So at the end of that, the CTO was like, "Can we put this practise now? I love this." So he was really against it that he was like, "This is wonderful, we can actually understand how these things are being."

  - Yeah, and I guess, and so that, to me, what I heard there was the formal, which is the part of gaining the visibility. So then enable the leadership conversation

  - Yes, and making sure what we're saying is what we're doing.

  - And so I can absolutely see that. And it felt like you are almost saying that product tops are the ones holding the feet to the firewalls. Product tops are the ones giving the visibility so that the leaders can then have the right conversation

  - Or working with engineering if they have some aspect of it to make sure like they're sort of understanding velocity and kind of how we're allocating things. But another area too is sort of sales debt, customer commits versus roadmap items. And a lot of clients I work with end up having this challenge where they've got this amazing roadmap and then, you know, we need this, not that, need this, both of those things. And then no one measures at the end of the year. They're like, "Well you delivered on, you know, 60% of your roadmap, what happened?" "Well we got, you know, the rest of that taken up by sales debt. Well what was that? Well I can't tell you, I don't remember."

  - Yeah, I think in one of the early episodes or on the channel where we're talking purely roadmaps. There was a joke about we allocate 100% of our resources to the roadmap and the other a hundred percent to customer requests.

  - Exactly, exactly, exactly. So it can help with that as well just in terms of like, how are we measuring, how do we track this? And sometimes it's just a flag in Jira, but non roadmap versus roadmap and then you start reflecting that and they're like, "Oh wait a minute, you know, 60% of our work this quarter went to sales debt. Is that really how we want? You know, can we track that back to the deals we saw?"

  - And did we make any money back for those? There was a really interesting conversation with a product leader at a product tank a few weeks off a couple of months ago where they got to the point where they knew a particular feature that a customer was demanding basically in the entire lifetime of that deal, they weren't gonna make back the cost of that feature. It was like, it made it so easy to say, "Actually no, we're not doing this and if we don't win the deal, that's okay because we're better off not winning the deal if we have to do this feature." But I feel like there might be some conflict here. I feel like product managers might feel like they've been told what to do. How do product managers and product ops interact?

  - That, I think is a misconception. So if you heard the interview that Melissa and I did with Lenny on his podcast, he said something like, "You know, the things that you usurp or take away from product managers." I'm like, "Whoa, there's no usurping. It's really symbiotic and you know, it's about enablement." And I think a good product ops person is kind of got that servant leader mentality, right? So it's about enabling the things for product managers at, you know, setting the strategy, the experimentation. It's about putting these things into a practise that starts creating that flywheel versus telling everyone what to do. So I guess what I'd like to do is break that down. I think any products person worth their salt is someone that's kind of treating product and the ways of working as as a product and understanding what the challenges, opportunities, and the gaps are and then hearing from the product team is sort of mirroring that back. It's not necessarily like you told me you want a now, next roadmap, I'm giving you a feature structure roadmap, here you go. But really understanding what that company needs and what that team needs and reflecting that back and not only putting that into practise but going back and retroing it each quarter. And we talk about that in the book with Shintaro Matsui from Amplitude and he stood up the practise at Amplitude. And it was very much about like, tell me what you need and let's talk about how to really make that a reality. But it's really kind of using those inputs to help guide the ways of working. No one's sort of sitting at a tall tower and saying, "Here's roadmaps, here's your template for, you know, product discovery brief." But it's really working with the teams and reflecting that back and you know, a lot of companies that don't have product officers, one product manager's like, "This is making me crazy, I'll do it." But what are they neglecting in their job and how are they being gold? Probably not in coming up with the perfect roadmap template. So someone's gotta do it.

  - Interesting. So we've got this symbiotic relationship. What sort of person, what skills, what experience, what background makes a great product ops person?

  - Of course, I love seeing product managers, but I don't think that's the only profile of this company I mentioned that has a number, you know, 50-ish product ops people, a number of them came from customer support. And I think they're coming at product ops from definitely one of those pillar that really having that customer empathy and understanding sort of the feedback and the experience of the customer. But this company actually ended up doing product management training for these folks so they could understand better a day in the life and how these people work. But obviously, I think ideally this person has done product and kind of seeing the challenges as a product person that aren't necessarily being addressed because your leader's too busy, everybody's working in their own silos and aren't able to sort of come together and think about how are we doing discover what is quarterly or annual planning? No one has time to stop and think about that just for a second because if we slow down a little bit, we can go faster just to think about how we wanna work together. So I think the person you hire has ideally done product management, not for not a long time, but has experienced those pain points. Either it's like we don't have a bi-directional feedback loop with sales, with customer support, with the executive team. We want to do more discovery, but there's not really a standard way of executing that and the CEO probably has a different idea of what that means than the team. So how do we bridge? Someone who has really just loves systems thinking, right? And really nothing makes them happier than thinking like, what's the best way to do this and how do we make sure everybody feels like they understand how to actually leverage this? And someone who's really excited about influencing and not necessarily directing or managing, I think the best products, people are excellent influencers. And they show like, here's an amazing way of working and we've worked with a small group, here are the benefits that they've experienced and people wanna do it that way versus like, here's how we're doing it, we're checking, we're gonna make sure you did it this way, here are measurements to make sure that you, you know, open this and access it and whatever. I don't love those sort of heavy ways of measuring, you know, quote unquote "compliance." So there are influencers, high EQ systems thinker and really able to bridge across different functions as well.

  - There's a couple of other patterns that I've come across being called product operations managers. I'm intrigued, I'm interested in your thoughts. The first one is more of a systems person and by that I mean a systems operations person. So I've seen someone coming from rev ops for example, and basically being told to look after the tools, like the road mapping tool, etc. And the second one is I wanna use the office, american office reference, the assistant to the product manager. It's the junior person that's called a product ops person and then given to a PM essentially to do the admin work. Thoughts on those two models.

  - So you've seen both, so the catchall, the junior person and then the other one was the systems person?

  - Yeah, kinda someone who's operating the tools of product management and kind of being the admin for them.

  - That's certainly an aspect of it, but that's not the only thing. And as you know, you know, tools aren't the magic bullet. You need to figure out how you wanna work, how you wanna present things, how you wanna think about structuring it before you. Use a tool and with roadmaps especially, I see this problem a lot of companies I end up working with, they're like, "Well we got X tool but it doesn't do this." I'm like, "Well who brought this on and what were your requirements?" "We don't know, we just brought it on." So doing this manually understanding what you need and then sort of thinking about well this X tool does Y tool give me this what I need versus trying to squish the ways of working into a number of these roadmap tools. So I think those are elements of it, but the catchall, I have seen that sometimes like, "Oh, we're taking on bugs." No product managers need to own that. We can think about how to manage those in a more efficient way or you know, if they're coming into a main email box, how are those things being triaged and they can think about supporting them to, you know, first person to take it, da, da da and think about how that gets passed down. But having them take that on completely, I think also disconnects the product manager from the full cycle of their product and understanding what the challenges and hopefully opportunities.

  - Yeah, so I completely agree. I just was interested in your perspective. 'cause I almost feel like the assistant to the product manager model in particular is a bit of an anti-pattern that I'm seeing in some places.

  - I haven't seen it a lot though. Are you seeing it much?

  - I've seen it enough to call it a trend in some places. Not enough to say that it's common, which I'm glad about. But that's again part of the point of talking about this as a subject today because I wanna spread good practise and help people understand when things are not the best way of doing things, which segues us perfectly into, what's the biggest mistake you see product ops people making.

  - I think taking on some of those things in the pursuit of creating value. So one person I know who's really respected in the community, she's like, "Yeah, our team took on bugs, that wasn't a problem." I'm like, "You know, what is it gonna be next? And you know, if it works out for you, fine, you've got the bandwidth for that, fine, but what are you not able to do that probably provides higher value? And how do you sort of measure success with that? Are you giving the product managers more time? How would you measure that?" So I think that is a problem I see.

  - I guess I could be someone seeing it as a career path of, well, I want to do a bit more of the actual product work 'cause I want to move into products as a product manager in the future.

  - No, not necessarily. I think in this case, I'm thinking about it's more in the pursuit of trying to provide more enablement overall for the teams. I think there's a middle ground, I don't think it's like don't do triage, but I think there's some way to think about helping them learn how to fish versus doing the fishing for them. So that's one area. I think another is a team of one just so passionate about wanting to make a difference, taking on too much and getting nothing done. So in the book we talk about the three pillars and if you're starting out, consider where your biggest gaps are and the opportunities and start there. Don't try to peanut butter across all three. And it's hard not to because you get excited. People want this, they want that. So that's challenging. And in the book, we talked to Blake Samic who stood up product opposite Uber and Stripe and he's at OpenAI now stood that up. And something he mentioned was this, he was being asked for more and more and he was like, "Well that sounds great, here's what our roadmap looks like, but if we did have that, wouldn't that be great? We would need another headcount." And then you sort of start painting the, you know, picture of that vision, the, you know, vaporware, whatever. But trying to just be really focused on that. I think in pursuit of really wanting to deliver more, you end up delivering less and frustrating yourself.

  - Sounds just like product management work. Yeah, I mean you used the magic R word, you mentioned roadmap and we are a channel called "Talking Roadmaps." I have to now take us into a couple of questions about roadmap. So does product ops need a roadmap for the function for the team?

  - Do they need their own roadmap? Absolutely. And I'm glad that you asked that because I think the sort of peanut buttering starts when you're not really focused on what am I gonna deliver? What am I gonna do and what I'm not? You know, what are sort of the areas of enablement and what would be great, but I'm not? So above the line, below the line. And even if you do it that way, just to be able to for yourself, but also as other folks ask for things you explain like with my current state and my, you know, capacity, here's what I'm able to do. But also for yourself too, like will coming up with a roadmap template, giving yourself sort of an end date is good so you're not getting into perfection versus good enough and let's get going. So I think a roadmap's really important.

  - And so like, I mean we've talked about ways of working and roadmapping tends to be quite a core way of working or part of the ways of working with a product team. So how does a product ops team get involved in the road roadmapping practise and so on of the broader product organisation?

  - So I think first of all, what's going well? What could be better? Typically, with companies I work with, that is usually a gap/opportunity of, you know, improvement. So understanding like what's going well, let's not mess with that, but what could be better? What are the challenges? And the typical challenges, I'm sure you see this a lot is, you know, our cross-functional partners not knowing how to align in and share their ideas of what they're hearing from customer. And then that ends up resulting in just constant emails versus we knew that we're talking in March and then June, you know, whatever they would understand, they could save up the ideas and share those out. So I think entry points is an area. So thinking about what's working, what could be better? And then what is the sort of structure of it look like now? Where is it stored? I mean, that's such a basic thing, but people are like, "I don't know where to find it. I had a version from March and it looks like you guys completely changed it up." So kind of boring, but like where are we storing this? How do we access it? If it's a tool, how do we have enough seats view only versus, you know, folks that can edit it. And thinking about if we're doing annual planning or quarterly planning, when are we tweaking it, when are we sort of reviewing it versus, you know, open season. And I think being able to put a little bit of structure around that ends up saving a lot of headaches in terms of ripping it up every quarter or it sits the same for a year, even in spite of new insights people may have brought to the table. And also how to roll it out as well. So sometimes, product teams will make these amazing roadmaps, but folks don't know they're there how to access it. So, you know, it's this beautiful thing that's sitting in a glass jar. So that's part of it too, the deployment of it. And if you're in a bigger organisation, your CPO or SVP may not have time to coach the more junior folks on it. So product ops can help with structuring it, framing it, and then how you actually deploy it and socialise it. So I see a lot of symbiotic support.

  - Yeah, I mean I'm hearing a bit of driving and wrangling the cadences to get the content together and then helping communicate it, which is how I think about roadmaps. Those you talked about quarterly, annually, like what's that cadence? Like one of my favourite things to kind of tell product managers forever has been, "Map your corporate calendar. What happens in June, what happens in July?" Don't be surprised when in June, your boss is going off to do the corporate strategy offsite and needs some input from you because it happens the same every year. You should be ready with your input. And yet, every June, everyone's surprised that it's happening and they're not ready for it. And so I can see product tops helping keep us honest with in that environment.

  - Exactly. And then other things too, like, as a product leader, I would notice end of quarter increase in volume and a decrease in revenue. And it turned out sales was putting things, you know, lowering prices to bring in volume. They were gold differently than we were. So I'm like, "Well wait a minute. Luckily, this is a high margin product, but we need to talk about this." So my products team helped us come up with sort of council talking about these quarterly sort of end of quarter pushes and what those could look like. So yeah, exactly. Those types of cadences, they're gonna keep.

  - Interesting. Okay, so found feels like, as product tops were almost helping create the space for some of the conversations that should be happening, but sometimes get forgotten.

  - Right, because you know, as product folks, we're caught up oftentimes in the execution of it, but have we considered why is this the right thing? What are the potential bets we're placing? And not only thinking about success from an engagement or adoption point of view, but revenue and that's an area I feel like a lot of product folks are light in that commercial sensibility and it's hard to learn.

  - Actually, there is a great resource that people can use. But with what other resources are out there or who else is advice out there do you listen to around the product ops space?

  - Melissa Perri obviously posts a lot about that. I think she's a great resource. I like to, John Cutler occasionally touches on product ops and I think he's usually spot on. So I think that's a great one. Some of the folks that are working for roadmap companies like Janna Bastow, I think she's got some really good insights on product ops in context of roadmaps and that's where I feel like there's a lot of connectivity. Those are the ones that come to mind right now.

  - Perfect. I'm sure that people will check those out and I mean Janna I think was episode three or four of the year the first season. And a good friend, I might have been out with her and James on Monday night at MTP.

  - That's nice. That's awesome. Oh yeah, yeah, MTP. That's great. But those would be the main ones.

  - Okay, Denise, here is now the big one, the hard one. If you had to distil your philosophy on product tops down to one or two sentences, what would it be?

  - It's like investing in tech debt. It's hard to measure. There may not seem to be a need right in the moment, but it's gonna make you go faster in the future.

  - My Steve Bankism, what should I have asked you about product ops that I haven't?

  - I guess what does success look like?

  - What does success look like?

  - Well, I'm glad you asked. I think you can consider it in a couple of sort of different lenses, right? So organizationally you could be measuring efficiencies in terms of cycle time, throughput, team health, team culture, capability benchmarking, right? At the product team level, more of effectiveness, right? Ideas generated versus production. Not only think that these are things to consider how many iterations are needed to sort of launch at, to reach positive results. Number of experiments, not that we just wanna jam in a lot of experiments, but are we, you know, sort of supporting an iterative innovative culture. Our product managers typically focusing on higher value work and that's gonna be a more subjective, self-reported type of metric, but important to start tracking. And data readiness, right? So as we think about those moments of every June and starting to think about roadmaps or as we're considering quarterly business reviews, do they have those things they need? A massive retailer I worked with would sort of reinvent the wheel every quarter because they had no visibility into metrics or roadmaps and we just sort of hand stitched together and the second the meeting happened, everything was out of date and it sort of started again. So that seems like a pretty easy and successful thing to measure. And then on the products team level itself, reducing waste, right? So cost savings, reduction of time and increasing value. So that will be the self-reported things like, you know, engagement surveys, NPS, but with a lot of feedback from the, you know, forget, I don't mean NPS, no NPS, I'm not an NPS fan. But engagement surveys and how are we helping support decision making and improving that. So are we able to create roadmaps that aren't going through 80 cycles? Are product managers able to sort of show their work in terms of why they got to you know, roadmap candidates? So it's something that comes up a lot. I teach a quarterly product ops masterclass. And a lot of folks, and I think this sort of speaks to the maturity of products. It's like, well what does success look like? So thinking about that scorecard I think is important in reflecting that back to show the value.

  - And that's a perfect segue. You even started it, Denise, it's been wonderful having you on the show, but I'd love to give you a chance just to picture yourself how people can get in touch, get in contact, and how you can help them.

  - Yeah, lovely. LinkedIn or denisetilles.com. T-I-L-L-E-S.com. Drop me a line. And I love working with companies to think about creating their product operations strategy if you have it. What is sort of a maturity assessment look like? You know, where you go, what's going well, what could be better? We can benchmark because I've worked with so many companies about what good looks like, how you get there and then coaching. So that kind of gets me up in the morning.

  - Well, we make sure those links are down below in the show notes. Been a pleasure having you here, Denise. Thanks for your time.

  - Thank you for having me.