Everything you’ve ever wanted to know about SAFe and the product owner role | Melissa Perri (author, founder of Product Institute)

0:00 There's this whole concept of safe, basically scaled agile, right? So scaled agile framework came out of the desire to figure out how do we scale Scrum and different processes. I Do not recommend using Safe. Every single person I have talked to who likes Safe, found success with Safe, they ended up ripping it up and making it into something else. You've been up close and personal with a lot of companies working with product owners, scaled agile, and all these things. This product owner role did not emerge from product management as we know it today. It was a way. To help the developers prioritize what to work on, I ended up going to a ton of agile conferences and speaking about product management. And I started to learn that there was this product owner role in Scrum. It feels like it's growing, like more and more companies are adopting this as the way to work. A lot of large companies turn to Scrum or to the frameworks, and it's because they traditionally didn't grow up building software. When you look at agile methodologies, what we're really saying there is we wanna be able to move quickly and deliver great value to customers. If you embrace those principles, you're gonna do well.

1:05 Today, my guest is Melissa Perry. Melissa is a legend in the product management community. She's the author of the foundational book, Escaping the Build Trap. And her most recent book, Product Operations. She's also the CEO and founder of the Product Institute. which trains product managers at all levels. She's trained PMs at almost every Fortune 500 company at this point. And in our conversation, we dive deep into a topic that I don't spend a lot of time on on this podcast.

1:31 Product owners, Scrum, Scaled Agile. And building product at very large Non tech companies. Melissa shares the history behind these ways of working, what she's seen work and not work when companies roll out these frameworks. And most importantly, what you can do as a leader at one of these companies and as a product owner working in one of these companies to level up your organization and yourself.

1:54 I learned a ton from this conversation, and I'm really curious to hear what you think, since we don't cover this kind of stuff on this podcast too much. If you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube. It's the best way to avoid missing future episodes, and it helps the podcast tremendously. With that, I bring you Melissa Perry. Yeah. Melissa, thank you so much for being here, and welcome to the podcast.

2:19 Thanks, Lenny. Thanks for having me. First, let me give a little context on this conversation that we're having. I think it's gonna be a little bit unique. So I was doing a deep dive on the job market in tech. And I saw something that was really surprising to me. that the product owner role was the third fastest growing role.

2:38 In tech. And this was just in the US the data I was looking at, but I think it's probably true broadly. And This was extremely surprising to me because I've never worked with a product owner. I've never uh I don't hear anyone in my circles talking about product donors. I've never wanted to hire a product owner.

2:52 And it feels like it's just kind of this very different part of the tech ecosystem that you don't hear a lot about on podcasts like this. And it's clearly growing. It'd be really helpful to spend some time.

3:03 helping people and helping me understand. This part of the world. And so I asked you to come on to talk about this. You've been Up close and personal with a lot of companies working with this Way of working with product owners, scale to agile.

3:16 and all these things and so I couldn't think of a better person to have on here to help us. Understand what's happening here and also just to help people do this better. So, Melissa, thank you again for Coming on and and helping us understand this.

3:28 Yeah, I'm excited to talk about this. I have been really passionate about this topic for For many years. And I I've been talking about it in both agile circles and product management circles, so Pretty excited for the listeners to hear what else is going on out there. This episode is brought to you by Pendo, the only all-in-one product experience platform for any type of application.

3:50 Tired of bouncing around multiple tools to uncover what's really happening inside your product? With all the tools you need in one simple to use platform, Pendo makes it easy to answer critical questions about how users are engaging with your product, and then turn those insights into action. Also you can get your users to do what you actually want them to do. First, Pendo is built around product analytics, seeing what your users are actually doing in your apps so that you can optimize their experience. Next, Pendo lets you deploy in-app guides. that lead users through the actions that matter most. Then Pendo integrates user feedback. so that you can capture and analyze what people actually want. And the new thing in Pendo, session replays. A very cool way to visualize user sessions.

4:34 I am not surprised at all that over 10,000 companies use it today. Visit pendo.io slash Lenny to create your free Pendo account today and start building better experiences across every corner of your product. Yes. You want to take your product led know-how a step further? Check out Pendo's lineup of free certification courses, led by talk product experts and designed to help you grow and advance in your career. Lear more and experience the power of the Pendo platform today at Pendo.

5:00 Dot io slash Lenny. Mm-hmm. And I'm excited to chat with Christina Gilbert, the founder of One Schema, one of our longtime podcast sponsors. Hi Christina.

5:13 Yes, thank you for having me on, Lenny. What is the latest with one schema? I know you now work with some of my favorite companies like Ramp, Vanta, Scale, and Watershed. I heard that you just launched a new product to help product teams import CSVs from especially tricky systems like ERPs. Yes, so we just launched one scheme of file feeds, which allows you to build an integration with any system in 15 minutes as long as you can export a CSV to an SFTP holder. We see our customers all the time getting stuck with hacks and workarounds, and the product teams that we work with don't have to turn down prospects because their systems are too hard to integrate with. We allow our customers to offer thousands of integrations without involving their engineering team at all.

5:53 I can tell you that if my team had to build integrations like this, how nice would it be to be able to take this off my roadmap. and instead use something like one schema, and not just to build it, but also to maintain it forever. Absolutely, Lenny. We've heard so many horror stories of multi-day outages from even just a handful of bad records. We are laser focused on integration reliability to help teams end all of those distractions that come up with integrations. We have a built-in validation layer that stops any bad data from entering your system, and OneStreema will notify your team immediately of any data that looks incorrect.

6:24 I know that importing incorrect data can cause all kinds of pain for your customers and quickly lose their trust. Christina, thank you for joining us. And if you want to learn more, head on over to oneschema.co. That's oneschema.co. So before we get into the history, is there just anything broadly that you think might be helpful to share before we dive into like the history of the product owner role and? All these things. maybe it'll help to set some context of, you know, where where did I

6:49 see all of this start emerging as well. When I started in tech, I was very much a product manager. Never heard of the product owner role before in my life. And in Escaping the bill trap I talk a lot about How

7:02 We use Scrum when I started working with this team in a startup, and it was the first time I ever heard of it. That was like twenty eleven. And At the time. the person who was teaching me about agile was very like, hey, this is this is flexible. We're just gonna break things into sprints.

7:17 we're going to um sit there and actually talk about the work, right? This is made for us to actually get better at our jobs. So We were pretty sold on it, and it was never dogmatic. And as I worked at other companies. I found that they were being a little more dogmatic with their scrum, with their stand-ups, how we actually run things.

7:35 And then uh I started speaking at conferences. And one of the first conferences I spoke at in New York City was called Lean UX. And there was a bunch of people from the agile world there too. So I learned that this was much bigger than you know what we were learning in my company and what we were doing in these companies. There's this whole group of people out there practicing agile. And I was like, Oh, this is cool. I wanna learn how to do things better. So like teach me about your philosophies. And I ended up going to a ton of agile conferences and speaking about product management.

8:03 And at the time people were really excited to hear more about it. And I started to learn that there was this product owner role in Scrum. Where I was talking more about how we traditionally talk about product management, like understand your customer, go out, test things. Make sure there's a hypothesis. Don't just blindly build what you want to build. And I found out that that was not the case in a lot of these companies who are adopting Scrum and introducing a product owner role.

8:27 So I started doing a lot of trainings um through my school product institute. And I'd get called into these large companies, like all these large banks, um, probably around twenty fourteen, twenty fifteen. to help them learn product management. And I was really excited about this because

8:43 Before they didn't want anything to do with it. They were like, I don't know what product management is, I don't need this. So I go in to train people. And I found that a lot of them had been going through an agile transformation. And they had all of these new product owners where they came in and they basically said Hey, like

8:59 You're a product owner now. Your whole role has changed and they came from all different backgrounds. Some were developers. So a lot were business people who worked on the banking side. A lot were business analysts. Some were project managers, but they just collectively took a bunch of people And said

9:15 Today you gotta be a product owner'cause we're gonna do Agile now. And I would come in and help train these people. And what I found was That there was a really big misconception. about what those people should be doing. compared to what they teach in Agile and Scrum.

9:30 versus what we all consider great product management. So I've been trying to fill that gap for the last, you know, almost ten years. working with these companies here. And then I would go to their leaders, and at the beginning of these agile transformations, I'd be like, you know, you can't just do scrum. That's not going to make you. amazing at delivering products. There's so much more to this.

9:49 And the leaders didn't quite understand that. And I'm noticing this really big shift in the industry where We're finally getting there. A lot of companies are doing it well now. Capital One is a great example that took their agile transformation and started adding product management on it and they've They really turn that around in the card business.

10:05 But So many organizations are still at the beginning of this journey. And they're at the place where I saw people ten years ago. So I think there's still a lot of companies out there, maybe we take it for granted in tech or in Silicon Valley.

10:19 about how many companies are doing this and how Big this scope is. Where there making these roles, but they're not really doing product management end to end. So

10:29 That's kind of where I've seen all of these areas and I've been trying to help organizations for the last, you know, ten years really set up robust product management practices. So it's not just one piece of development. It's How do we actually build better products? I love this example of Capital One is just like it can work really well. Yeah, and you can get to a place where it's actually really productive.

