Jason Knight 0:00 Hello, and welcome to the show. I'm your host, Jason Knight. And on each episode of this podcast, I'll be having inspiring conversations with passionate product people. Now I'm 100% sure that given tonight's guest, this is going to be a popular episode and rightly so. But let's not be ships that pass in the night. I've got interviews with all your favourite product leaders as well as up and coming stars and people you might not have heard of yet, but absolutely should have. After you listen to this episode, why not pop over to OneKnightInProduct.com, check out some of my other episodes, sign up to the mailing list, subscribe on your favourite podcast app, and make sure you tell all your friends where to find me. On tonight's episode, we visit the scariest place in product management, the dreaded build trap, talk about what the build trap is and why so many people seem to have been caught inside it but you think about some of the ways you might escape the build trap including getting a strong CPO to give executive presence in a truly product led organisation and why, despite the views of some, you might actually need to start thinking about product operations. For all this and much more, please join us on One Knight in Product. So my guest tonight is Melissa Perri. Melissa is a... deep breath... product management leader, educator, board member, author, speaker podcast host and DIY enthusiast, currently rebuilding her home office with her bare hands. When she was younger, Melissa worked selling knockoff handbags at a flea market before embarking on a career in product management and trying to help product managers around the world flee the dreaded feature factory with 2018 Escaping the Build Trap. These days she's in the process of evangelising the value of product operations to help product teams scale, make sure product leaders get a seat at the executive table and, if we ask her nicely, I'm sure she could knock us up a table while she's at it. Hi, Melissa, how are you tonight? Melissa Perri 1:42 I'm good. How are you doing? Jason Knight 1:43 I'm doing wonderfully. I'm really, really impressed with the quality of the work behind you as well. Melissa Perri 1:49 Thanks... hopefiully I can finish it and the next time you see it, it'll all be done. Jason Knight 1:54 Fingers crossed. Right. So there's a lot to talk about. But first off, you are currently a senior lecturer at Harvard Business School, board member at Forsta, founder and lead instructor at CPO accelerator and Product Institute founder and CEO of Produx Labs. You've got podcast, you're writing a new book. All of this sounds about like three Melissa Perri's worth of work. How do you find the time? Melissa Perri 2:14 Oh, man. I don't know. I always like over max myself, I find but one of the big things that I did in the end of 2020 was I stepped back a lot from consulting. So I do.. no longer go in consulting heavy handedly with companies... always happy to chat with people like one off, I still do talks. But that was taking up like 80 hours a week on its own. And then I did all the rest of it. So I had this moment where I was like, Yeah, I would like to have a normal life to have friends and like see people so I stepped back from that. And everything else kind of complements each other pretty well. So it's it's a lot of work. But it's been really fun. Jason Knight 2:58 And would you consider any of those like your main gig the thing that you spend the most time on? Or is it literally a case that you just divide up your weeks into all those different buckets, and then just do all of those to the max within those buckets. Melissa Perri 3:10 Harvard is definitely where I spent most of my time over this last year. So I was rewriting a class teaching a class I taught both semesters, still rewriting this class, I have to do a bunch of cases. So spending most of my time there. And then in addition to that CPO accelerator takes up time, but it's seasonal, because we have a couple classes a year. Jason Knight 3:29 Oh, so you have your your cohorts and then you're done. What are you teaching specifically at Harvard? Are you teaching product or you teach in business in general, like what's the focus of what you're teaching there? Melissa Perri 3:41 Only product management... that's really what I specialise in. So I teach second year MBA students, they go through a first year whole curriculum thing that's very defined very much been tested over the last 20 years, 50 years, whatever. And then in their second year, they get to choose their classes. So my students are usually this year is mostly people who wanted to be product managers or working a product adjacent role. In previous years, we've had a lot of startup founders, I had a couple of them this year, but actually over like 50% of the MBA students who go to Harvard want to start their own companies. So trying to help them understand what product is about. Jason Knight 4:15 Well, we need more CEOs who know what product's about... but Escaping the Build Trap came out in 2018. I said to someone recently, I've never nodded quite as much as when I read it and also kind of got the Apocalypse Now helicopter noises in the back of my head as I got the PTSD as I remembered all of the things that I'd experienced on that book, and I brought it all back to me. Now, it's obviously a great foundational book and one that lots of people recommend in and around the product community. But for the handful of managers who haven't read it yet and in your own words, what is the Build Trap? Melissa Perri 4:46 Yeah, the Build Trap is a scary place that I would say most companies... is a scary place, let's put it that way. But most companies get into this area that I call the build trap, where it's like we we focus more on shipping things as fast as possible, usually, you know, software features, but guess you could build trap yourself into other things as well. I talk about in a software context, but we're shipping... shipping features. And we're not really taking the time to step back and say, hey, is this the right feature to ship? Was this going to do what success look like? Do we actually want to do this or not? And I have personally been in the build trap a lot. That's how I got started talking about this, if anybody has seen my talks, I talk a lot about how I realised I was stuck in the build trap. But then I've seen every size company kind of get there. And you know what startups don't stay there for long because they fail. But large companies can stay there for a very, very large amount of time, because they just got the money to burn. Jason Knight 5:46 Yeah, I guess there's these two angles, like I can completely understand when you've got a very traditional old company just sort of sitting there. Maybe it's trying to come a digital transformation from the other end light from the big end, where it's already kind of requires an entirely working of its entire operating model to actually get there. But I guess the concept of small companies going into that build trap mentality, it kind of feels a bit like that shouldn't happen, because of course, people are starting small, they don't have a lot of process, you'd imagine that they would be trying to do things, quote unquote, properly. But if you had to estimate, kind of like an a thang interview style estimation question, if you had to estimate the percentage of companies out there that you believe are stuck in the build trap of whatever size, like how many companies do you think are actually inside the build trap? I guess the other way around? How many aren't in the build trap, what percentage of people have managed to escape? Melissa Perri 6:39 So, good question. I don't know, actually what percentage it would be. I feel like too, depending on the company, you could have certain teams stuck in the bill trap, and you're gonna have other teams not. And it just really depends on like, the maturity of product management and how you're actually going after it. When I look at small companies, like you said, hopefully they're doing it well. Not all the time. Like I have seen a tonne of companies are just like, I don't know what I'm doing. I know what I'm building and they build it. Thing is, you never hear about them, because they don't make it very far. So I work with, I've worked with tonnes of startups that you know, advised or coached founders who, you know, just didn't want to hear it. They thought they wanted to hear about product management, how to test things, but they just really wanted to build their own crap and just ship it and didn't care. So tonnes of people out there like that. Now, I think when you find product market fit, like after you find that at least with one product, that's tends to be where the, I call it growth stage companies, startups that have gotten past that, like, first stage, right? Right after they find product market fit on one of their products, that's a dangerous area where a lot of them can fall into the build trap, because they're basically like, okay, cool, we have a bunch of customers, we have a product that's got really good traction. But now we have a bunch of customers, you're yelling at us to build more. So that's where you get these laundry list of feature ideas. And everybody's like, please build me this. And then it becomes really hard to navigate. Like, how do I not become a custom dev shop? How do I make sure that we're actually like, having a strategy for growth, figuring out what our next product should be expanding correctly, instead of like, just responding to things. And it's really easy to respond to stuff. And I think those companies get nervous because they're like, oh, we have customers that we have to satisfy now, which is true. But they can get really easily trapped in this mode of just like, Oh, you want that you want this? Okay, we'll build it for you slot on the roadmap. And I also find that's exactly when the product teams start to scale. Yeah, so now it's not like you have one person controlling the prioritisation of what's coming in, you've got a whole team 10/15 people sometimes as you keep getting bigger, who are making these decisions? And if you don't have a really good framework for, you know, setting your strategy, figuring out what makes it what doesn't make it, what will get punted until later, you know, what, what should we do now, that's where it can get really easy to get into the build trap. And that's where I usually see a lot of the smaller companies stuck there. So you may see these companies out there raising, you know, just watch. People are raising ridiculous amounts of money these days. But like, you know, you're like, wow, that company just raised $100 million. It doesn't mean that they're not in the build trap. They could very well be. It's just so you won't actually find out until you're in there. And on the outside, everything could look really really rosy. But on the inside, you know, it might not be but when you have a company that solves a problem really well for people, you can ride that for a really long time. And I think that's what larger companies and some of these companies kind of bank on is like riding that wave. But the problem is like when that wave stops, and when it fizzles out, it's too late usually to course correct. And that's usually in some of the like medium sized enterprise or smaller companies. That's kind of where I was brought in to do some transformations and stuff. It's like the wave fizzled out. Been fizzled for a very long time. And now it was like, hey, let's do a whole product organisation transformation. And like by that time, it's you have to, like overcome so much to get back in it. It's really hard. Jason Knight 10:12 Yeah. And I think that some companies, you've kind of touched on it yourself a little bit as well, you get some companies, maybe they've got two or three really big clients are paying a big chunk of money. And they can kind of sustain any size a company for quite some time, if the amount of money that I'm going to spend on this stuff is effectively a rounding error in their accounts. So yeah, kind of makes people look like they've got product market fit, or look like the sustainable person is one of those companies goes, you know, the company has a product that no one else wants necessarily. That's where it gets into a situation that you describe. But in the acknowledgments for escaping the bill chap, you said, to paraphrase, writing the book was the most difficult undertaking of your career to that point. Now, obviously, lots of people that I've spoken to that have written books have all said that writing books is really hard. Sometimes I think about it not started yet, who knows what'll happen there, but you decided them that you're going to write another one anyway. And this one's gonna be about product ops. Now I know you're writing it with a friend this time, although some people might consider that a little bit stressful as well. But why did you decide to start putting pen to paper again, figuratively speaking? Melissa Perri 11:14 Well, first of all, I would like to acknowledge has been like four and a half years since I actually finished the last book. So the trauma has died down a little bit. So that, you know, you get itchy to me. The brain heals itself. So it also because Denise and I were talking about it. And Denise approached me and said, "Do you want to write this book with me?" And I said, "Yeah, let's do it." And I also thought it was a great way to take all the lessons learned from what not to do for my first book. And try again, but it's been really nice to write it with Denise and completely a different experience than the first one because that was kind of like on my own. And we get to, you know, pass things back and forth. And we have different types of strengths when it comes to editing, and writing periods. So like, we get to play off each other's strengths, we get to like really collaborate on it. And it's been really nice to have a partner in this journey again, because doing it your first time on your own. It's just, it's hard. You got to figure everything out along the way. Jason Knight 12:16 Yeah, although, as you were talking about your different styles and strengths and weaknesses, I was then starting to wonder like, how can you make sure with two of you that you're writing a book that has a consistent voice like that the phraseology is the same? And the kind of attitude behind it is the same? Because if you're two different people with two different backgrounds? I mean, how do you sort that out? Melissa Perri 12:37 Yeah. So Denise, and I work together at products lab, she was our VP of product for two years. And then when I stopped consulting, she went freelance, but we still work together a lot. So she does if you reach out to me for consulting, I'm usually recommending Denise, right. So she's consulting on her own. But while we were working together our products labs, like she ran our product operations. And it was based on my philosophy of product operations. And then we refined it together. And we were like, cool, this is how we're going to do it. So we spent, you know, two years teaching the same stuff, implementing the same stuff, seeing the same companies over and over again, Jason Knight 13:14 Two hands in the same in the same gloves. That's a horrible metaphor. Melissa Perri 13:21 And before, before that, she was doing it in different ways in The New York Times, and the other places that she worked. So she brought the flavour in of here's what I've done before. And this is how I've set that up. And then I brought in stuff from when I was implementing it in my consulting before she joined. So, you know, we got to collaborate it. But while we were at product labs together, like, it kind of found its rhythm, and we were like, we see this work. And we've implemented that a bunch of times. And so we have very, we have the same philosophy when it comes down to it. Jason Knight 13:51 Oh, fair enough, that should make it a little bit easier. But you do mention product operations in Escaping the Build Trap. But it's fair to say that it's basically in passing, it's like a couple of pages in the organisation section towards the end of the book. But you obviously in that book talked a little bit about product operations and the benefits of it and how you've worked with it before. But why was it then you decided, in general, to double down on product operations since that book, because it wasn't a big focus then. And it seems to become a much bigger focus now? Melissa Perri 14:20 I think I was just grokking what product operations was when I finished writing the bill trap, and that's probably why it looks like a little blip at the end, because I had been implementing it at Athenahealth when I was writing the book. So we were rolling that out across the organisation and like getting a VP of Product operations set up in their training the teams figuring out what works and a lot of my experimentation there was happening there. So when I finished writing the book was when my tenure at Athenahealth ended. So I kind of was like, oh, yeah, this is essential, like we need it. And I have this philosophy on how it's done, but I haven't fully fleshed it out yet. And I think That's a hard part about teaching and writing a book, it's hard part for me, it's like, you may be able to go in somewhere and do something like I could go. Like when I was playing interim CPO roles through products, labs and stuff like that, like, I could go into an organisation just be like, blah, blah, blah, do this, right. But then you have to do it a bunch of times, reflect on it, refine it, and then teach it to others before you can really write about it. And that was kind of where the product ops ended, or started, I guess, for me was at the end of escaping the build trap, where I'd been implementing, I was putting it into practice, but I had to wait to see how it works. And that is honestly why it gave me the build track took so long for me to write two to three years, because I'd write something and then I put it into practice. And then I was like, Nope, that didn't work. And then I go back and fix it, and reflect on what it worked. And I think that's how it how it goes. So this time around is nice, too. Because Denise and I have done this, like, I don't know, like 1520 times in different organisations putting this through. So we're like, cool, we know what works, we know what doesn't work. And we also have like 40 interviews with product operations leaders from all these different companies that you know, will put as case studies in the book too. Jason Knight 16:09 Sounds good. And it's really interesting to see your thought process evolving, as you kind of move past that initial discovering part into actually implementing and then ending of a book and hopefully then a Netflix series or something like that as well. I've spoken to a couple of products, people on this podcast before. So I've spoken to Christine from Pendo spoken to Brian from clickup, both obviously companies that are going through very high growth stages and unicorn growth and all of that good stuff. But they both had slightly different takes on what product ops is and there's obviously lots of other competing takes going on around the internet, some of which we might talk about in a minute. But imagine that you're a party full of non product people and someone pops up to you and they introduce you start chatting and they like, what you're doing is hey, well I'm write a book about pilot operations. And they say, Well, what's pilot operations? How would you describe that to someone who didn't know anything about any of this stuff? Melissa Perri 17:02 Yeah, I'd say product operations is the discipline that enables strategic decision making inside companies. So a lot of people implement pieces of what I would call a full product operations framework. And I see that all over the place, there's people who spike on certain things, depending on what the organisation needs. But at the end of the day, if you were to like, sum all that up into a why I think everybody says the same stuff. It's like it helps us make decisions better. And some of the stuff might be like a reaction to something bad happening in the organisation. Like I asked one person about it, and they were like, oh, because we realise like, none of the feedback from sales was getting to product. So you're like, cool. Why was that a problem? Oh, because we couldn't actually incorporate that into our product. Okay. Why is that a problem? Okay, because our customers were mad, and we weren't prioritising, really, okay, cool, goes all the way back to strategic decision making, like at the end of the day, so that's what it really comes down to, I believe. Now, the model that Denise and I talked about, we really see like three different pillars for it. One is being able to like monitor your strategy, and make informed strategic decisions. So it's like, what are we working on? What's our progress towards our strategy? What are our goals? How does all the stuff on the team letter up into like portfolio and capacity planning and all that wonderful stuff? So it's really about like making sure that we're building the right stuff, right? When we're making progress towards it, then there is getting internal insights surfaced up to make that strategic decision. So it's like, how do I know what the revenue per product is? We got a multi product portfolio, what's my revenue per product? What's my cost per product? Does the revenue per cost per product make sense? What's my price per product? If I have like a different subset on there? How many people are allocated to each one of these products? Right? What does that look like across initiative? How do I slice and dice, we have so much information in all of our systems that we use in companies, you know, our accounting systems, our JIRA management systems, our HR systems, like everything across the board, even, you know, just not even just the product analytics space, where we're tracking usage and all that stuff. But those things aren't interesting until you actually combine them together and start to figure out what's the impact to the business. So that's what the insights piece is really about data and insights. It's like, how do I get the numbers out of all of our systems so we can start to look at them in interesting ways and make sure we're making progress towards our business goals. And then the last piece is really getting no sorry, that was the that's the internal data. But then there's also external data. So we look at market like market research, competitor analysis, all that stuff. So how do we streamline user research? Not how do we do user research, but like, how do we make sure that we can find people to get in touch with this was a huge issue that we actually had at Athenahealth. And people were going to the same hospital over and over and over again to talk to them because it was easy to get in touch with them. Of course that wears out after a while where people were like stop bothering me. And you don't want to, you also don't want to, like, build everything based off of one company. So there was a team that built a whole database of all the customers and ask them what types of research they wanted to opt into how often they wanted to be contacted, we kept notes on the contacts, we shared all of the user research in a database, so people could search it and see if people you know, we have 350 product managers. So like, you could be researching the same thing at the end of the day. So we had to build all those systems to really be able to enable user research. So not do the user research, but enable people to do their own user research. So there's all that kind of external data, things that don't live within your company, but you have to streamline to get it. And then the last pillar is really like processes tools, and really making sure that we standardise the things that need to be standardised. So for instance, if every single person in your company makes a different roadmap, you as a product leader have no idea what's going on. And this happens every day. This is one of the most common things I see across the board. One person's got an Excel file that doesn't look like the other person's a hover map who doesn't look like the Trello roadmap over here, like it's really hard to manage a portfolio have multiple different roadmaps for different products and features if you can't standardise them. So a lot of people criticise that piece because they go and that's where I think some of the definitions get really hung up on product operations. They go, Oh, it's just all processes and really looking at the tools we use and standardising roadmaps, and it's like, no, but honestly, a lot of people start there. Because what I always say when I go into these companies in you know, when we actually put product operations on the map and start to implement it, you have to start somewhere. It's really hard to do all those things at once. And the question is, where is the biggest issue? Right, like, where are we leaky bucketing? Everything. So in group stage companies, usually we start with the data and insights piece, we start by doing like what we call manual baseline. And I did this in tonnes of companies when working with insight. We go in, we pull all the data out of the systems, we try to figure out what data exists, what data doesn't exist, what do we have to start tracking, and then we start putting it together to help reflect what's the current state of our strategy. So a lot of those end up in board slides, like when the chief product officer is presenting something like, that's what data and insights is for is to help you tell the story, but they also help them set the strategy. You cannot set a product strategy without the information like it is actually impossible. I know everybody out there will be trying to do it. But like you can't set a good one. Jason Knight 22:36 Like don't have product str ategies Melissa, that's the problem. Melissa Perri 22:38 No, it's not product strategy is is just basically like a stick your finger in the air and see what which way it goes. But that's like, where a lot of times we would start with growth stage companies because the act of growth stage companies like you have to be able to make strategic decisions about your strategy. Constantly, like every quarter everything something is changing. It's it's characterised by tonnes and tonnes of movement. But some of the larger enterprises start with the processes and tools. Because their biggest hurdle is I have no frickin clue what anybody is doing right now. Right? So like, it'd be great to be able to see what's on the roadmap, and I've got 80 roadmaps I'm looking at. And I have no idea how to make sense of them. So they'll turn to those types of things. First, and that's not necessarily bad. It's just meeting people where they are and based on the type of company you're at, you know, it may vary. Jason Knight 23:27 But some agile fundamentalists might sit there and say, Melissa, everyone should just be able to do what they want. These teams are self organising, we don't need to impose any rules, regulations, or tools or methods on them. They, they can all organise themselves. Do you think that's a slightly naive view as companies start to scale? Melissa Perri 23:46 Yeah. It's a hugely naive view, actually, a very long time ago, I worked with Spotify briefly as a consultant, and they were addressing exactly that issue. They had allowed every single team to work independently use their own systems, use your own deployment systems. And I was brought in to do research to figure out, hey, do we actually need to standardise our deployment system because people couldn't ship stuff like they couldn't merge it together. And it was all affecting the same product that you see every day. So like, yeah, that's a big problem. And I think it's a problem for companies that have growing pains now, should you the not growing pains, but that are growing like you got 1000 product teams all using different roadmaps? No. So the way that I think about like, how to separate yeah, there's some stuff, they self organising teams, right? Like, you should be able to self organise around things that don't matter to other teams. Like you want to keep all your tickets in Trello and JIRA, and you have a way to roll it up into over a mapping system and you can actually track them and do all this stuff. Sure. That's usually not the case. Usually, people are looking at a portfolio view in JIRA, but hey, let's take something else like you don't want to do stand up meetings every single day. You want to do it every other day. Sure, whatever. Right like you want to use Slack instead of I was gonna say ICQ but that was a long time ago. Jason Knight 25:01 If anyone's using ICQ I'll be very, very impressed. Melissa Perri 25:04 I used to use that Jason Knight 25:06 I bet you still remember the number as well. Melissa Perri 25:09 No, I don't actually, which is good. I wouldn't, I would have wasted space in my brain. But yeah, I mean, like, if it doesn't affect other teams, do whatever the hell you want, right? But if it does affect other teams, and it's preventing you from making decisions that need to be made, or, you know, preventing leaders from doing their jobs, like, yeah, you're gonna have to standardise some of that stuff. And that's just how companies scale you can't scale without that. So, you know, I don't think you need to standardise everything. I don't think everybody needs to be on a two week scrum cadence or a one week scrum cadence or anything like that, like, whatever works for you. But if it's roadmaps, for instance, like, they inform strategy, they inform budgets, they inform financial outcomes, a lot of these Chief Product Officers are going to their boards and saying, Hey, we chose to, you know, enter this new market over here, because there's a $400 million TAM opportunity. And here's our roadmap of how we want to actually approach that TAM. And this is the information that we have in the validation all that stuff. Like, you can't do that if you don't know what teams are working on, right? You can't plan for that. You can't see if you have capacity for that you can't weigh those decisions against what else you could possibly be doing if you don't know what's going on. So that's why I love product operations. I've walked into so many organisations that didn't have anything like that. And my remit was go figure out the strategy or go fix it, or what should we do? And I'm like, I don't even know where to start, because you have no information for me. So the first thing you start with is gather the information. And that takes so long when you're a consultant. Also, if you're one person, it takes a long time to we had some phenomenal analysts at products labs who would do this, but like you are, if you don't have product operations, implemented in your organisation, or you're not thinking about it, like, I think you're doing yourself a disservice because it allows you to move at the speed of the markets that you want, that allows you to make these decisions that allows you to make sure that you are building the right thing in escaping the build trap. So that's why I'm pretty passionate about it, walking in blind to places with like, no data, nothing there, right, you know, have to go get it. And that takes time. And everybody wants a roadmap. Everybody wants a strategy and like a day a week, right among all the CEOs are like, what are we going to do? You can't decide what to do if you don't have any information. Jason Knight 27:34 But it's fair to say there has been some pushback about the concept of product cops with certain high profile thought leader coming out against process people and painting at least some types of product ops as the revenge of the PMO. Now, I know you disagree, and you disagree loudly at the time. But do you think there's anything to some people's concern that some companies are just rushing to layer old fashioned thinking and processes and project management processes on top of perfectly well functioning product teams? But have you seen that as a kind of the dark side of product that was becoming more of a trend and more of a thing that people think about? Melissa Perri 28:12 Oh, I'm sure like, I mean, hey, how many people read my book or somebody else's book and they go, Hey, we're doing you know, we're doing the build trap model, or like, I know, Teresa with her book, we're doing continuous discovery, and you get in there. And it's like, no, you're not like, you're doing it wrong, right. I'm sure there's people out there doing product operations wrong. But that doesn't mean that it's bad. Right? It was the same type of stuff we got into I mean, it's the same more we got into with Agile, you know, agile is bad. No Agile is not bad people who are abusing Scrum and I don't personally love Scrum, but like mania, but if it's fine if you don't abuse it, and it works for some people, but some of these crazy things that people were doing with agile, it's the same thing. Like that's never what it was intended for. And I think you could totally say that with product ops. But he also works with very large enterprises. And where do they start, like I just said, they need roadmaps, they need standardisation, they've got 5000 product managers in one business line, not even across the entire enterprise. You try to synthesise what 5000 people are doing, you need some kind of standardisation in the tools. And that takes a long time at these enterprises. Now, hopefully, that's where not where they end. But that's a lot of where they begin. And if as long as they know, that's not where they should end. I don't see a problem with it. Now. What's next? Do they keep going? I don't know they might abuse it. But I think there's a lot of people out there doing product operations, right. I've met a tonne of them. And that's why I'm like, I don't think we should demonise the whole thing. Yeah, it's not the discipline. It's how people interpret it. And it's like that for everything DevOps, agile, like we get into these wars about all of this stuff. Right. And I think product operations apparently is just the next one. Jason Knight 29:58 Everyone needs to be able to kick something right? But the said thought leader's written a few follow ups then, since then on that original article where he's tempered the message, actually even bigged up your version of product ops. I know that we even talked in passing about maybe trying to get debate going and, you know, seeing if we could set it once and for all, but we couldn't really arrange anything. But given the follow up articles and some of the clarifications and deeper thinking and of course that shout out to you, in some of those articles, do you think that you're kind of on the same page now? Or do you think there's anything that you still need to clarify? Melissa Perri 30:31 Oh, I have no idea. I don't know if we're in the same page, I think so after reading that last article, it seems like we agree on what good looks like I don't know if he really loves the concept of product ops or not, I think, I think he comes from a world and I could see this too. You know, I see the other side of this as well. You know, back in the day, when there was, I guess, less product managers. The thing is product managers. This is his argument, like product managers do a lot of this work themselves, they get the data, the systems, they do all this stuff. Yeah. That's how it used to work. Does it have to work like that forever? No, right? Because that's not I'm not actually hiring a product manager to go dig through a SQL database to pull out the transactions that just happened. So they could build their own funnel? Like there's software out there to do that these days. What if we connected that software and made it more powerful, so the person has to open a report and just look at it and go, okay, cool, I can make a decision. Now, instead of wasting 40 hours during the week, like I used to digging through MongoDB, I literally had to teach myself MongoDB when I worked at open sky, to get the friggin data out of the system. And I literally took a whole class for like 15 weeks to learn MongoDB because I couldn't get the data I needed, like, why do we have to let that happen to product managers anymore? That's my question. So like, did that used to be part of their job? Sure. Like I've done it, I'm sure everybody listening to this has had to do that type of stuff. Had to do their own user research, recruiting, how to go sift through everybody with sales. But, you know, I thought like, we were all in the business of optimising and improving things. Why can't we improve? The way we work? Why can't we make it easier for people to do their jobs? Jason Knight 32:08 Makes a lot of sense. And I've certainly got my own memories of having to learn MongoDB to look at stuff. Melissa Perri 32:14 Everybody had to it was funny, a lot of the people who worked at Open Sky left to go to MongoDB. And that's how we ended up with that database. But then we had all the inside scoop on everything. Jason Knight 32:25 Right, so that's fair enough. And I think we've obviously put that one to bed. And, you know, that's the final word on that subject. But talking to scaling, you saying escaping the build trap, that strong C suite representation is essential for truly product lead companies. So that's basically talking about having a CPO will be that leader for the product organisation. And that's something I totally agree with, I think it's really important to how can you really always have a product company if you don't have that exact level sponsorship of the product organisation? But I think it's also fair to say that not all companies do that. I'm not even sure if the majority of companies do that I probably say absolutely not. Like at best, you might have like a VP of product going through the CTO or maybe you even have like a CP to kind of combined tech and product into one role or a CTO is really a CTO or maybe even worse than industry expert with no product experience at all. What do you think it's such a struggle still to get good product leaders to the top table? Melissa Perri 33:20 Ooh, good question. So I will say the CPO role is one of the most in demand roles right now. I work with a lot of executive recruiters more just to like pass them good names and stuff like that. I don't have like a tonne of people off the top of my head. But I'm always happy if you're listening to this. And you're like, Oh, listen can help me with search. I'm not going to help you help you. But I'm happy, like, share it. Share your job descriptions with CEOs that I know like I've got a group. I will say like the reason why I think a lot of companies didn't have this role before is because they lumped product and technology together. And they didn't really think about the business side of product, right? They just saw it as like, oh, fix the features. And now they're realising that product strategy is really what enables growth, especially in SaaS businesses. Now, I feel like SaaS businesses probably caught on to this a little bit more than your enterprise businesses or your like software enabled banks and stuff. But SaaS businesses, the CPO role is extremely critical, especially at a growth stage. Because the whole growth stage the scale up phase, it's really characterised by like adding rapid business value through the development of software. And if it's not connected, and if it's not right, you're not going to scale the way that you want to. So that's where that role becomes absolutely critical. And where you start seeing Chief Product Officers enter at the size of the company. Usually we try to hire Chief Product Officers in around 30 to 40 million in ARR. But that's not a hard and fast rule but like big enough where there's a team to manage and there's like some meaty opportunity there. Also another shift that you see CPS come in and when they move from single product to multi product or you're going to go geographically or something. Before that. It's usually a VP of product had a product sometimes the founder So, now, enterprises are still catching on, I feel like so they usually have like a CIO on top. And I don't love the CIO.. Jason Knight 35:07 Chief Digital Officer even. Melissa Perri 35:08 Yeah, Chief Digital Officer, something like that CTO sometimes. And then they have VP of product and each business line, but I'm like, who's like thinking of product strategy across the way, like, Who's, who's looking at this part of the bank and going, Wow, we actually need the same set of tools on that part of the bank, because we develop the same damn things. Like, that type of mentality, I feel like doesn't carry through across the enterprise level and some of the bigger companies I found, but it should, I mean, a lot of really large companies that are software based on like Google and stuff like that they have Chief Product officers, why? Why don't we have that in some of these other companies are not digital native. So there's all of that in there. Why don't we have a lot of CEOs, that's part of it. The second part of it, I find is that a lot of us who entered the world, and this is also where you get bad CPOs, too. So like, a weird, weird thing to a lot of us who entered the role of a product manager started working with teams. So like, we work with our developers, we break down stuff, when you become a chief product officer, your role is all strategic, it's not tactical like that, if you don't get the opportunity to actually try strategic things in your role, it's really hard to learn how to do that. So a lot of people get trapped at the lower levels of the organisation because they don't actually understand what goes into defining strategy and building good business strategies. And they don't understand the business side of things either. So that's essential for CPO. And that's where you run into issues where you see a lot of people come in as a subject matter expert, who may have been an executive for years, and they really understand the business and they understand the financials, and they understand how it all works. They don't understand product management, but because they know how to be an executive, yeah, the company is more likely to bring them in or move them over from another position, say, Oh, you can handle products easy, go do it. Jason Knight 36:59 But if you do get that subject matter expert in like, is it just as simple as them getting a really strong VP to kind of do the product management stuff? And then they can just go away and all that strategic stuff? Or do you think that that's kind of a recipe for trouble in and of itself? Melissa Perri 37:15 I've seen that work well, if you're willing to listen to the VP of product, like one of the designs that we would do in some organisations is have a really strong CPO on top and see sometimes it's even a hybrid CPO/CTO, and depending on where they weren't super strong, actually, it didn't even matter if it was super strong enough, they would hire a VP of product, a VP of technology and a VP of design underneath them. So you'd have the functional leads, who took more of the people management part, but you could still do the strategy part and you know, operating and combining all the roadmaps, you know, in that way. Now, the hard part is, if you're a subject matter expert that doesn't understand product, like you have to actually understand how software products are built. Yeah, what the different formulas are for them. For me, it's like all patterns like I look at, and this is the thing that I run into. And one day I'll maybe write something about this, but it's like product patterns, right? Like now. And this took me a really long time to understand. And I couldn't go I kept going like, oh, subject matter experts aren't great at product management, because they just don't understand the process. I don't think they actually understand what a product is. They don't understand like what software products are. And because they're so good at their domain, they are not open to actually looking at other domains or other areas to learn from it and figure out how could you use it. So perfect example, I was working with such one subject matter expert, CPO in this company and CEO, and everybody and nobody had like a good product background, both of what they were doing. And I was like you are a data company. Like you're basically a data company that needs a set of workflows on top of here for people to do their jobs. Yes, you need some reporting. And you need a database on the backend to basically control that. You probably want to think about API integration swell. And they were like, no, no, no, that's not who we are. And I'm like, That's exactly who you are. Because, but like they couldn't see it because they were like, no, no, no, no. Our domain is what the data was actually being served for. Right? Like, it wasn't healthcare, I'll use as an example. Like, if you were doing health care data all day, you were like, No, we're not. We're a health care company. And like, you're not a health care company, you're actually a data company, right? Like, and you have to understand how all those things manifest. So I'm looking at other companies like, I don't know, even like amplitude, right? Where it's like, you've got all the data stored on the back end of your product usage. And you got the workflows in the top to put the reports on it. Great example you borrow, how that's designed and where that's from, in this other company, even if it's in healthcare, right. It could be in banking, it could be whatever, yeah, but they don't see the patterns like that. And I think that's what separates a great Chief Product Officer. Somebody could see those patterns, understand how software is built, understand the power of software and where there's opportunities for strategic design of software elements to bring more value to be to also understand the market and the business so that you know, like, Yeah, we should go up market, it'll take X,Y and Z to get there, right? Like this is what people need in that market. That's where I see the disconnect come from. So like, Does somebody have to be the best tactical product manager to be a CPO? No, like, but you have to be really strategic. And it's really helpful. If you understand how product is built, I still think you need to have been a product manager or a technology person at some point to be a really effective CTO, or UX designer, anybody who's like been involved in the prioritisation and the modelling in the getting things out to user of software. But did you have to be the best person at being the tactical person? No, as long as you be the strategic person, right, like, yeah, you know, the best, the people who are the best at the tactical stuff may not make the best strategic people. But I do think it's a skill a lot of people can learn. And that's why I started CPR accelerator because I just found that a lot of fantastic product thinking people out there product minded people, you know, product managers, they got that tactical piece to understand roadmaps and they don't understand the business side, and they don't understand what it means to really be an executive. And like one of the biggest mistakes I see new CEOs make is I don't know why. But like, I don't know if this is with other disciplines, just because I haven't really been other disciplines. But like, I feel like product, people look at leaders and stakeholders and go, oh, like scary people. And then when you get to be one, you're like, Oh, I can't talk to the CMO, again, like that is your peer now, you're supposed to be working with a CMO, the CTO, the CEO, like peers, they don't see them as peers, they see them as like scary people. So what do they do? They gravitate into their team? Yeah, they only manage their product managers, they spend all their time there. And they don't do what they need to be doing, which is aligning the entire organisation around what they're going after? Jason Knight 41:51 No, absolutely, I think that kind of level of executive presence, which is a concept that I hate, by the way, because I think it's kind of almost like a microaggression in certain circles, the the whole concept of executive presence, but being able to be present in front of executives. And also being able to speak the language of business. And being able to translate product staff into business staff seems really important, and something that not all product managers can do. But I guess the question there is, then obviously, you're working a lot of these people to try to make them into effective CPO. So what are some of the areas or some of the techniques that you use to try and get these people to be a little bit better that will give them the confidence to try and be a bit better than that? Melissa Perri 42:29 Yeah, we kind of cover a couple different topics in our in our class and CPO accelerator. So we go over, what does it actually mean to be a CPO? Like, what's your job now, so even just orienting them around like hate your job is not to train the product managers, that's like a very small piece of it. And honestly, a lot of times you hire somebody else to do that, like you're not doing it yourself, depending on how big the organisation is. But your job is to basically set the strategy work with the CEO to interpret their vision into a product strategy, align the entire organisation around it. So huge strategic parts of it, implement product operations, get started, hire somebody to help people that out, organise your team, where am I going to put people? How do I capacity plan? What do I do for allocation? How do I start making sure that we're monitoring our strategy and looking at the governance around that? And then we also talk about working with your executives? So it's like, how do I work with my peers? What types of conversations should you be having with the Chief Financial Officer? What types of conversations should you be having with the CEO? How do you work with difficult CEOs in difficult, you know, in quotes, because just really understanding like, what's the most important thing and might not be your most important thing, and you know... Jason Knight 43:35 They're just CEOs, right, they're not difficult, they're just CEOs. Melissa Perri 43:38 You know, some of them are definitely difficult, but like some of them, it's just it, a lot of it's like, how do you put yourself in other people's shoes and think about, like, what matters to them? Or there's a lot of that? And then also, how do you work with your board? So we do a lot of education about like, what does what do boards care about? What are they doing on a day to day basis? What's it like to be a board member? I'm a board member. So like, I bring that in there now? What information do they want to see? How do you put together a really effective board presentation? How do you talk to the board? What should you do to help? A lot of times, they've never had that experience? And it's like, where do I go to get that experience, you're never going to be talking to a board unless you're a CPO. So it's not like you trained for that. So getting them that type of exposure, making sure that they're really comfortable from there. So that's the type of stuff that we really go over. It's like some of the tactical pieces of like, what do you do on a day to day job? But like, also, how do you just work at this level? Like, how do you how do you communicate better? How do you plan strategically? How do you make sure that you're building a good executive team and bringing people together? Jason Knight 44:39 Makes a lot of sense. I'll sign up tomorrow. And when can we expect to see the product operations book out? Melissa Perri 44:46 Oh, man, we're still... we just finished chapter.. Jason Knight 44:49 We need a roadmap and timelines. Melissa Perri 44:50 It's going to be a year. I mean, I'm going to tell you later this year. My goal is to get out by the end of the year. So I think we'll be able to do that we're making pretty good progress. We just were done with three chapters so far, which is pretty good progress. So ... Jason Knight 45:03 Fingers crossed. Melissa Perri 45:04 Yeah. Jason Knight 45:04 And where can people catch up with you after this if they want to speak about product ops or learning how to be a CPO or maybe even see if you still got any of those old handbags hanging about? Melissa Perri 45:14 Yeah, no, I think all those. There's like Gucci handbags with a C instead of G. It's a fun, fun little job when you're 13. But the yet, I used to go to ProduxLabs.com that links out to pretty much all of our trainings and all the things that we've got going on, including our product operations, training and under workshops, Product Institute, CPO accelerator. I am happy to come speak to organisations about this. If you're having some kind of events, please reach out to me either through that I get the products labs.com emails or you go to MelissaPerri.com. And you can follow me on Twitter as well @lissijean is my Twitter handle. And I'm happy to chat on that or listen to the podcast and submit your questions there which is also you can find through ProduxLabs.com. Jason Knight 46:02 So as with all of the things that you're doing up front, there were a multitude of ways to get in touch. I'll make sure to link them all in and hold enough space on the page. That's fantastic chat and obviously really interesting to hear some of your rebuttals to the criticisms of product ops and some of the ways that people could become more effective CEOs. Hopefully we'll stay in touch but yes for now. Thanks for taking the time. Melissa Perri 46:22 Thanks for having me. Jason Knight 46:25 As always, thanks for listening. I hope you found the episode inspiring and insightful. If you did again, I can only encourage you to hop over to OneKnightInProduct.com, check out some of my other fantastic guests, sign up to the mailing list or subscribe on your favourite podcast app. Make sure you share it your friends so you and they can never miss another episode again. I'll be back soon with another inspiring guest. But as for now, thanks and good night.