Should Product Operations Operate at the Portfolio Level? | Becky Flint

In Episode 19 of Talking Roadmaps, Phil Hornby speaks with Becky Flint about why product operations must operate with a portfolio lens to maximise organisational impact. They explore the evolution of product operating models, how shared context accelerates decision-making, and why portfolio allocation often drives greater strategic ROI than individual product choices. Becky also breaks down the orchestration role of product ops in connecting strategy, investment, and delivery across teams.

Becky is a product and tech executive based in Silicon Valley. She has built and scaled product and engineering teams globally and established product operations and portfolio management for startups, unicorns, and Fortune 500 companies such as PayPal, Shutterfly, Bigcommerce, and Feedzai. Currently, Becky is the founder and CEO of Dragonboat with a mission to empower product leaders and their organizations to accelerate product investment outcomes.

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

Should Product Operations operate at the portfolio level? | Becky Flint

Becky Flint and Phil Hornby

In the next episode we have Thomas Hartmann, Cofounder @ Product Masterclass. So watch out for this bonus episode!

• Transcript

  - Product ops is when it comes to strategy, when it comes to delivery, it really needs to take a lens of the portfolio. It's very different product managers think about their customer, their product, because that's their focus. Product ops, the same thing as product executives, have to say across the board where I may be over invest, where I may under invest, where I may pull resources from one to the other. And if you're in the product ops role, you're not in that conversation or driving that conversation, you try to work in your product area, that is a big problem. Welcome to "Talking Roadmaps," Season 2. I'm so pleased today. We're joined by our first ever repeat guest. We have Becky Flint, the CEO of DragonBoat, who was an early guest on season one, when we talked about roadmapping. She's back today to talk about product operations. But I'll never do it justice. Becky, give us a bit more of a flavour of who you are and whatever you want to introduce about yourself.

  - All right. Well, thank you for inviting me, Phil. It's great to talk to the community in the first season about roadmap. I think we cover a little bit about portfolio roadmap. And today it's even more exciting to talk about operations and actually product operating model in general. So a little bit of intro by myself. I'm Becky Flint. Currently, I'm the founder and CEO of Dragonboat. Dragonboat is a platform to strategize and deliver, for you to strategize and deliver your product investment that actually covers the end-to-end at scale and with the speed. Now a little bit about myself, why did I start a Dragonboat? i was joking that I've been working on the product to solve the needs that DragonBoat was solving today throughout my career in the earlier days, it really building product operations, the portfolio management at companies scaling very fast called PayPal. And later on I went to a few other companies as well through, you know, Shutterfly's and BigCommerce and AI machine learning detect fraud companies to build out their product org in the first time. And that was a lot of interest in how do we think about product investment? How do we strategize where and how and sequence them? And then how do we deliver the plan and strategy will come together and eventually not only just deliver software, also deliver value and then also deliver the business outcome. So we need to capture that as well. So that's a little bit about me and interest to be here really is to say how we as product people, product ops people, and product leaders can really make decisions to orchestrate the decision of the organisation.

  - If you're enjoying the channel, subscribe, hit the bell, and give us a like. I mean, decision-making is my favourite subject it's the book I'm trying to write. Because I realise that the centre of all product work is decision making. But actually I don't think it gets spoken about quite enough it's kind of this yes we make decisions then we talk about all the other parts of our craft. And yeah it's definitely a common theme I'm seeing coming through in the discussions about product operations around helping enable better decision-making, which makes me think maybe I'm more of a product operations person. Hey, who knows? But you hit an interesting note there around the product operating model. Now, we've had Marty on the show, and I know he's kind of one of the people who coins the phrase there, but it was before he'd written Transform. So it's before the book came out. So just for the purpose of our audience, what do we mean by the product operation operating model?

  - Very good call out. So I want to take a step back about product operating model is that, you know, obviously there's an ideal way of operating product. I also want to say something that may be a little bit different to some common belief, which is every company, when you have people build product, you are running somewhat a product operating model. That may not be the best, may not be ideal, but you are operating. You have a way of operating and you're operating, have a understood relations. And if I were to use the term we like to use, we call it operating ontology. It's like you have your semantics, you have your interaction, you have a cadences, you have your roles. It may not be great, may not be the best, but you're running it. So, you know, throughout DragonBoat, we met a lot of customers. They said, you know, we're not ready. I said, "What do you mean you're not ready?" You are running a product operating model, not the best, not the greatest, but you're doing it. Therefore, any moment you are ready, you are ready before. So how do you make yourself and your organisation operate better? There are certain ways to get there. So product operating model, in a way to say, how do we operate better? How do we take product thinking? How do we think about investment? How do we think about our customers and think about strategy? Those are like better way or ideal way we try to go to but every company is operating product if you have product people right? So I just want to say these are two things you aspire to versus you are actually doing it. You are living you know at your best and fullest but you are living.

  - Yeah I mean in fact I'm just reading the notes I had from before the show and yeah it's... You specifically use the phrase product operating models. It's an S on the end there, it's plural. And as you just described it there, I heard about a spectrum or a continuum and maybe multiple continuums on multiple different facets of a given product operating model. I shy away from possibly the term maturity model, but, you know it's kind of it speaks to that sort of space it's like there's this should we say nirvana states that we often think of a perfect product I don't think it exists in any company ever anywhere in the world. But different facets we might get all the way on one facet and some other way on another one and it's about finding the right fit for our organisation and the right model for our organisation. Yeah, I'm with you there.

  - Yeah, and if I may get a chance to touch upon that, it's also the evolution of the company itself, the environment we're in, right? The business itself, and also the market condition of that. We all operate not in silos. So think about it. Throughout my career, I've gone through a lot of sort of decentralisation, centralization, and, you know, shared model and the agency model and all that stuff. I think it's not like, and sometimes the company, you know, especially at the team level, they're like frustrated on why we keep changing, right? But the reality is this is the business that keep changing your think about it, you know how your... AS lot of times your technology platform determine how you operate right? So you want to don't create all this a lot of dependencies because your organisation create a lot of dependency, your structure, you know Conway's law, right? Conway's law says that your org structure reflect you know interactions and . So the idea is that, but then because your organisation evolving, you have a bigger product, you add more product, you consolidate product, you sunset product, you just have to change that all the time. So I think a product operating model, you can think about two ways. One is what it look like as a structures and aligns and interactions. The other one is how you model your product operating model over time, depending on the size of the company, the evolution of things and technology. Now you have, you know, just think about what happens with AI? If we change a lot of things how company going to operate, right? Including your structure of your org structure. Same thing for, you know, prior to AI, regardless of social or mobile, before mobile came along, you just team. Now, as a mobile, you say, okay, we have to have a mobile team. They have some similarity, but they are different because they are different products. So that changes how your structure of your team and the team typology is a part of your product operating model, right? So I would say product operating model always evolves depending on a lot of factors. But how you model it, right? How you structure it, that's a certain sauce and the best practises.

  - I mean, you just hit on one of my kind of my observations recently as well. Yes, when mobile appeared, we suddenly had mobile teams. We kind of created that dedicated vertical team for mobile. More recently most mobile... You don't typically have a mobile team they're integrated in with the rest of the org and I see that same pattern happening with AI where it's a vertical team in many cases whereas I think it should be a horizontal enabling team in most cases. But you can understand a vertical team in terms of building the competence, keeping it kind of focused to actually get ready for that, really leveraging that value. But ultimately, it should be everywhere. It's been leveraged across the organisation. The same way as mobile is. Thee same way as connectivity and the internet was, you know, so if we go back even a further generation it's a cross-cutting capability as opposed to a, you know, one pillar. We go through these rounds of organisation. In fact in some of the previous conversations I've had with people product ops has been seen as part of the organisation that helps facilitate thinking about that team topologies, that organisational structure. So is that one of the key pillars of product ops? What do product ops do and why do we have them? Maybe we can go that direction and how does that connect to the product operating model?

  - Yeah, very interesting conversation here because I get asked a lot, right? What does product ops do and how does it relate to product operating model? And I would say they are different. I know obviously Melissa and Denise's book has the pillars of product ops. I think that's really one way to look at it to say the type of impact and focus they do. I think you can also look at different lenses on who they interact with and what is the outcome you want to drive. And the product ops is sort of like people want to use the connectors or glues and whatnot, right? I like to use connectors and glues to drive. It can't move anymore. But the organisation is living. So I always want to say it's the connectors and you can adjust. But regardless, the context is the same. Which is in a larger organisation you have to have a specialties so that you can do things better and faster similar to your mobile example. And when you started with the mobile or now you started with the AI, you have to build the capabilities and competence in the organisation that no one else has you can't just give it dedicate to everyone so nobody's going to achieve anything. People really have to focus on something to do it well. so the specialisation happens as companies scale. Otherwise if you do everything then you can do something well right? I think a long time ago at PayPal we had a rule to say you can only solve one thing. Like you are allowed to only solve one thing at a time. And that's really like in the earlier days this is helpful so that you don't everyone do everything and nobody can be expert to something really well. So the special experts are that. But then experts need to work together so you have to create this overlap of experts then overlap of expert is where the ops come into play. Now when you think about that it's okay so what does the ops do? Is to take part of the things that the shared, right? Think about the services if you do applications there are services. These are shared services it's not built internally so then you don't have to have a duplicated codes, how to maintain and no best practises so the shared services is the manifest into the product itself. Now what are the shared services? A little bit of covered by Melissa to this book about the three parts. But I would also think a slightly different lens to say, okay, there's the shared services about strategy. So how the product team, individual product managers interact with the executives and the business and strategy. And that's one part of it. And then the other part is how product managers work with each other, because 90% of software build was with dependencies, right? Almost nothing done at scale by one team. So that how you work with each other, how you orchestrate that? And then there's also another one is how you orchestrate with the customers and intake. Again, everyone will do a little bit of that. There's some and even with engineering. So you hear R&D ops these days, you hear a programme or engineering ops. What they do is how engineering team can work together. Engineering can work better with the product. And then you have a GTM ops sometimes working also with the product to say how product bring to market. You think about the end-to-end product, truly drive outcome. The GTM is a very important part of it. And then there are sometimes people have a design ops. So how do I make sure that design can be decentralised, you call it a federated model, but design also need to be centralised. You don't have org charts on your products saying, this team looks this way, that team looks that way, right? So I want to say, so going back, a long answer to your question, what does a product ops do? What product ops does is to orchestrate from a strategy, business strategy, to investment, to building product, to customer interaction, to driving revenue, to best practise of a code. So they would need to orchestrate all of that. So even within product ops themselves, they would have a specialisation over time at scale. The goal is to say we build the right product, we form the right strategy, we build the right product, we actually can deliver it. So the roadmap is the beginning. How do you deliver it? How do we adjust changes? And then ultimately, how do we capture value? So each step the way product ops can be finding the shareable services and then move into their realm of responsibility and finding specialties that need to be carried out and leave them at the team level or a functional level.

  - Interesting because yeah one of my observations is that product ops work has always happened, just didn't always have the title. The interesting thing is some of the things you say there, the bits that always were the fun bits of product management work, the bits of filling the gaps of bridging between one team and another, and I'm finding that kind of shift towards, well, actually, no focus on what you and your team is doing and we'll bridge the gap. Maybe I'm old school, but I feel like I'd end up fighting with a product ops person because I like that bridging the gap.

  - I agree with you. There are a lot of similarities there. I also think there's a big part of how the philosophy and how a company runs a product org. And I would use an example of how I got into product ops. I started in early 2000. And why did I get into product ops was because at PayPal, we were expanding internationally. And when you're expanding internationally, product managers' job becomes so much bigger. You have to design and build a product and make sure it works internally with different product. You also have to make sure the product cannot launch to market if you're not having internal connection with the internal finance and others to make sure banks and all that stuff connected. If you don't work with the legals and all the other teams. So all these other things you have to do, if the product manager needs to do, then who's going to work on product in terms of experience, privatisation, scope, engineering, other product teams interaction. So that part is not there anymore, right? So that's the most basic form of the product ops is to say, to bring a product to a market, there are a lot of other things involved. And when you just have one product, relatively internal facing, you don't have a lot of that. So when you have more external facing, then you have to say, I'm not going to be more like doing a lot of coordination with others, actually, I need to spend time to really figure out how product is going to work. What's the holistic experience? How can I scale that to others and stuff? So the time from product manager is just need to split. That's the most basic version of product ops, is all the things outside a core product thing. The second part of the product ops is most impactful, which is how do you orchestrate between product at the level that even not product yet? So that's a portfolio management and a strategic orchestration. So in most companies, you would have, well not every... Every single company should have it, right? You should have a longer term strategy that's connected to your vision. How do you turn it into your features? There are many steps involved and many people involved. Who's going to do that? There's no one. Like it's not individual. Like imagine every product directors and product managers to get involved in that process of how chaotic it is and too many opinions. So strategy is a top-down process regardless if you like it or not. If the strategy didn't come from the top we're all bottoms up strategy we're not going anywhere it's a strategically suicide for our organisation, right? You have to say, here's where we want to go. We have four or five strategy focuses, and that orchestration is more leadership-level product ops person. In a company, sometimes their job title is like a VP of Product Strategy. Sometimes it's strategy ops or something like that. And that is the higher level orchestration that would connect not just between product executives, the product VPs, a bunch of them, right? It could also connect it to your engineering counterparts, design counterparts to say, OK, here's our product strategy. Here's a bunch of things we wanted to accomplish. What does it take to make it happen? So you need a cross-functional input. And then we say, can we do it or can we not do it? What are our trade-offs? What are our scenarios? And once you design that to say, okay, here's strategy we're going to go, here are things that we're going to go after and chase, then that would go to the next level, right? So that product ops at a strategic level is it's orchestrated across different functions to create a strategic roadmap that we want to go there here's what we want to do, so the strategic roadmap will guide the next level roadmap. Because you want to make sure your strategic roadmap is just not going to stay in another room your product manager just going to prioritise whatever they think, right? So you have to connect that down, right? So some company called it quarterly planning or something like that, right? Or PI planning, I'm not a big fan of that, but I just would do that quarterly. You translate from a strategic roadmap to a typical product roadmap or feature roadmap, right? In the strategic framework, that's the execution of the strategy. So typical product roadmap is executing strategy, not like whatever you wanted to do, the customer says. That's my bit. Customer don't tell you what to do. Just because you heard what customer said, you did all the fancy AI analysis, doesn't mean that's what you should build.

  - It's should align with the business direction as well. It's like that's a lens that you put on top of what you hear from the customers and the users.

  - 100% and that's the translation layer, right? That's the product ops sort of the next level of product ops need. And then sort of the one I mentioned earlier is more like a team level of product ops need. And through working with a lot of companies and customers, I think sometimes you see a lot of team level product ops need. They're like, oh, I need to help my product managers. All they say is I need to help my product managers. I think that's a good thing to say. But why? Why do they need your help? Like you said, I kind of like I want to do it myself. Why do I need product ops? Maybe you don't. Maybe the product ops should get out of the way to say what I need to do is send a level higher to do orchestration between product teams because I need to help them to prioritise. As a product manager, you always think your thing is the most important. But with 80% or 90% of dependencies, who's to say if you have five things from John and the other PMs have five things from John and you guys are going to prioritise differently because you have your lens and they have their lens, then John's stuff is just going to slide into pieces, it's not going to work. So that's why you need a portfolio and product ops to go to the level higher, not at helping product manager at the individual level, but helping product organisation to be able to execute the strategy, right? So that's a deliver strategy and a define strategy. That's the product ops role. I think the ideal world should be is orchestrate define strategy, and then orchestrate and define how the execution roadmap can deliver to the strategic intent.

  - I think the key word in there that I heard was, and I want to emphasise it for our listeners, was the orchestrate part. Product ops are not the ones who are defining the content, but they're creating the rituals, the meetings, the workshops whatever, to help get everyone to that place where it exists. So with the product leaders and other cross-functional leaders in that room with product ops creating that space and helping them get to that answer, right?

  - Yes, and I also would add to it, right? In the room are looking at the same data with the same context, right? So I would say why DragonBoat exists in the first place? Is that the challenge of tools you look at today, regardless of work management tool, obviously work management tool is not product tool. Now, even if you look at a product roadmap tool, they are very limited because they don't have the strategic context, right? So every product managers could be prioritised differently. And you look at the traditional product tools, it's almost like project, project, project, or folder, folder, folder. There's a one level higher orchestrating across the board. So nobody has the whole picture. Therefore, the prioritisation of one team versus the others is not the same. So now the orchestration happening here is one is how people work together, the cadences, the meetings, but more importantly, what data everyone is looking at and what the context of the data.

  - What's super interesting is I recently went back to a super IC role and everything you're describing there is what I'm essentially trying to bring in place in the organisation. Because there's a bunch of other product managers and we actually all have a fairly shared resource pool to work with not dedicated teams and that trade-off we're having constant conversations and I'm spotting gaps in our tool stack and things like that where we just don't have that visibility be able to have those conversations and that's exactly what I'm driving a lot of at the moment it's like so I'm coming in with this fresh set of eyes as a new person and able to have those conversations. And then looking at the things that my part of the product needs quite hopefully quite maturely saying actually I can see why your thing is more important. I'm trying to drive that conversation in those forums, but it turns into a lot of work already.

  - Yeah, I mean, imagine it, you know, you're talking about two teams or five teams or 10 teams. It's exponentially higher because you have this random connection of a five or 10 or 18 or 25, right? So that's going back to how, you know, I don't want to say how DragonBoat started really talking about the company so much, but more about the problem we're solving is because when you scale product, you say share the resource pool. Guess what? If you have 80% or more dependencies, it is shared across the company, right? Because you're dependent on the other one. You're basically sharing your resources. It's not just a five or 10 or more. When you have those, these kinds of dependencies basically kill the company. Because look, you talk to anyone at a company of a certain size, how long do you take to do quarterly planning? Everyone would say, oh, you know... Like a product ops HQ actually had a survey, I think a year or two ago, right? So companies typically spend four to six weeks and up to like eight weeks. I said, well, eight weeks is almost like two months. You spend two months to plan a quarter, right? And that's like, you know, then, you know, within a month, things are going to change because that's just how it is. And imagine if you have to make decisions like that, and take so much hundreds, if not thousands of hours, try to give everyone on the same context, using the same data, it's very challenging, right? So to your point, what product ops do, especially in today's world, is in addition to cadences and stuff, but more importantly, how do you speed up the effective decision-making with the context of data so that you get going, right? You don't spend time to plan when everyone says, what I'm supposed to do, I just do little things so that I can kill time until you get done with the planning. Imagine the waste and opportunity cost from there.

  - I probably say it depends far too much as every product manager does, but the reality is that decision-making in product is all contextual. It all comes back to that context and shared context definitely speeds up that decision-making because we no longer are coming from a knowledge or an information asymmetry point, which means we're able to hopefully make more aligned decisions. Making clear what the decision criteria are as well can be super important there. The context and how we're deciding and what we're deciding based on, which comes back I guess to your strategy lens of that's one of those criteria that we need to use to help us filter and make those choices.

  - Right, that's definitely the, you know, people like to say product management is art and science, right? And you really think about that. The whole world of art and science is the decision-making with the context. Because even coming to art is generally acceptable, accepted sort of the standard of what is good, what is not, right? So there is a standard around it. So that's still science, right? So the context and shared context is really what guides the decision. And I forgot who said that. You know, if everyone has the same information, reasonable people will come up with the same conclusion. And like you said, the asymmetry of the information and the context. And this is, I would not say the future of product ops, but that's the right way to think about product ops. It's how do you enable the contextual data but not overloading so that the people can make a decision. So when you say putting people in the room discussing it really think about if you sort of decompose that activity really is to say how do you get people have a shared context that's right. And then when people have a shared context decision is pretty much obvious.

  - Yes in fact I contend that there are three stages to decision making. There's getting to the decision, making the decision, and then implementing the decision. I think implementing is just as important as either of the others, because if you do something different, you made a different decision. But equally, I contend that getting to the decision is the biggest by far. If you do that well, making is usually pretty quick and pretty easy because you have to take people on a common journey. Often part of the problem I find with decision-making is one person is this place on the journey and another person is here. Even if you have common data, this person's already read it all and understood it and analysed it. This person hasn't even looked at it yet. And we're trying to assume everyone's on the same page ready to make the decision and it's just not true. So as humans we have to walk each other through that same journey to get to that decision making point and yeah usually you're going to end up with... If you understand the context and the criteria you're going to end up with a common sort of perspective on the decision. That said, there's not always data, right? I mean, Tony Fidel in Build, talks quite a lot about the fact that there are just opinion-based decisions that we're going to need to make and accepting that sometimes that's the case and just calling it out being honest about it I think is also quite important.

  - I agree with you so you mentioned something it's very interesting I want to say I would have called the bow tie model. Think about it you know sort of coming together make a decision the data is and get people on the same page it's like the one side of bow tie, right? That's the like this, from... Making a decision is a little thing in the middle, right? And then let's talk about the next part, which is to execute a decision. And people really sometimes forget the executed decision is actually also a lot of things come in. Because when you go there, things come out. And that's very similar to forming a strategy or building a roadmap, right? Forming a strategy or building a roadmap, well building a strategic roadmap is . You're coming to here, so you gather inside, you analyse options, you look at the trade-offs. So that's like the bow tie into this middle. Making that decision, deciding on a roadmap, it's not terribly hard once everyone come along, right? But then executing it is another sort of open up the funnel if you will, because anything could change. The assumptions are no longer there and other things happen. And that's the same as your product investment and portfolio investment. It's like a strategizing, it's coming to the middle. And then delivering is like going back up. And that's constantly evolving. And that's the role, you know, both you can start at product ops or product leaders and or just how the product operating model runs. So we've talked about product operating or product ops helping a lot here. It sounds like it should be obvious, but how do we justify having a product ops team then? You know how do we communicate it's ROI maybe?

  - This is actually something really important is how do you prove value as product ops? And sometimes you know, sometimes you have a hard time describe. When you say my job is to, you know, kind of running the process, running the product operating model, there's no tangible ROI there. So it becomes an overhead. In the organisation, especially more and more so anything is measurable, then people say, what is the value? You have to define what is the success for the product ops and how do I measure that? And then I say, would ROI justify to have one or two or three? So I would say play the devil's advocate. If you can use AI, data, software, tooling to automate 80% or whatever percentage of the busy work, then you can say, I just need two or three people to be able to drive the data, getting the visibility and drive decision-making, ensure investment to the thing. Then you don't need a big product ops team because what would they be doing anyway? They're going to fighting for what product managers will be doing. That's not the point, right? So I would almost say, what is the problem we try to solve here? And what does it need to solve that problem? And I want to say, should product ops be part of the solution of that? So, you know, going back to how product ops came into play, even in my career, right? So we initially we have like one product team had one product ops because the work is almost more in things outside the product, right? Later on we create a playbook, we have a system, a lot of things get taken down by functional team so the product ops the one product ops can own like five product teams because they take out the things that belong to function because they build the best practise and excellence, right? So then these things can be done more efficiently into the other area so their thin layer of orchestration their best practises is lighter. So then I want to say if you're a product ops person, if you do the same thing year in and year out, that is a problem, that means you're not efficient. You have to say, how can I get like a mobile? Let's use the example. When you have a mobile team, we don't have mobile team today anymore. Why? Because they already built best practises and coding in the different teams. Now, maybe they have a mobile standard, maybe they have a mobile architect or someone still owns this thing. Make sure we're not going all over the place. Maybe you have a review a standard team, whatever. Did I say product ops is going to go away? No. What I'm trying to say is in the beginning of the journey, if a company don't have product ops, and there's a symptom of that. Things got a lot of duplication. We have a lot of dependencies. People cannot move. We don't know everyone is going on. And then go to a marketing team and say, oh, I thought you guys were going to deliver last quarter. What happened? Or say, no, no, no, this is not ready yet. There's a lot of challenge of your... I would just say, put everything on money, right? If there's no money, there's no money. No, this is a cost. When we have product ops, it's a cost for organisation. So what is the benefit? Benefit is like the reduce the cost from a bad and completely complicated and confusing product operating practise today. So communication, planning, alignment, that type of work, right? So some of them is like a customer interview and all that stuff. These are efficiency gain. But efficiency gain should go away after a couple quarters if you do it right. So then it will become like a well-oiled machine to have communication, things go out automatically, you have a tool, you have a system, you look at it, right? So then what? If your product ops that they'll focus on that thing is not shrinking over a year, then you're doing wrong. S what do you need to do is like okay do i just let go of the products that's not the case. Because when you solve the first layer of problem you have a second layer of problem, right? Just like a game, you open the door, there's another level there's another level, right? So actually I had in my PLA, I had a talk, I think a few years ago, I had a product ops roadmap to success into the level of impact and or maturity of the product ops function itself, right? So first you get some foundation, operating data and so forth. Then the next one will be saying, how do we make sure we invest in the right thing? Now you're not just outputting anymore. You actually make sure we're invest, right? Then you start to orchestrating strategy. And you can speed up the things, right? So orchestrating strategy is the second part of the product. And then you have to speed up. What can I do to make things faster? How do I automate most of them? If you don't do the job to automate yourself out of your job, then it's not successful, right? You really want to say, how can I do better, faster with less resources? Myself and my team and my organisation.

  - Totally agree, I love it. And one of my follow-up later questions was going to be, do we need a roadmap for product ops? But it sounds like the answer is yes, and you just described it. You did use the dangerous word towards the start of that. You said the word process. And I know that as Melissa and Denise published their book, there was some debate on Twitter, I seem to recall, about process people and are we creating more, and is product ops just that? And I'm not saying that I believe that they are. But there was an interesting angle as well that you talked about. Yeah, it looks like a cost. And one of these patterns that we've seen in the last few years is something that looks like a cost, like a process-oriented role gets taken away sometimes as one of those early headcount reductions. Similarly I've even seen product people going because the reality is you probably get away for about a year without a product management team if I'm honest because there's a plan in place, there's a direction, engineers will continue executing. We'll end up going the wrong direction because it won't have the steering that's needed it's almost like a second effect layer there like no product ops means that the product manager are going to be less effective. Which means the engineering team is going to be less effective. And so if you peel away both of those layers as cost savings, I'm hypothesising here. I could imagine seeing that efficiency and that effectiveness as well going down massively. And I've just ranted, but any thoughts there?

  - Yeah, so you covered two things. One is a process in general. And the other one is, you know, the second order effect. If you remove quote unquote, the process owner, what's going to happen? So let's talk about the first part about process. It would be silly to say process is bad. What do we do today? Right now we use the software. What does the software build on? You build applications. What does this do? Process, every single application is a process. Is the software bad? No. But why is it there? They run on themselves, right? So the thing is this, you process is a product. It defines how people and organisation work. If it's not clear, there's no common practical, then everyone going to invent their own. That will be hugely inefficient. So you dedicate someone to do a good. If you're in sales team, do you have a sales process? You bet. Why? Because then you can improve win rate. You can reduce overhead. Like that is a driving efficiency for sure. No process is bad. But bad process is just bad process because no process is a process. How you gonna work? That is a process itself. So how can you say oh we don't like process, we don't... But the fact that we're talking about we have an order you say something i answer something, right? That is a process. If you and I both speak at the same time, it's going to be chaos, it's not going to work. So a process is just how things work in the sequencing and who get involved and when. Regardless you call it or not, it always exists. Therefore you might as well have a good one and the one that's constantly evolving lightweight and streamlined and flexible and solving a problem. Process is a product. And by the way, I also have a blog post called "Process is a Product." If you don't maintain it, you have a process debt. Hey, in any function you have, there's not the best... Not every salesperson is good. There are ones not bad. You can't say sales is bad because there are bad salespeople everywhere. You can't say that, right? You can't say engineers is bad there are bad engineers everywhere. So therefore you can't say product ops is bad because they're processed people, no there are people doing bad process or people just do processes for the sake of process. That's definitely not good. But if you don't have a good process that's definitely bad.

  - I think John Cutler said it, my favourite way a few years ago. Something like the processes exist. Whether you recognise them, whether you codify them or not, they exist, they are there. So surely it's a better choice to take control of them and design them to do what you need them to do.

  - Exactly, process exists. The product operating model exists. It may not be the best you want to be, but you better go improve it, right? Because that just exists. It's just like air. So that's the first part. Second part I want to cover a little bit more I think, is to say, hey, what's the downside? We take away process people, product ops. The same thing is like, what is the downside if we take product manager away? Engineers can code, engineer can also understand customer, right? So the thing is this, right? Then you again, it's the question on two things. How much you want people be specialised on something? Or how much you want everyone to be generalist? When everyone is a generalist, would it be the best way to create the best thing? I don't think so, right? The second part of that is, it is not about efficiency. It's about, are you going to lose a market share and eventually your company going to die if you don't have a good product to market fast. So you see, good product, important. To market, important. Fast, too. If you miss any one of them, there's going to be a massive problem. You may not see it this quarter. You may not see it next quarter. But soon enough, you will be gone. Why do companies just go away faster and faster than ever? Because they forgot about that. They have a product on the market every single day. There are alternatives to customers. How do you understand that and go to market fast? How do you stay ahead? You need to run an efficient organisation. So people nowadays say, oh, I need to be outcome-focused. I need to be customer-centric. And they forgot about efficient. You also have to be efficient. You have brilliant ideas. It's not to the market, to the hand of a customer it doesn't really matter.

  - Yes, for example, I've often said, when you join a new organisation, deliver first. It's a great way to build trust. And two, there's already a plan in place and you're going to take some time to figure out what's behind it, but you've got to place some trust in the existing organisation, having done the discovery, having done the right work to know which direction to go. And you then learn as you're going. But make sure you don't get in the way of that delivery engine because otherwise you're not taking value to market. It's unpopular for product people to talk about delivery there sometimes.

  - Oh, sheesh. Like, it's actually very different I think, depending on where you are. There are idealistic people who think about product management need to deliver, but realistically, if you don't ship, you're never going to get promoted. You're never going to be recognised. You can talk all the talk. People say, what have you done in the last six months? If you have nothing to show, so then why are you here? And that's really something I also want to talk to product ops people. I think, you know, we see more people have a new role in product ops. The company started having a product ops role and a function. And, you know, and then I think I'll quite often talk to them and say, hey, your product ops, what do you do? They say, I want to standardise this process. I want to do this. I say, you know, organisation have a role. You know, have a function like you are very expensive. I think about it. It's not cheap to have a bunch of people and you have to prove your impact and value to the organisation. If you want to change the process, it's going to take easily six months or longer. And if you take less than that, that means you do a bad job. You can't just come in here to chop things up, want to make things. You have to understand how organisations work. What is the problem to fix this? You're not going to be tabled as the process people. You just roll out the process for nothing. You do have to understand the current process product, where it's working, how things are going, right? Then you cannot think about from the angles like, I don't like it. It's a PM. I don't like it. It's this. That's not a customer feedback. You want to say how the current process is affecting your organization's ability to deliver value to market fast. You always have to farm that lens, right? I always say product ops is the first person should always think about the money. Meaning how much you would deliver value to the market and organisation How much I save the cost to the organisation because we reduce the wasted and dependencies and all that stuff. If it's not these two things, then to drive your action, you have to rethink about this. I know people don't want to talk about money as much, but the reality is like Mark Benioff said, right? Money is oxygen.

  - To me, product is all about business, and business is all about money. And if we forget that driver, because reality... Mark Benioff calls it oxygen, I call it fuel. It's like, it's the thing that pays our salaries, that keeps the business there. And we can have this wonderful idealistic view. But if we run out of money, we won't be here to deliver that idealistic view. So it's a waste of time.

  - Yeah, there are very few companies today on the market don't need to care about money right away, right? Because they need to take care of the market share, but they also have a tremendous funding of billions to drive market share. You can work on ID, you can work on the stuff, you can explore, but the competitive pressure there is this, can you bring the product to market fast so that you're ahead of a competition? Again, bring the product to market fast. It's in some form related to the money. So delivery, that delivery thing, it's very, very important for product ops people.

  - There's a working hypothesis there that getting to market fast is about capturing, which will ultimately make more money. So you don't have to make it in the short term, but you got to make-

  - You're not losing to others that's the opportunity cost, right? The market's this much you have this many people, so if your competitor take more that means there's less left for you. And today's market is competitive for every business, right? So how do you make sure you get there fast?

  - So I can see we're coming towards the top of the hour Becky. so I always like to ask a couple of questions towards the end. If you had to distil your philosophy on product ops into one or two sentences, what would it be?

  - I would say the only reason product ops exist is to accelerate and maximise the collective outcome and impact of product organisation.

  - And is there anything I should have asked you about product operations that I haven't?

  - We didn't talk as much. We talk about strategy. We talk about process. We covered delivery a little bit. We didn't talk as much the portfolio, and I still want to highlight that a little bit. Product ops is... When it comes to strategy, when it comes to delivery, it really needs to take a lens of the portfolio. It's very different. Product managers think about their customer, their product, because that's their focus. Product ops, the same thing as product executives, have to say across the board where I may be over-invest, where I may under-invest, where I may pull resources from one to the other. And if you're in the product ops role, you're not in that conversation or driving that conversation. You try to work in your product area. That is a big problem because, you know, taking my finance background. Product ops job, same thing as product executives, is to maximise the impact of product organisation as a whole, right? To the market, to the customer, to the business. If that's the case, the number one impactful thing is portfolio allocation. Portfolio allocation is way more important than individual stock selection. You know that, right? So that's what product ops really need to take is a strategic portfolio view in strategy, resource allocation, product delivery, all of that, so that you can really maximise, if your charter is maximised the organization's collective output and impact, strategic output, not just work related, that is really around the portfolio mindset all the time.

  - So Becky, I'm sure that segues perfectly into, here's your chance to give your pitch for DragonBoat, and how you guys can help and how people can get in touch. Yeah, great. Well, get in touch, find me dragonboat.io or find me on LinkedIn, Becky Flint. But what is DragonBoat? So DragonBoat is a platform, more of a platform, a data orchestration. So we call it a portfolio intelligence platform. Where we're having data for users to use using our product and also data from externally, regardless of analytics or BI or work management or cost to others, so that you can make orchestrated holistic decision at all levels. So think about DragonBoat is where you run your product organisation. There's a product manager, there's the stakeholders, there's engineering and delivery systems. You want to plug them in when you're ready so that you have a place, have a shared context, have a strategic intent, be able to see and evaluate different scenarios and see the outcome of that. And more importantly, identify risk to your portfolio, risk in the strategy, risk in delivery, so that you can have a timely resolution. So think about DragonBoat is your, not just product ops, it's for the entire product organisation to see, understand, adjust, and act on things that impact your strategy outcome holistically.

  - It's been wonderful having you on the show again, Becky. I'm glad I got to interview you this time instead of Justin as well to have this conversation. Thanks for being here.

  - Thank you for having me.