10:48 So there's a few ways we can go about this. Do you think it would be helpful to uh talk through the the history of the product owner role, just like where it initially emerged? Yeah. I think that's a great place to start. I think it brings a lot of context to to what's happening. Uh and and people forget about the history here. So when I explain it to people, I say, you know, we had product managers in Silicon Valley, right? They were in Google.

11:09 They were in all of these companies, Amazon. And they were born out of this business role and from a software native company. Your software is the business, right? It's what you sell. It's what you actually look at. So Our product managers in Silicon Valley are doing, you know, they're doing market research. They're talking to customers, they're working with developers, they're iterating, they're doing the end to end product management.

11:31 Oh. What happened on the other side of things, especially in large companies, is the emergence of product management from Scrum. From product ownership. And that's usually the first time these companies were introduced.

11:43 Two. product management was from implementing a product owner role And then going, Hey We're still not meeting our goals. Like we're still not Are we building the right thing?

11:51 And then they start thinking about product management. And where that role came from is uh scrum. So if we go back and talk about the history of Agile. Agile was a movement that got started by software developers. So in two thousand and one, the Agile Manifesto was written

12:08 A bunch of developers got together in Park City, Utah. Uh, they were all skiing together and they said, Hey We've been independently all working on how to develop software better. Some people were d practicing scrum, as we know it today. That was Ken Schwaber, Jeff Sutherland. There were people who were doing uh different types of agile frameworks as well. Conban

12:27 Where you were You know? moving it through a Kanban board. Uh, there was uh behavioral driven development, there was feature driven development, that was a style of Agile. There was um XP, extreme programming. That was started by Ron Jeffries.

12:41 All of these people kind of found each other saying, Hey, we've been trying to push the boundaries of how do we develop better software. And they got together and they wrote the Agile Manifesto. As we know it today. So the Agile Manifesto is really just a guideline on how they're striving to not just be You know

12:58 people who code what people want, but like Building better products. How do we build better products through software development? The promise to remember this is and I keep saying it, but They're all software developers. Nobody was a product manager.

13:10 Who went to that meeting? Right. Nobody who wrote The Agile Manifesto was actually a product manager. And I've spent a long time talking to these people as well over the past ten years just saying, Hey, how did this come about? Right. Where did this come from?

13:23 The one person who was really close to them who was a product manager was Jeff Patton. But he never signed the Agile Manifesto, he wasn't at that meeting. So he talked to them a lot. He was able to See what was going on. But all of this was approached from a how do we build better products from a development perspective. So that's really important to know.

13:41 To the people who signed the Agile Manifesto, Jeff and Ken, as I was talking about They were independently. kind of coming up with Scrum on their own in their different companies. And they got together and started to codify it. And they said, This is how I'm doing it, this is how I'm doing it.

13:55 And they ended up writing the scrum guide. And the scrum guide is what a lot of people base their agile practices off of today. And in the scrum guide, it outlines a bunch of rules. Uh that you would do on the development team.

14:08 And then it says how you should be developing products. So most people out there are working in Scrum today. And what they say is let's break things down into two week sprints. You can change the length of your sprint if you want to. But two weeks sprints is pretty standard. At the beginning. We define what we're gonna work on in the backlog.

14:25 It's the product owner's responsibility. to define what goes into the backlog. Write down the user stories for it. Do all that. Then the development team comes in, they discuss it.

14:35 the product owner r prioritizes it, they ask questions and then the development team commits to what they want to build and they go out and do it. And at the end, the result is a potentially shippable product. Not necessarily shippable, but potentially shippable. So they're trying to break it down into small chunks. and build things instead of what they had been doing in a lot of companies, which was

14:55 building stuff for like three years and then releasing it a big bang. And what all of the people who signed the Agile Manifesto realized was If we do it the other way, if we do a waterfall type environment. So agile waterfall, that's where we go across. There's a lot of risk. Because we don't test it with the customer and we don't get feedback on it.

15:11 If we spend three years building it and never show it to somebody. So it really approached a different way of building Software. So it said let's chunk it down and And try to get feedback faster.

15:22 Really noble intention. In the Scrum guide, though, it introduces these new roles. So we have developers as we know and love them. We also have a product owner. Then we have a scrum master. And the Scrum Master is in charge in Scrum of actually helping people

15:38 Do scrum better. That that's literally their job. How do I do scrum better? How do I make sure that the team is working well together? So they host things like retrospectives where at the end of a sprint we say what went well, what didn't go well, how should we actually inspect and adapt our process. The product owner is where things get murky.

15:56 So the product owner In general. First showed up with Scrum. And if you go and you read the first scrum guide, which I I pulled up and started reading, because I've been very fascinated about how This is described.

16:09 It says that The product owner is responsible for maximizing the value of work done. The team does the work. Interesting, because now the product owner is not quite part of the team. The team consists of developers with all the skills to turn the product owner's request into the potentially shippable increment each sprint.

16:26 The team is usually seven plus or minus two members. And then when you go further into the first version of the scrum guide. It does say that the Scrum Master works with the customers and management to identify and instantiate a product owner. The scrum master teaches the product owner how to do his or her job.

16:42 in order to optimize the value of the use of Scrum. If they don't The scrum master is held accountable. Then it's got another tip. If we go deeper into this.

16:51 Says for commercial development, the product owner may be the product manager. For in house development efforts, the product owner could be the user department manager. What's interesting is that That was the first version of the scrum guide. And I get into arguments about

17:06 Scrum guy with people all the time. Twenty thirteen's version, though, the more updated one that you could go and find, is the one that almost every company has run an agile transformation off of. It loses that thing that says the product manager could be the product owner. Doesn't see it anywhere in that guy.

17:23 So this was the first version and and you could kinda tell it was like an aside. It's like oh by the way. The product owner in Scrum doesn't need to be a product manager. It could be the customer, it could be a developer, it could be It's usually the customer. But when They were writing this too. Sometimes the customer was an internal person.

17:39 like at a bank or somewhere where we're building software. Who was Asking. For the software. Right? They were like, Go build me an internal tool, go do this.

17:47 So now we're just asking for requirements. Inside a company. And that's where you can start to see how the product owner role. kind of evolved into somebody going to ask like hey what do you want me to build? What's required here.

18:00 And then just listening to somebody come back and say, I need this feature, I need this feature, I need it's this feature. Scrub doesn't describe how to get the stuff into the back lock. And it didn't.

18:12 in the twenty thirteen manuals. The manuals have all been a little bit better. They've all kind of been updated sin. And they do describe like it has to start with the vision a little bit more. You have to break down the vision for the product and get in there. But none of that existed. In the early versions of Scrum.

18:28 So when people got trained on how to be a product owner What was happening here is uh and the this is the whole other world of Scrum over here. When people get trained to be a product owner, it's usually a two day class. Where they teach them. Hey.

18:42 This is how you break down a backlog. This is how you do stand up with your teams. This is how you think about prioritizing work. This is how you manage your backlog, prioritize it for the developers. This is how you run the ret you work with the retrospectives. But it doesn't teach them about

18:57 experimentation. It doesn't teach them about market research. It doesn't teach them about data. It doesn't teach him about any of the things that we need. to be a product manager. So then what happened was we went into this these agile transformations at these companies.

19:12 And uh They said, Hey, let's adopt Scrum because Scrum was built as a way to Building. Better products faster. It's literally the tagline.

19:22 And that everybody was like, Yeah, I wanna build products faster. Okay, great. Like let's do scrum. And all these large organizations back in the early twenty tens and the two thousands said, Oh, we gotta be better at software. How do we do this better? Cause otherwise we're gonna lose when it comes to innovation.

19:38 So they adopted Scrum as a way to build software. Now what happened is in order to do Scrum Scrum basically sells Training. That's what Scrum does.

19:48 So all of these agile coaches would come in And teach your product owners, newly minted product owners, right? took all those people, made them into product owners, put them through a two day class. And then say go. And that was the beginning of all the agile transformations. And that's where a lot of companies still are today.

20:05 So this product owner roll did not emerge. from product management as we know it today. It was a way To help the developers prioritize what to work on But that was it.

20:17 And the product owner was held accountable For making sure that they were working on the most uh pressing things, right? The highest value things. They do say that. But to me, if you look at it from a developer perspective, it's also the person where you can say, Hey Well, you told me to build that.

20:32 Mm. Right. We didn't build it wrong. You told me to build that. It almost gets into like Consulting territory. We're like, Okay, if the product owner

20:39 prioritize all this stuff for me. And told me what to do. I can't be held accountable. If it was the wrong thing to build. And some of that stuff does come up.

20:49 in a lot of teams that struggle to adopt Agile to adopt Scrum. So I feel like there's big misunderstanding out there about What is this role and what should we be doing? But the the premise of this is

21:01 when we talk about Scrum. It's just one piece of the puzzle. And when people talk about agile now. They almost always associate it with Scrum. I was actually Googling agile methodologies.

21:12 And like I said. The other one's Kanban's an ad agile methodology. X P is an agile methodology. They don't have product owners. They they do not exist in those methodologies. They're for developers to work on things, for teams to work on things. And XP would consider

21:27 product managers. In the teams. As I as far as I know it. But Scrum kind of sees it as a separate thing. So

21:36 Agile methodologies, everybody says, Oh, they're scrum now. And so it gets a bad connotation out there about what to do with it. think scrum, if you do it well, is bad. But you have to understand that it's just one piece. of building great products is not the whole thing. And companies will adopt it like it's going to

21:54 radically transform everything, and to be fair. A lot of times it's sold that way too. There's kinda like a bigger picture question that's coming to mind as you talk about this and I'm imagining founders listening to this and smaller companies listening to this like Why do we need any of this? We're we're just like we're just gonna like especially, you know, Silicon Valley startups. We're just gonna build stuff.

22:13 We know where we're we don't need these. frameworks, we don't need a Scrum Master, like we just have awesome p developers and product managers. And we're just gonna build off some stuff. And I don't know anyone That has worked this way that's built amazing things. Can you talk a bit about like

22:26 who ends up looking for solutions here, like where this even comes from. What companies need help here versus like I just don't need any of this. A lot of large companies turn to scrum or to the frameworks, and it's because they traditionally

22:41 didn't grow up building software. So they're looking at how do I implement something that has rigor at scale? And that's where you see a lot of scrum come up. Now I've seen startups using Scrum. Uh

22:52 Some of them do it fine. Right, they understand that it's just more about trying to get things out the door every two weeks to test it with customers. I think if you keep that philosophy, like I said, I used it. And we didn't have a lot of rigor around it.

23:04 That was fine. When we were doing Scrum when I did it with my team back in Open Sky. We got to this point where we're like, Two weeks is too long. We're just gonna ship things every week. And we just talked to each other. We skipped stand ups, which is like sacrilege and scrum. But we skip daily stand uh stand ups. We didn't need to stand around and talk about it. We talk to each other every day.

23:22 For me, what was amazing and where I see teams actually thrive when they start using scrum is when you go and talk to people, right? You're having the conversations about the work, you're breaking it down, you're understanding it. So the developers and the rest of the team can go hit the road running and people can ask important questions. If you're not doing that

23:41 That's where I think things like a framework help. But if you already are doing that, you don't need a framework, right? Like you don't need scrum, you don't need to be prescribed to this two week sprint or anything like that. As long as you have a methodology or It doesn't even have to be it.

23:55 Define methodology. Long as you have a way of working. That gets things out to customer as well. Who cares? Right.

24:01 Who actually cares? And where there's a lot of I think baggage in the industry and where I think where I hear product managers get really frustrated and other people as well, developers too. Is that When you do scrum by the book.

24:15 or how people teach it and how they write about it. There's a million meetings. And I know they were put in there so that people were forced to talk. But when you already know what you're supposed to work on. Why do you need to keep doing meetings, right? Like

24:27 Shouldn't you just go do some work? So a lot of developers complain, a lot of product managers complain that Scrum has too many meetings. And they don't actually get to do work. And that's where I think you have to go back to the inspect and adapt part. And a lot of people who are very religious about Scramble come and yell at me about this. They're like, Oh, well that's not how it's supposed to be. You're supposed to inspect and adapt. Agree.

24:46 Right. But a lot of people aren't doing it. And that's the piece where you go and you say, Is this serving us? And if not, let's get rid of it. Or let's not do those types of things. So When you're a small startup, I don't think you

24:57 Need. a lot of this overhead. It's it's really much designed for larger scale companies and those are the ones that you see really adopting it. And from what I've seen on the data, it's also companies that are, as you I think alluded to at the beginning, not like necessarily software first, product first companies like

25:14 feels like it's very common in like banks and telecom companies and Companies that aren't like product first and software first. There are SaaS companies that do scrum. out there. And they like it. And I don't think they're very

25:26 Uh Dogmatic about it. Right. But they they do it for a reason of um just trying to provide some more context. to their teams about how to work together at scale. Uh I've also seen

25:37 places where, you know, they don't prescribe whatever methodology you want to work with. But Instead, they'll spend a lot more effort breaking down, you know, the road maps, thinking about what are we gonna do each quarter. trying to like set those themes and then they just let the teams run. And

25:52 That works as well. I I think it really depends how they adopt it, but I would say it's not a hard and fast rule that no startups are doing this. Some are the some are doing it. I just don't

26:03 Know how it's going for them. It might to me it might be overkill if you're doing that with like a team that's pretty pretty experienced in doing this. Yeah, and w uh what I meant to what I was ins insinuating is less just like scrum as a general idea and more like very structured, rigid Oh yeah.

26:19 Processes and also with product owners. And then there's this whole concept of safe. That we can talk about. So should we get into that? Or should we talk about uh product manager versus product owner and just like the challenges People that have their

26:33 Let's let's talk about safe because that's where a lot of it started to get confusing. Yeah. So scaled agile framework came out of the desire to figure out how do we scale Scrum and different processes and bring it to organizations at scale. So it originated From um a more structured approach to agile two to called

26:52 Rational, unified processing. Now, safe wasn't the first thing. That started at scale.

26:59 It was there was also LESS, which is um a scaled agile framework. And then Jeff Sutherland, who did Scrum, has Scrum at scale. So it's not the only scaling framework out there. Uh there's a lot there's actually a lot of out there. But safe. was the one that was marketed the best. And the way it's marketed.

27:15 Is will tell you. Everything you need to do. To do all of your agile teams with Scrum. And put them all together. So

27:22 The idea behind Safe was that uh Dean Leffingwell came up with it. He wanted to really show how you tie multiple teams together at scale in an organization. And how do you bring some rigor and process to that? And it

27:36 The executives at really large enterprises, we're talking tens of thousands of people, right? They love safe because it prescribes a lot of an operating model of what to do when it comes to development. But it also gets billed as like, Hey, this is the whole model. For you to go do software.

27:54 And if you look at it, it's It's a it's a big map that everybody kinda makes fun of a little bit. And it describes like all all different things on it. If you look at the map, and you can click in and you can see the definitions and you can see What's going on what's going on in the areas. The save image has gotten bigger and bigger over time.

28:12 the I think the what is this version six. Uh and I do know a lot of people who worked on safe. So I I know a lot of trainers And I've worked with companies. The first time I was introduced at uh to safe It was when I uh was working with a bank back in twenty fifteen. I came in to train their product managers. I'm

28:29 During my training, we're like setting them up on how to like go talk to customers, talk about hypotheses, MVPs. And somebody came up to me and they said, Hey Melissa. All this is great. But I don't have time to go talk to customers. Because I'm a product owner.

28:42 I was like Well, what are you doing on a day to day basis? Like what What did she have time for? I gotta write my user stories. Like okay.

28:51 How how many user stories do you write per day? And this is for the developers to have a full backlog so they could all work, right? She's like, Oh, I yeah, I spend like pretty much forty hours a day writing user stories. I'm like on on what? We're like what are you what are you controlling? And she's like the login API. For a bick.

29:07 I'm like, can you log in? She's like, Yeah, and I'm like, So. So what else are you working on, like Like is there a new initiative? Is there a new thing? And it's like no, I was reorganized. Into a team where I became the product owner.

29:19 I have a product manager who goes and talks to customers, but then she comes and she tells me what to build. And then I write the user stories around it and I put it into the backlog for the teens. And I was like What is this? Like and then they said that's safe. This is what we're working towards. So this was my first experience with Safe, and then I ran into another company that did it, another company, same thing over and over and over again.

29:41 Where? All these product owners. We're just basically trying to keep these backlog fulls. for developers and they were working on such a narrow level. And when a lot of organizations too, I saw it

29:51 reorganized into agile teams, they did it by component. So everybody was over every tiny little feature and these teams were massive, right? Like Super huge scope. And some of the stuff was just not prioritized, right? It was done. Like you didn't need to work on it. So they were finding work to do so people wouldn't get fired, right? Like That's how the product owners operated. So there was all this legacy baggage sometimes in companies.

30:14 Where they were all re put on things by By component. And they're just Making up work to do.

30:20 So Safe introduced this kind of split between product manager and product owner. And if you look at the map. The product owner is part of the agile team. Where they sit with the scrum masters, um Which is a team coach.

30:33 That they call here and the developers. And then the product manager Is sitting with a system architect? And what they call a release train engineer. And what Safe does

30:42 is they pull a bunch of agile teams into a release train. And you get on the train. when you're ready to ship things and you make sure that it all goes pretty smoothly to get to that potential shippable increment. or that big feature launch that you would be doing with safe.

30:58 And safe's are really good at prescribing how to do that. They're great at Describing like how to do the release trains, how to bring those teams together, how to put them on it. Um, and then they do this thing called big room planning. Where they get the entire release train together, all these teams.

31:11 They put'em in a room and then every quarter you're kind of breaking down what we're all gonna work on. Where I hear frustration from teams every time I come in and train them is that When you do big room planning, a lot of times it's a commitment. So you start at the quarter They haven't been doing good discovery'cause remember, these people have not been trained on good discovery.

31:30 So they don't really know what should be they should be working on. They haven't been out talking to customers a lot of times. They kind of scramble, they figure out what what needs to happen. Usually they have a backlog of stuff that does need to happen because it just has to get done. Uh they map it all out in a big room together, they commit to it, and then that's the quarter. And they asked me when when am I supposed to do discovery?

31:50 I'm like, well, before that, ideally, right, like you should have a vision, you should be breaking it down, you should be putting discovery into that vision. Talking to customers, feeding that in there. And then I hear We don't have time to do that because we sprint back to back. I was like, what does that mean?

32:04 And they're like As as a team? We go and we basically do two week sprint into two week sprint into two week sprint and I gotta make sure my developers are full. I gotta make sure they have things to work on. So if I go take time off to go

32:18 talk to customers, which also is not my job as a product owner. It's my product manager's job. They'll feed me in what the customers are saying. Then I break those down into features and I can work with the developers on it. So that's how all of this stuff starts going. And what happens in organizations that they don't understand here is that

32:36 It's not the most efficient way to work. Okay. You should be uh I I see a lot of developers out there become

32:45 Uh almost Like how how do you describe it? Uh reliant on the product manager or product owner to tell them what to do. And even though you build them this great vision and explain what needs to happen. They go, Oh, I can't work on it'cause the product owner hasn't

32:59 hasn't prioritized it. Right. And then they asked me if I don't have enough for the developers to do on feature work. What are they supposed to do? I said, I guarantee you there's a ton of tech to it. That you'd be working on. Like you don't have to scope that out. Like

33:11 let them choose what's the most important thing. They should be working together as developers and architects to figure out How to tackle some of that tech debt, how to get into it, right? It while you're figuring out is this the right thing to be building. So With all of this stuff, it feels like

33:26 people feel like they don't have time'cause they're in a million meetings and the expectations of these companies is that Every sprint we're like delivering software towards these roadmaps that we promised. And The last quarter. And we're not checking to see if they're right. We're not checking to see if they're actually

33:40 Helping us move it forward. Um and a lot of times the organizations are not set up with the right feedback mechanisms, the right user research and the right uh data to tell us if everything is working. So they can feed that in. To the next release planning. So they're just planning, planning, planning, breaking it down into sprints and going.

33:57 And Safe. Is not Good at describing. How you do all that other work?

34:03 So in a lot of this stuff too, they they started putting on There's like pieces that they put onto this map of safe where they're like, Hey, you should do OKRs. And it's like this is what OKRs are. You should do a roadmap. This is what a roadmap is.

34:17 like how all of that cycle kind of works together where you're balancing discovery and delivery and feeding it in. gets really confusing in organizations. And then what it's basically saying is a lot of the discovery work goes into the product managers. And the product managers, the product owners report into. The product managers.

34:34 And what I've seen that doesn't work here is that you are basically making these product owners order takers. They are extremely tactical. And then when it's time to actually be more strategic, let's say you want to be promoted to a product manager, well, some organizations, that's not even the same business line, the same, not even the same career path. It's product owners go over here and product managers go here and they report into different people. And

34:58 If you ever want to move from product owner to product manager, a lot of times you don't get experience with the strategy. Like figuring out what customers want, breaking it down. looking at at the market research, determining like, is this valuable? Is this what we should be working on? And They're not even getting exposure or a chance to do that because Safe is like, No, that's the product manager's job. Your job is to go really deep.

35:18 And work with the developers. Wow. Okay, so This also a lot of this sounds quite absurd. hearing all the details and looking at this image. Uh

35:30 That being said, many companies are adopting this, it feels like it's growing like more and more companies are adopting this as the way to work. I imagine the incentive is we just want to build great software and we don't know exactly how and there's this

35:46 Process we can plug in and it'll help us do it. Mm-hmm. I guess thoughts on that and do you find it Yeah. can work or often works or often doesn't work. What is your experience with people adopting this?

35:58 And how it goes. I know a ton of companies that adopted safe. about eight years ago and I've got gotten rid of it. Um you know, Capital One just came out and said they got rid of all their agile roles, all their Scrum roles. They were an early adopter of safe, they don't do it anymore.

36:13 Um and they they wrote about that. In a newspaper. Uh, I've seen it happen. More often. Now

36:19 In a lot of our organizations too, I'll see parts of them. Do safe. and other parts not do safe. So it could change business line to business. I don't think though That

36:31 people grasp how much it's still out there. I get questions on safe every single day on the podcast. Like I everybody asked me, like, why are we still doing this? And it's For what you said. Executives buy safe.

36:43 Because it is the only framework out there. that basically draws them a map and says plug and play. Do this. And that's why everybody's so excited about it because It's the only thing that specifies things to this level.

36:56 And they went, Oh, it's something I can understand. It's something that actually has definitions around it. And to be fair, that was like a great thing for safe to do as a marketing tool, you know, like Bravo, they created this thing that everybody wants. Like Good product to sell.

37:09 But It's overkill. And that's what I keep hearing from organizations is Yeah. It's basically taking the responsibility away from leaders to go figure their stuff out themselves as well. And if you were a new leader and

37:23 You know you've just been dropped into this role. I have tremendous empathy for them because Yeah, where do you get started, right? Like how do you try to run a technology organization. I Somebody came and told me the CIO came and told me I'm in charge now.

37:36 Right. I'm in charge of all of the developers or I'm in charge of all the product managers now. Where do you start? Right? I can totally tell why people adopt safe.

37:46 Because you're like oh I've been looking for the handbook, right? Like I've been looking for something to do here. But the problem is It's only solving a little bit of the puzzle, which is bringing those teams together. And people do say it does release trains well. But it doesn't tell you also how to do your job as a leader.

38:02 It leaves it all out. So they talk about portfolio visions and portfolio management and safe there too. But more often than not, I come in and I find Everybody above product owners and product managers. Let's talk about directors of product, VPs of product, right? They don't know what they should be doing.

38:16 as a VPA product or a director of product. It's like what what's my role? What should I be feeding in here? And Safe doesn't even have that in there. That's not even a role. Like product manager going up into those levels is not really there. So

38:30 What do you do when you own a whole product line? in an organization. What do you do when you're the head of product for a credit card at a bank, right? Like What's my job? Doesn't say that.

38:41 So there's a lot of people out these in there in these organizations that I've been working with who are I'm like you you were supposed to be doing strategy, right? And this is how you do strategy. This is how you go out and talk to customers. This is um the patterns that we have in software. Are you doing a plat are you doing a platform strategy? Do you need APIs?

38:59 How do you think about your app strategy rolling it out? How do you do this here? All of that stuff. doesn't quite come from ways of working, which is what safe is doing, right? It's about how do you do your jobs in those areas. And a lot of organizations who adopt SAFE don't realize that you need

39:16 I had a product, right? Like you need somebody to actually be feeding that vision all the way down. and make sure it's breaking up around the teams and controlling that portfolio vision and doing all of these things to into it. So I have not seen

39:29 safe slowing down by any means out there. for people adopting it. I see more and more organizations uh adopting it. I think we take for granted too in Silicon Valley, like How

39:41 Many people are just starting on their journey. for digital transformations. There's a lot of like pharmaceutical companies Banks, insurance companies. They they outsource their development.

39:52 Or they had an IT team. But they never had to really think about it before because Digital wasn't as important. Now they do. And some of these companies

40:01 Most of these companies are fortune fifty companies, right? Fortune one hundred companies. And I think a lot of like the ones I see at least banks. Realized early on, hey you know, when it comes to apps and how people interact with our our our stuff. software's important. But there's a lot of companies that

40:16 Did not catch that train. And they're just starting. And then they turn to things like safe because It gives him a guideline. Hey, I've never done this before.

40:25 I've been in this bank for forty years. All I know is like waterfall type development. What do we do? And then we'll go we'll go look at safe. I love that we spend time on that'cause I think it's really important. Like you can be

40:37 cynical about all this and like be like, what the hell are people thinking? This is crazy. But As you described, people just have like a problem to solve. They've never done this before. They look for solutions. They find something that seems right. They see other people doing this and like okay, let's try this thing. And

40:53 What you've seen is it rarely actually works out the safe specific approach. So let's talk about people that are There's like a few ways I think we can help folks. When is someone Trying to

41:04 do with say an agile transformation or digital transformation, like how Your advice for how to actually do that. Better. And then I wanna talk about like say you're a product owner or a PM within a organization that works like this, what can you do?

41:15 So maybe we'll start with the first. Say someone's like trying to figure out what We need we need to build better product something's not working right. Safe as an option. Your suggestion is don't maybe do that. What what should people do? And I know this is like a they're not gonna have the answer and like a short answer, but

41:31 Generally. How should people. When when I've worked with company that's on digital transformations, You have to you want to develop an operating model. Right. And

41:41 That's where a lot of these agile methodologies came out of. You have to understand that's just a development operating model. That's not actually gonna help you with go to market, with launching your products and with product management. So what I advise for companies do is first sit down and say Hey How do we think about building our operating model and When I think of

42:00 You know, product operating models. And what I do with companies is like we break out How do you determine product strategy? Do you have a good product strategy, right? You look at your organizational design. How are we Uh actually

42:12 Organized around our products. Do we have good coverage of product managers and do we have skilled product managers? Up and down the organization. Then we want to look at product operations. Do we have the infrastructure in there? to help support these teams. Like can they get the data to make decisions? Can they actually be in touch with customers?

42:29 A lot of these large organizations haven't actually thought through many of those steps as well. that enable product managers and development teams To be successful. Right. They don't have ways for them to go and talk to customers. So that's why they're not doing it. So I have a lot of

42:44 empathy for people in these organizations as well. Cool. can't do product management well because of the bureaucracy or the things around it. So leaders need to solve that, right? They need to understand what the role is and they need to open it up. And then we gotta look at our culture and incentives, like

43:00 Are we just rewarding people for shipping as many things as possible, right? Which is like hey just put everything you possibly can into that release train or That backlog. Or are we coming back and saying, Hey

43:12 Is this valuable? Is this tying it back to our business? Many organizations do not have a great product strategy. many large organizations. that I've worked with.

43:24 And it's that tying it back to the value piece, right? Tying it back to Is this gonna reach our company goals? You're a huge organization and let's say making billions of dollars a year. And your your goal is like expand geographically.

43:37 What are you doing in your portfolio to actually enable that, right? Like what products are you building? to expand geographically. So many organizations don't have the transparency to actually even see that. One like crazy thing, a lot of people

43:53 give large organizations a lot of flack for And I know Marty does this too for for focusing on processes. I don't think processes are the enemy here. So for example, if I hear somebody really worried about getting a road mapping tool in there or something like that.

44:06 I'm like, yes, you need that. Because you have no idea what your four thousand teams are doing. And if they're actually coming back. to the business goals, right? You have no infrastructure in there to be able to see that transparency. Those types of blocking and tackling is absolutely necessary for a transformation, right? For a

44:23 organization to be stood up around software product management. You have to have the transparency to actually see those things. You do need to have enough process. So that You as an organization can be efficient. In getting things out the door.

44:36 And that's what I think Safe was trying to do. But it's not working because it's not solving the problems of the product management and it's not solving that problem of connecting the value Back to The product teams.

44:48 Instead, it's seen as a role that almost like babysits developers or kind of tells everybody what to do. But where's the discovery? Where's those things come in? And I know with the safe image that we got over here. Like they try to drop things like Lean U X in there, which Jeff Goth will think is hilarious, but it's not really pulling it all together of how do we do this on a cadence, right? How do we

45:09 How do we help people go out there and actually talk to customers, how do we enable them to do it? So if you're starting a transformation It's not just thinking about How do we build the product?

45:20 But you should also be thinking about how do we launch the product and how do we make sure this is the right product to to do. Right. That's the big pieces of it. And that's where all that product strategy comes in. And you should also look at

45:31 The career paths. And This is what really bothers me. about agile transformations and what bothers me with Scrum and Safe is that When we organized in these large trans uh large organizations into

45:45 Agile teams. We made all these new rules called a product owner. And so many organizations don't have a career path for them. So they they email me and they go, What's my career path? What do I do next?

45:57 Right, where am I supposed to go? And I've been saying for like ten years, like this is not a team role. It's not just a team role, right? Like it's a business role and it rolls all the way up to helping you further your business and you have to make sure that

46:11 people on teams can be promoted to Running multiple teams, can be promoted to running an entire product line. And to us, that's so simple. in Silicon Valley native software companies, but it's still unheard of. in other organizations. And what happens too, and this is where I think

46:29 leadership and C suite needs to really pay attention. Because we're transforming in this way of working. What happens is some of the roles that we had before do not serve us now. Right. Maybe we don't need a million project managers.

46:43 maybe um people in the business who decided What we're gonna build. Are they the right people to bring with us on this next phase? Right, into product management. Can they learn, right?

46:54 Can they grok software, do they understand those pieces? That's what we have to ask. But people are so organizations are so afraid sometimes to put these career ladders in. because it kind of overhauls their traditional ways of working. And then they've got people who've been in these organizations for forty years. And now you're saying like, hey, you're actually not in charge of that.

47:12 The product manager is in charge of that. And that's scary. And a lot of them get in the way because of that. And if you really want to transform though The C suite has to be like, Hey, we're going in this direction and just Just put it down because I've seen it run by a lot of middle managers, like a transformation run by tons of middle managers.

47:29 And those are the jobs that are usually in most jeopardy when you start transforming And you have to re skill and you have to figure out what to do. And they don't want to do that, right? Like they're not going to be the ones who jump up and down and say, Hey, let's do this. There's a lot of people out there, I think, pushing

47:44 organizations to try harder. And two. internally as well. Like I've worked with a lot of people who run these transformations who just really want it to work. And I think they they do it with the best of intentions.

47:55 But the C Suite has to understand like It's not just a transformation project, right? Like this is a whole new way of working. And if we want a whole new way of working, we have to really rise to that occasion. This episode is brought to you by Coda.

48:09 I use Coda every day to coordinate my podcasting and newsletter workflows. From collecting questions for guests, to storing all my research, to managing my newsletter content calendar. Coda is my go to app and has been for years. Coda combines the best of documents, spreads, and apps to help me get more done. Encoda can help your team to stay aligned and ship faster by managing your planning cycle in just one location, set and measure OKRs with full visibility across teams and stakeholders, map dependencies, create progress visualizations, and identify risk areas. You can also access hundreds of pressure tested templates for everything from roadmap strategy. to final decision-making frameworks. See for yourself why companies like DoorDash, Figma, and Qualtrix run on Coda.

48:54 Take advantage of this special, limited time offer just for startups. Head over to coda.io slash Lenny and sign up to get six free months of the team plan. That's coda dot IO slash Lenny to sign up. And get six months of the team plan. Coda dot IO slash Lenny. There's a few things I wanna pull out from which you just shared. One is Is it

49:17 Just to clarify, you recommend not using Safe. You don't think that's a good approach. Do not recommend using safe. I I think they're yeah. Great. I I There are people who like safe. So let me just say this. Mm.

49:28 There are people who found success with safe every single person I have talked to. Who, like safe, Found success was safe. They ended up ripping it up. And making it into something else.

49:39 So I'm like It's not actually saved by the book. If you do that. Fine, right? Like that's any process, right? Like if you ended up adopting safe and you want to go back and look at it. And say, actually, let's just get rid of all the stuff that's not working.

49:51 And keep the stuff that is. Fine. Right? But being open to understanding like This is not

49:58 the way that we do good product management, like there isn't not a lot unsafe about doing good product management. Like That's the stuff that we have to understand. It could help in certain areas, and I do think it does help in certain areas bring some You know. some rigor to things. But If you take it too far,

50:16 It will it will destroy things. There's actually a great story about A w oh the a water company in the Netherlands. Right. And uh They decided to adopt safe.

50:28 And this is this was on the news like a couple of months ago. They decided to adopt safe. in their IT teams and start working with it. And they're uh they ended up going bankrupt. And the reason they ended up going bankrupt is because the teams were learning the processes were safe. They were taking so long.

50:44 To deploy. their new invoicing system and payment collections that they couldn't collect payments from customers. 'Cause it got so caught up in the process. And that that's what I see happen a lot. in these organizations, instead of talking about what's really important, which is

50:58 Hey, how are we serving our customers? How are we winning in this market? How are we you know, how do we stem churn? How do we do all these things? We're talking instead about like What stand ups are we doing in? Oh, how do we do this release release planning and Oh my God, you guys didn't sprint back to back, like

51:14 You did it wrong and That's not We're talking about work about work, but we're not actually getting into what are we achieving here. And that that's the the part I do not like about rigid processes when it comes to this. So that touches on the other theme I wanted to Bring up is

51:31 It feels like the stuff is Uh Kind of replacement for skilled, talented people. like a product leader that understands how to do these things and has product Taste.

51:45 And has organized teams to build great product. Like it feels like people are just We don't have that, so we're gonna create the we're gonna this process is gonna fix all our problems. Talk can you talk about just the importance of that, like the people you hire to run these things? as key to this, if if that's true.

52:00 In a lot of organizations, the people who buy safe They have not run. large scale technology organizations before. Um or They they're new to this way of working. So they adopt safe and they they hope it works because it looks like a nice plan, like we said, to go out and do things.

52:15 And When you're doing a transformation, a lot of companies are pulling people into these roles for the first time. I've said since day one that I've been working with companies. It's okay and I think it's noble to want to train people. and put them in different roles. Twelve like cool. If you're gonna spend money upskilling your people, like do that.

52:32 You also have to interspers. People who know what they're doing. And I think at leadership. it's really important to bring in somebody who knows what they're doing to help run this type of thing. So there are more people out there and more leaders who have done this before because we've been doing this for ten years.

52:48 So there's Shroudie Patel, uh she's chief product officer at uh US bank for small business banking. I just had her on the podcast. She worked at Shopify. She saw how great teams worked.

52:59 Right. And then she was able to come and help apply that. At a bank. So She She's experienced, right? She's an experienced product person who comes in to help.

53:08 Uh, Melissa Doris is the CPO of Green.bank. And she had worked at Discover Financial. Leading the transformation there. you know, did all that work and then could bring it to Green Dot Bank.

53:18 Like she can see what needs to happen, what needs to actually go on here. So we've got more and more people out there who have done this before who are looking for these opportunities to do it in the bank. And I think it's important for C suite to

53:32 Bring them in. Right, to actually look at that. And where I've seen transformations be the most successful And all these organizations is when you do that mix.

53:40 Right. You keep You keep Some of your people, but you also bring people in to learn. And

53:46 I get hired all the time to come in and train. I've worked with almost every like Fortune fifty company at this point. Fortune hunter company too. And I get in I come in to train a lot of product managers and we do it through, you know, product institute. And we'll train everybody. And what used to happen

54:03 about like eight years ago is they train everybody and they would say go. Where do you go? After you bring in the consultants. To do training to keep learning. Right.

54:12 How do they watch other people in the organization? do great product management if there's nobody in the organization Who's done it before? And luckily, I think a lot of organizations are realizing that. So more leaders are out there.

54:25 who are saying, Hey, I've got to actually Interspersed skills here. Really, I need to bring in some more directors who are experienced here, some more individual contributors who are experienced here. And those organizations I think are wildly successful because they recognize it. And they say.

54:39 I've got to make sure that people can learn from others. 'Cause that's how you keep developing, right? Like that's how we all keep developing. It's not just doing all external classes. And that's where I think these things become powerful. And you can do that at all levels. You don't have to just do it with the teams. You could do it at director level, you could do it at V P level. That that's how we should be thinking about this.

54:57 Now there are some CPOs out there and some VPs of product in these large organizations. Who are new to this way of working. But they have committed themselves to learning. And to trying to figure out how to do it best.

55:09 And they're not saying hey. I'm just gonna adopt safe or I'm just gonna do whatever is over here. They're actually saying, What don't I know? And I'm watching them go out to talk to other CPOs. Do all these other things.

55:22 They usually have great market knowledge, great business knowledge, and they're fantastic at strategy. And then they hire people underneath them who are great at the other pieces, like the execution and getting Getting the software out the door. And I think those people are successful in it as well'cause they notice their skill gaps. And they hire for it, just like any great leader would.

55:40 So In these organizations I I do see sometimes safe or something being a crutch for people who don't know what they're doing to bring in.

55:49 And If you really think about Hey, how do I make this better? And have that continuous learning mindset and that way to wanna propel this forward. I think you'll consider other options.

56:01 and start to think about broader than just safe, broader than just agile, what do we need to make this successful? But The key part of this too. is recognizing that product management is not just this Yes.

56:12 role in Scrum. And I I see this in my like talk too. I say Take Scrum away. You still need product management. Right? Like Product owner doesn't exist without Scrum.

56:22 That's not a thing. but you still need product managers. And that's why all product owners should be product managers. They should be fundamentally product managers. And that's why I do not like These crew traje the trajectories that keep them separate.

56:35 Like sure, if you want to have a principal I see product manager like they do in A lot of large Silicon Valley companies. Perfect. Like let people keep working on those things. They don't have to go into management. But that

56:47 Doesn't mean they're different. between a I C product owner and an I C product manager shouldn't be different there. Perfect segue to where I wanted to go next, which is Say you are a product owner today, listening to this, and you're like, Man, the sound, this is exactly my life. What can I do?

57:04 What's your advice to folks in that role right now about how to potentially become product managers, build the skills they need to be? To not just be stuck in this career path that doesn't go anywhere. Yeah, I think the first thing is bringing awareness to that your role is more than just working with the developers. A lot of leaders argue with me that we need product owners because it just doesn't scale.

57:25 That I've seen. You've seen. massive companies at scale. Like. They don't have any product owners, so I I don't know.

57:32 Do not understand that it's a it's a weak argument to me. It's a very weak argument. It just means You don't know how to distribute the work evenly and give a little bit of strategic guidance to product owners so that they can go or product managers, right? on a team so that they can go And build visions and cut down features and stuff like that.

57:49 If you're a product owner and you're like, Hey, I don't have the opportunity to talk to customers, my product manager does that. I'm just working with the teams. I wanna be more strategic. I wanna think longer term. I'd say Try to take some ownership over that and push back. on the things that are being given to you.

58:04 I was doing a workshop for mine the product like back in the day and I had a product owner in my workshop. And she said, I don't think that things were working on they were doing safe. Are the right things to work on. And I said, You should bring this to your your manager. And she he she was like, I don't know, I'm gonna get fired. I don't think it's the right thing. What am I gonna work on if we're not gonna work on this? And I'm like, Well, this is the beauty of

58:24 product instead of project, right? We we stay with the product. Just because your project ends doesn't mean that you lose a job. So she put together this whole thing, went and said, I don't think we should be working on this. And they promoted her. So they were like

58:37 Fantastic, right? So she took this leap of faith. And went out there and started Saying this is more, we need to do more. I think if you're a product owner and there's no career path for you.

58:47 Start asking leaders what your career path is. Because it's gonna make them go oh. Great question. Like, what should the career path be? And there's a lot of literature out there about how we make career paths. So You can start there, right? Ask what's next for you after this product owner role. I would ask the product managers if you if they're doing all the customer research.

59:06 See if you can do some customer research with them. Right. Go sit in on it. And a lot of them will say, Oh, I don't have time, I don't have time to do this. Strip back.

59:14 all the user stories you're working on, stop thinking about it as a quantitative metric that needs to just go up and up. Instead, really think about the value you're delivering with your team. Is this the right thing? And when you talk to leaders and when you present your case

59:27 You say it in a way of Hey, I'm working on X, Y, and Z feature. What's the goal here? When we release this, What do we hope will happen?

59:36 I think that's one of the best questions anybody can ask. if they're worried their company is not focused on outcomes. Right. What do we hope will happen when we release this? What metrics are we gonna change?

59:46 How do we instrument it to make sure that's true? Then we can go back and actually see if it changed. One simple question to get alignment on it. And then you can start to say oh That didn't work or this did work. Great, why did it work?

59:58 And you can open up those conversations. So I'd say There's a lot of things you can do to help move your companies forward. And I have seen in a lot of these organizations too. A groundswell of product owners and product managers saying, Hey

1:00:12 You know, like What's next for me? What's going on? That makes The organizations Go and Figure it out.

1:00:19 I was working with one like fortune ten company not too long ago, they're C Suite. And I've been working with them for a very long time. And they're finally like, Hey, we're gonna codify the product manager. role and we're gonna have it all the way up and down our organization. We're gonna make roles, we're gonna make responsibilities.

1:00:33 To me, that was music to my ears. But the reason they were doing it too is because they noticed there was a lot of churn. in the organization in that role. And they also realize it's a critical role. So they're losing good people.

1:00:46 Because people from the outside are coming. Because they want to work for this great you know, big organization that's doing super well. Like Fantastic. But they get in there and they go, Where's my like

1:00:55 Where's my career path? Right, what am I supposed to do? Where am I supposed to go? So a lot of leaders are out there now realizing like, hey, we do have to get our stuff together. And the only reason they're they're coming to this conclusion as well is because they're looking around, seeing other people doing it.

1:01:09 And they hear it from the teams. Right, they hear it from the product managers. So I don't want people to think like, Hey, I have no power, I'm in a ten thousand person organization. more you bring this up, the more your leaders will respect it'cause they don't want to lose you, right? They don't want to

1:01:23 They don't want to lose good people. So if you want to be great at your job. And you need more support there, like speak up. Right, speak up. At a certain point I do tell people this, if you feel like you can't do great product management in your organization,

1:01:36 try to find another organization. And I know That is hard to say and I I respect like People are tied to. insurances and you know, it's hard to change jobs.

1:01:46 But if you do have the opportunity to look for another organization that does it well. I would go there. I would also say in large corporations too. I've seen certain business lines and certain divisions Do it super well.

1:01:58 And then others not. So if you're in a large corporation, maybe think about Moving internally. Like laterally to a different team. And seeing if you can work there. I'd find the leaders who know what they're doing and

1:02:09 Go work for that. That's usually the best move here. The point you made about how a lot of companies don't have any product owners and have scaled very wide. Just to reinforce that in the data dive that we did on job. job market trends like no tech company has a product owner.

1:02:24 Yeah. Basically. Like no top tech company. And I know y there's an important distinction here. Like these are tech software first, product first businesses where their business is the software they're building. And a lot of the companies we're talking about here are not that. They're like banks and telecoms pharmaceutical companies. So I get that it's like a very different

1:02:41 world, but I think it's important to highlight. Like you can become very big. Like Google has no product owners, as far as they know. Amazon, Microsoft, Netflix, like No company you you've heard of that's a tech company. As a product owner. They have or they're all product managers. They're all product managers. Yeah.

1:02:57 And I I don't want th I don't want people to think that there aren't people who build great software in these large corporations too because there are, right? There's pockets of people who are doing it super, super well. And if you are one of those people who's been pushing the boundaries, doing great work. And your title as a product owner. But I always tell people on your resume if you're looking for your next job so that you're not

1:03:19 Like pushed out, let's say, of these large corporations like a Google or somewhere like that. And that's where you want to work in a tech firm. Make sure you describe how you did your job from a value perspective. Do not talk about your agile cadences.

1:03:33 Get scrum out of there. Right. Talk about what value you brought to the users and what metrics you moved, and that's how your resume should be laid out. 'Cause I do read tons of resumes to hire people. And I and also like chief product officer, same thing.

1:03:46 If I see. immediately like implemented scrum processes across your organization. I'm like, nope, that's not what I need. Right. That's not what I was looking for. I was looking for What are you gonna do to push the strategy? in that part of the organization. What are you gonna do to actually build better products for customers? And then when you get into the interview you talk about.

1:04:02 Well things you did to do that. But You wanna make sure that you're focused on really understanding the customer and translating that into great products. and the outcomes that we were looking for when you do it on your resume. I think that's important.

1:04:15 Okay, I wanna spend more time here'cause this is so important. So this is kind of highlighting here's the difference between a product owner and a product manager. And so if you want to move into product management and become a great PM, if you're product owner today, even if you're not a product owner and just want to get into product management. Can you again just highlight here's like

1:04:32 The big difference and here's the skills that people value most in a PM versus a product owner. Yeah, when I see product owners write out their Um Their resumes.

1:04:43 or describe their job functions, they always approach it from a process standpoint. I prioritize the backlog. I worked with the developers to break down the work. I checked the developer's work and accept did the acceptance criteria. I wrote the user stories. All those functions is what I I see over and over and over again in product owner.

1:04:59 Resume. what you wanna do instead is say I led The We can even do the login API, right?

1:05:07 I led the work around the login API. the problem that I was solving around it was, you know, trying to enhance security. for our login protocols to meet regulatory requirements. I interviewed a bunch of users. I got up to speed on the regulatory requirements. I worked really closely with our legal teams and our compliance teams. To translate that.

1:05:24 into something that was going to secure our bank. And when we launched we were able to meet our compliance, save our bank like couple million dollars and We smoothly transitioned into these new security requirements without disrupting any service for customers for four million customers.

1:05:39 Right. way different story than I prioritized backlog and I I shipped it off to developers. Take it a step further. If you're working on Customer facing things, who are your customers? Did you go out and talk to them?

1:05:50 by by, you know, interfacing with customers and understanding them I was able to solve X, Y, and Z problem with them. which resulted in a measurable amount of X, Y, and Z metric going up. For the business. Right, I I ran this function, I ran this feature, I launched this feature.

1:06:06 I watched it through, I iterated on it. I did the stuff that was needed to make this successful. That's what I want to see on a resume.

1:06:14 So even if we have a product owner title. I'll still read the details and everybody else will too. But I will say there's sometimes a poor connotation when you have that title Fortunately.

1:06:25 Because of the baggage that's associated with agile. So Even just like on resumes, I would say do product owner slash product manager, right? Like in in there, just to let people know. That I

1:06:35 know how to do this and I've been doing this well, right? But if you do that in your bullet points, that shows up as well. There's also this whole concept that we didn't even get into about certifications. And people keep asking me if I want to transition into Product management.

1:06:51 Should I get a certification, an agile certification? I feel like these were bigger. A couple years ago, but They're still big. So if you ever see somebody with a C S PO

1:06:59 on the end of their profile, which you probably have seen on LinkedIn. It's a certified Scrum product owner. Now One thing to remember, and this is

1:07:09 about all agile stuff is like We call it The agile industrial complex. Agile. Coaches and agile trainers. So like uh the whole Scrum team, Scrum dot org, Scrum Inc, safe, everybody.

1:07:22 The way they make their money is through consulting to teach you these processes. And by having people be trained to get these certifications. So they come in and they say, All your people need to be certified Scrum product owners. It's like give me give me twenty five hundred bucks per person.

1:07:37 And then they get a certificate at the end of a two day class. That says they're a certified Scrum product owner. Doesn't necessarily mean they could do the job. Doesn't necessarily mean they could do product management. But let's think about like when we're talking about two and

1:07:50 Should we adop safe in general? Should we adopt these things? Think about how these organizations make money. The selling certifications. Right? course they want more and more people to adopt it. Like that's that's the idea here.

1:08:02 So they're they're selling you this dream that They you you know, all the you just certify all your people and then you can be working on it. So They take all these people, they put'em in two day classes or whatever, and they turn them out and then they say, Go like you're a completely new role. Doesn't work that way, right? Like that's not in the best interest of your company. That's not really what we're looking for here.

1:08:21 And that's why all of this stuff needs to go deeper. So if you've done a CSPO class and you have that certification It may help you get hired, but at another large enterprise that is adopting Scrum and Safe.

1:08:33 Right. That'll probably help you there. If you want to transition into tech and go into the companies that we talk about. They're probably gonna look at that and say, This person doesn't know what they're doing, right? Like this this is not here.

1:08:45 So you if you do know what you're doing and you did that for a reason Because some people need that to get promoted. Some companies actually require it, which is crazy. But like G promoted or be the thing. I have tremendous empathy for that. You're gonna have to do a lot of work explaining in your resumes and stuff as you transition that you know more than that. Right, you're not just a CSPO. You're

1:09:04 with a two day class you have done the work. And that's where all of this building up on your resume. becomes really, really important. It's not just about getting certified. That's why like I I had people ask me, they're like Can you just certify product managers? And I'm like, no, if people take my course, I give them a certificate of completion and it says completion.

1:09:22 So you finished a course. Just like any other course. But I will not certify product managers because I do not think you can Ever say somebody is Prepared.

1:09:32 And able to do their job. From a short class. Right. If now if you are doing there there are some agile agencies That do a lot more training. Where you have different levels.

1:09:44 And what they would do is they would train people. But then they would make them go do work and they had a coach that they worked with. And they go back and forth and they could demonstrate that they could do the work over time to get to the next level. And

1:09:56 Uh, it's almost like the PMP, like the project management certification, where you have to have time. actually doing the job. That's different, right? Like that's a different type of skill, it's a different type of certification, but you see any like CSPOs, it's typically a two day workshop that they went to.

1:10:11 And then got certified. So That's the difference with this. And I would say Be careful. If you are a product owner wanting to be a product manager,

1:10:19 Um just certifications. Like all the large tech organizations I know too, they're not looking for certifications and product management or product ownership to hire people. They're looking for experience.

1:10:30 But the organizations that might not know what they're doing, they are looking for CSPS. Right. They are looking for for that. And then if you're it's required by your organization, you might have to ask like

1:10:42 Do are we all well set up here? To do our best job. Right. Is this the place where I'm gonna learn how to be a better product manager? I also feel bad though for people because it's hard to be a product manager. It's hard to get your foot in the door.

1:10:53 Right. So I I I'm so torn on it because There are organizations that hire people. With the C SPO.

1:11:01 And they require it. So of course if it gets your foot in the door. You know, and it helps you. Do it. But if it's not gonna help you and it's not gonna put you in the career path you want I I I don't think it's worth money.

1:11:14 I think one interesting thread throughout this whole conversation is Rarely is a plug and playish easy solution gonna be the solution the answer to your problem whether it's plug in safe and it's gonna help us build great software. Taking a class, helping you become a great product manager.

1:11:30 Be sceptical. There's no yeah, there's no there's no quick way to doing any of this. Right. There's no fast track. We don't get just skip over all the hard things. Yeah. Bummer.

1:11:41 Yeah. Yeah. One question I wanted to clarify. So when you come into an org and they have product owners, do you Encourage them to get rid of product owner as a title enroll and make them product managers, or do you keep product owners? I say that we should have a hierarchy, right? So

1:11:56 you would have a all product managers on a team would either be a They've been I see. Right, it's an individual contributor. So they're either an associate product manager, and that's if they don't have all the Discovery experience or You know, may maybe they know basic scrum, totally fine. You can be an associate product manager. But if they don't know how to talk to customers

1:12:14 digest what the customers are saying and turn that into a you know, feature direction and a backlog and This is how we're gonna work. All that stuff needs to be in there, right? They don't know how they be sh should be measuring things. You're not quite a product manager yet.

1:12:28 So associate product manager and then product manager and then a senior PM, right? A senior PM can work on a Scrum team as well or a development team. But I do encourage them, I say get rid of these two different titles because it's confusing everybody. I've seen companies, I I hope a lot of people with career paths do. I've seen companies with forty seven different titles for product managers.

1:12:47 Because Somebody in this organization is called like a product associate, and somebody over here is a product manager, and that person is a platform product manager and that person is a platform product owner and this person is an API product owner. Like You know. You can have

1:13:01 Product manager, product senior product manager, all that stuff, but I I would not confuse people with the two different titles of product owner versus product manager. But importantly there's a bar for who is called a product manager because

1:13:17 If you take a product owner, as you've said, and say you're a product manager, they're gonna be a terrible product manager. So your advice is make them an associate PM and then once they reach a certain level, they've graduated to product manager. It depends. So I w I don't say this is a hard and fast rule because there are product owners out there who've been doing their job very well. So just because they have a title of a product owner doesn't mean that somebody can't do the job of a product manager.

1:13:38 There are plenty of people out there. Google just named this because the company names them that and they know what they're doing. So Don't look at that hard and fast. When we do this

1:13:48 We typically will say Everybody's got product owner on their title, change it to product manager. what we would go back and look at was the actual skill set. So when I've come in to work with companies on transformations, what we typically do, the way I get introduced, usually is we come in and

1:14:03 They're looking for some kind of training for all of their product teams. And then we bring in product institute. We do our online training. And then afterwards I work with the organization and I say Now that everybody's been baseline and trained We have to figure out who is going to be a great product manager and who's not.

1:14:17 So there's an awareness. You know what's interesting. Once people figure out what the job's about. A lot of them opt out. So when I did the transformation at Athena Health, we had three hundred sixty five product managers.

1:14:28 Uh and they all had different different titles too, product innovation all all over the place. So we turn them into product managers. We trained everybody, we gave everybody the opportunity to learn, which I think is great. And then we Give them opportunity to practice their skills.

1:14:40 What happened is at the end of the training a lot of people raised their hand and said Oh no no, this is not what I wanted to do. Like I thought it was very different. I did not realize How much You know.

1:14:52 people work it was. I have to go influence these people. I have to do all this stuff. Like This is actually not really what I wanted to do and We found other roles for them that were, you know, what they wanted to do or they decided to leave. And that's that was up to them. We didn't we didn't cut anybody.

1:15:07 But we moved some people into operations because they wanted to be a little more heads down define process, right? Like that was their their thing. We move people into data roles who were good with SQL and were good with data analysis. We move people into user research roles because they wanted to talk to customers. but they didn't want the responsibility and the accountability that came with the product management piece. Because I realized it was so intense. So

1:15:29 I've seen this happen a lot in large organizations. It's like You baseline everybody, you give them the experien you show them what the role is, right? And then you let them go practice it. And then at that point some people will Opt out. And then you have to go back through your people and say, Okay

1:15:43 How do we level set now? Right, who's Who's doing really well. Who's not doing so well. Which teams need to have

1:15:50 More experienced people on it. Because They don't have anybody to learn from. Right. And that's where we would say, Hey, let's hire some I Cs over here. Or a director of product management who can help train these people.

1:16:00 And help them keep growing. Right. And that's been super successful. I've seen people bring in some more directors, scatter them around. And they've leveled up These product owners who were not necessarily doing great product management and now they're doing fantastic. I and I've watched fantastic leaders.

1:16:16 in these organizations that are you know, not software native or doing these transformations, you bring in the right person, you can make Amazing product managers. Like Give'em a year or two and

1:16:26 Completely turn it around. So It's totally possible. It's totally possible to take people and train them and I I firmly believe in that. But you gotta get them exposure to what good looks like.

1:16:36 And if you are in an organization and you cannot see what good looks like anywhere. That's a red flag, right? That's where leaders need to look at their organization and say, Do I have people with these skills? interspersed around so that everybody can start to learn, right? So that everybody can actually be On the uptake of this.

1:16:54 And make sure that we are well balanced. That was an awesome Nuance and addition. So I'm just looking back at all the things we've talked about, we've covered so much ground. kind of a history of

1:17:06 Agile and Scrum and safes and product owners. We've gotten into all kinds of advice on how to be How to do this better as a company leader as a product owner. That's the one thinking about even moving to product management.

1:17:18 Is there anything else that we have not covered that you think might be helpful to Touch on or Wrap up on I think I would tell people to remember that When you look at agile methodologies.

1:17:29 And if you look at it with small agile. what we're really saying there is we wanna be able to move quickly and deliver great value to Two customers. To embrace those principles. You know

1:17:40 you're gonna do well. But if you think of Agile as just like a defined Super Cut and dry process. Where you have to follow every single little step here and there. Like that's not gonna serve you, right? Because you're not getting back into

1:17:53 Why are we doing this? And there are some great agile coaches out there. There are first principle approaches to Doing great. product working doing great. development work, right? They're they're there because they are not just selling scrum. They are there to make people better.

1:18:07 And those agile coaches I think can make great fantastic teams. And I've worked with a lot of them. And I think they are Really there to just make it a better environment for the people who are working and to help the company produce better products, right? Like that's their whole goal.

1:18:21 But then there are people too who are wedded to This is, you know, this is safe and you will do it by the book. This is scrum, you will do it by the book. And I'd be very skeptical of that. Because What's what's the end goal?

1:18:33 Right. What's their end goal? And like I said. A lot of people out there get paid. By certifying people and by consulting on these processes, right? McKinsey. made a huge division to do this.

1:18:44 And a lot of Safe was actually introduced to organizations from McKinsey and from large organizations. Consulting organizations like that. They came in and they said Yeah.

1:18:53 This is what you do. I'll teach you how to do safe. I'll teach you how to do scrum. And they have been building those consulting agencies off of agile transformations. And We always laugh, like when I talk to other people who've been doing transformations and coaches, they say

1:19:08 I go, why, you know, why is McKinsey always coming in here and doing this? And I've followed them into so many organizations and I've been like, Oh wow, they screwed this up. Like, let me go fix it. And There's always a saying that Nobody gets fired for hiring McKinsey. So

1:19:22 Kinsey's big, people trust their name. A lot of the people at McKinsey haven't done this before. Right. They never They've never been inside the organization trying to transform it. And stay there for a long time.

1:19:33 And that's why I'd be really skeptical of who's selling that. So If you approach agile from a perspective of I want to be agile because I want to release things quickly and get feedback from customers, And make sure that that's great. look at all of your processes like that and say, is that serving the best interest of our company?

1:19:51 And are And our culture and our customers. Right, is this making our customers proud of us, right? Is this helping our customers receive good value.

1:20:01 And if your processes aren't. Fix them. Right, change them, inspect and adapt. is a lowercase agile. Principle.

1:20:09 So we should be looking at every process we do. And saying, Is it working? And not be afraid to change it. And I think it's important to highlight this can work. There are ways to

1:20:20 reorganize the way you build product at a very large company where you can actually deliver Great product consistently. You've seen that happen a lot. Anything you want to add? There to give people uh hope. Yeah, I mean

1:20:31 W the the biggest pushback I hear from large organizations, especially ones that are not software native. as banks or insurance companies, whatever it is. Is that we're not like Google. We're not like SaaS companies. And it's true, you're not a SaaS company. So

1:20:45 The way that you do it is gonna be slightly different. than the way that Amazon runs or the way that Google runs. seen many companies actually run the same. Right. And just because it works at Google doesn't mean it's gonna work at An insurance company that's hundred years old, right?

1:21:00 That's okay. But you could still learn From people who've been producing software at scale. For sure. For many, many years, right?

1:21:09 You can still learn. what makes them successful and then you could take some of those uh principles and apply them to your organization. And then figure out where we need to adapt. And that's what I would look at. Right.

1:21:21 I see software strategies and digital strategies. becoming so intertwined into the strategies of companies. in general, whether you're an insurance company or a bank or anything. Right.

1:21:32 They were becoming so heavily entwined that in the C suite strategies. And the first thing I would say and where I see a lot of companies struggle with this is You have to make sure that it is thought of at the C suite.

1:21:45 And what some organizations do is go, Oh no, that's like IT work. Let me push all the software strategy down. And if you're doing that, you're missing out on innovation. Right. And this is where the product role comes in and where I think More organizations me chief product officers because they're the person in the C suite saying

1:22:01 How can software enable us to be ten times better and crush our competition, whether we're a bank or insurance company or a pharmaceutical company. Like What can we do with our software? that's gonna put us ahead of the competition, that's gonna put us ahead of the market. And if you're not

1:22:17 Having those conversations when you're thinking of your long term company strategy. You're behind. Right, you're behind.'Cause that is what every small, high growth startup is doing.

1:22:27 that's coming out to try to disrupt these big companies. And I I think the big companies are successful. They have a lot of money. So they don't have as much urgency. as sometimes these these smaller companies do to change or somebody who's failing to change. So that's why things are going so slow. But at the same time, if we don't pay attention to that and we're not considering it That's where the danger comes in.

1:22:46 I imagine people are gonna have a lot of questions and Hopefully. to get even more advice. So a couple of final questions. Where can folks find you a line if they want to Ask more questions along these lines, maybe get your help on some of this stuff.

1:22:59 And then finally, how can listeners be useful to you, Melissa? You can find me on LinkedIn. So if you go search for Melissa Perry with an I P E R R I. Uh you'll find me there. My LinkedIn is slash Melissa Jean Perry. Um happy to connect with people there.

1:23:12 My school's called Product Institute. So if you're interested in doing product management training or getting help with some of the stuff. go to productinstitute dot com and reach out to me. And then uh I run a Podcast two. Called the Product Thinking Podcast. So we answer questions every week, and a lot of them are around safe and agile on all these topics so if you have a question and you're saying, hey,

1:23:31 How do I do this? Definitely reach out and let me know. Awesome. Melissa, I learned a lot. I feel like a lot of people listen to this podcast are like I had no idea about any of this. And now I understand all these terms that I kind of hear occasionally. So

1:23:44 Thank you for coming and sharing all of this with us and especially the advice for folks that are in this world right now. Yeah, thanks for having me. By everyone. I Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app.

1:24:02 Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show. at Lenny's podcast dot com. See you in the next episode.

What you see above is a preview of the first minutes. One unlock costs 10 credits and covers this episode forever: full segment and word-level timestamps on this page, plus .txt, .srt, .vtt and word-level JSON downloads, as many times as you like.