139: Melissa Perri

Listen to full episode:

Joe Krebs speaks with Melissa Perri about how to use the Agile Kata to overcome "The Build Trap", a topic she wrote a book about in 2018. They talk about Scrum, the role of a Product Owner, all in the context of products and Agile Kata.

Joe has a book “Agile Kata” in the making, if you like to be the first to know when it launches, please visit www.agilekatabook.com.

Transcript:

Agile.FM Radio for the Agile Community.

[00:00:05] Joe Krebs: Thank you for tuning in to another episode of Agile FM and I have here Melissa Perri with me. That is melissaperri. com. She's the author of the book, The Build Trap from 2018. And she just recently in October 23 released another book together with Denise. You have to help me with the last name. Phyllis.

Phyllis, right? Product operations, how successful companies build better products at scale. And that was, I think I mentioned that October 23, so that's brand new. We want to talk today a little bit about our product and a topic I'm super interested in and that is Kata up, but before we do that, welcome to the podcast.

[00:00:43] Melissa Perri: Thanks for having me

[00:00:45] Joe Krebs: Melissa, you are known for your expertise in lean product strategy, user centric product development. You also a COO for Produx labs that is with an X at the end, so not products, it's produx. And I have all the links in the show page that is a product management consultancy, but I want to come back to that book you wrote in 2018, the build trap, because You say companies have a little bit of a dilemma when you wrote this book, because not only did they have to deliver faster, but faster, not only features, but value has anything changed since 2018?

Since the book was released, did the dilemma get bigger, smaller, wider?

[00:01:27] Melissa Perri: I think it got bigger, but we've seen a lot of progress. So I'm happy. I'm happy with the progress we made in the last five years. It's what happened was, I think. A lot of organizations now, we are not fighting the same battles I was fighting 10 years ago, where it's you must go talk to your users.

Not everybody's still talking to your users, but they know they should be, right? Like I don't have to convince them that's a good thing to do. It's just that. Usually politics or systems or something else will get in the way of them actually going to do that. So what I'm observing though is a lot of companies are realizing they're in the build trap.

There's a lot of people in the last five years who made strides to get out of the build trap. But there's still a lot of people who are stuck in it because they're just starting this journey. And the people who started this journey 10 years ago are making great progress. The people who started this journey like last year, they might be, a little more slow to be able to realize all the benefits. But the good thing is I don't think we're arguing about, do we actually need product managers What's the role of it? Should we be talking to our customers? How do we focus on value? Like people know that we should be doing those things. Now the question is, how do we do it?

I

[00:02:34] Joe Krebs: mean, there's still an emphasis based on my experience working with teams on just building features, and there could be like that pressure in an organization off, like releasing more features, but that's really not the goal here. What value do they carry?

And so just want to make sure I get this right in terms of the. The build trap, right?

[00:02:51] Melissa Perri: Yeah, exactly. The build trap is this place where organizations lose track of what value are we producing? And instead they're really focused on outputs instead of the outcomes. So what we're doing is we're measuring our success on things like how many features did we ship?

Did we get everything done in time? Did it go out to our customers? And what happens is a lot of times we're not going back and revisiting. Those things that we released and saying, did they do something for business and for our customers? Did they actually solve a problem? Were they based on a problem?

You see this happening with AI right now, right? There's always these places where we are like, Hey, there's a solution. Let's just implement a solution, but we're not pulling it back into what problem is this actually solving. And I had this conversation even with a CTO I was working with the other day where I was like, he has a whole AI strategy.

I was like what is it, what are you going to do with that AI strategy, right? What problem is it solving? And we're doing a lot of work right now to uncover some customer problems. So I was like, let's pause this for a second, go and cover the problems and then go back and see if AI is a tool that can help us solve those problems in a unique, differentiated way.

And that's how we have to look at. It's keeping the build trap, right? It's being able to really critically think about what we're building and why, and making sure that they go back to solving a need for our customers in a way that's going to scale our business. So it's not about ignoring business opportunities.

So we should always be looking at those. But we have to remember that the way that we achieve business value is by. Solving customer problems in unique differentiated ways,

[00:04:29] Joe Krebs: This is so this is really cool. I'm going to come back to that build trap here in a second, but I do want to go back to Summer of 2022 here for a second.

When I was going to Nashville to the agile 22, which you deliver the keynote. I believe it was a Tuesday or Wednesday, but it was somewhere in the middle of the week. And I remember because I was hanging out in the open jam so that was the first I think after post COVID kind of agile conference, if I'm not mistaken.

And it was quiet, it was very quiet on the open jam floor. A lot of people went to talks and everything, and that drastically changed when you deliver your keynote, because you mentioned the word Kata and I was out in a open jam and I constantly wanted to talk about agile Kata in terms of transformation, business agility, et cetera.

But you related that to. Product and to your talk and after that keynote, obviously the floodgates were open, so to speak to open jam and people came in you were talking about Kata. How do people, and I think that's the question here to the build trap is how can people use the Kata in your opinion, the improvement Kata Michael Rother would popularize in his book, Toyota Kata to overcome that build trap.

[00:05:36] Melissa Perri: I love Toyota kata it because. It makes you really take a step back and consider what you're doing. And it's not like this dogmatic framework that's really prescriptive for a specific moment in time. It can be applied to a lot of things. Like you said, like I actually learned kata. Teaching people Kanban Kata by Håkan Forss, right?

And that's how I was introduced to it. And I had been a product manager for awhile and I was subcontracting for Kevin Bear actually, and Jay Bloom, and they introduced me to Kata and they said, can you help them think through their Kata using their Kanban using Kata? And I looked at it and I, once I started understanding more about Kata, I was like, this is how I approach product management.

And I had been working with, a company called Lean Startup Machine where they taught a very specific approach to MVPs for companies where it was like, first you do a pitch, then you do a concierge experiment, then you may do a Wizard of Oz or something. And there was like a format to it. And it never the structure never sat right for me as a product manager, cause I'm not building a startup.

I was inside of a company because I was like, in certain situations I wouldn't go in this order or I wouldn't do exactly that. And I'm like why doesn't the way that I operate fit into their. And it was having a hard time with it. And I was having a hard time explaining it, how I was thinking to other people.

And when I introduced, when I got introduced to Kata, I was like, Oh my God, this is how I approach my thought process, but I've never had it Kata-fied before. And I do think it's a great, like problem solving framework that helps people solve problems and think about what they need to do and how they might get closer to a goal.

So for me, what I found is that. When I was a product manager I taught it to other people who are around me. I taught it to my team so that we could build better products together and it caught on really well there. And then I started doing it as a consultant and as a teacher, I started teaching people kata to help them with product strategy and to help them with thinking through what they were going to build.

And it kept expanding from there. And why I love teaching it is it's. It's really like a series of questions and it helps you get out of the build trap because it's asking you that critical question of why. And people get stuck in the build trap because they're not thinking about the why behind the features that they're building.

And that's what Kata does. It slows you down for a minute to critically think about. Why are we investing in this? What is it going to do? And what do we expect at the end of the day? And I like even use it in informal settings all the time. Just like some of those key questions with leaders.

So like I go in, I work with a lot of CEOs. I work with a lot of chief product officers and they'll show me their roadmap. They'll show me what they're building and I'll go, okay. What do you think, what is the goal that you're actually working towards, right? What's the outcome that you're trying to achieve?

What do you know about the current state right now? What are the problems about our customers? And sometimes they don't have that answer. So I'm like, okay, let's go do some research, right? Let's now we know what action to take to learn that we can go explore what the problems are. We could go do use the research.

We can get some data. Then we'll come back and then we'll set the next goal. And we get into strategy deployment there, right? Where we're setting a goal. We're trying to go out and do some experimentation around it, trying to learn a little bit more. And what it does is it really helps us learn about our businesses, our customers, our current situation.

And critically thinking through all those things is what. Gets us to consider more options than just whatever solution idea came to your head first. And that's why I love Kata for product management for product strategy and deployment and creation and thinking through all these things, because it's not just about product management, but it's a broad framework that, anybody.

Yeah. Anybody could understand, right? If I ask you, what's the outcome? What do you want to achieve from this? You're gonna, anybody can answer that depending on where you're sitting in this situation. And it's easy to understand, it's easy to grasp and it really helps people stop and start thinking more critically about stuff.

So that's how I use it to help companies get out of the build trap. And even if I'm not going to introduce it in a super formalized way, like I've used it with, I have a Google sheet where I stepped through every part of the Kata when I'm experimenting with stuff and go all the way down. And I have some people I've taught love doing that, but even just the questions and the way that it makes us break down our logic and think about what's next, I think is really impactful for working with anybody in an organization just to get them to learn and deeply consider different things.

[00:10:04] Joe Krebs: Right. I think something very interesting you said was like to slow down for a little bit, right?

[00:10:08] Melissa Perri: Yeah.

[00:10:09] Joe Krebs: and to think and really look at the the situation you are in product development and so many teams and an actual transformation aspect where I use the Kata a lot or business agility same thing, right?

There's a tendency of all we know what the problem is, let's get started. Versus stepping back and say what, where are we right now? And I think that is a probably aspect in a product, but nobody wants to hear that. So it's let's slow down. Everybody's let's get started.

[00:10:33] Melissa Perri: Yeah.

[00:10:34] Joe Krebs: And it is getting started.

[00:10:36] Melissa Perri: Exactly. It is getting started. That's like the best way to put it. One of the big things that I see people don't do is actually evaluate that current state. And that's a huge part of being able to set great product strategy and get out of the build trap. It's and when you go and look at your current state, and we do this with product ops, like in the book I was talking about, a lot of that is helping you get to that current state.

It's about understanding like, what are your users doing now? What kind of customer segments do you serve? Who's using which products, what types of personas are using which products? And you can pull all this information out to get a current landscape of what is my company and my business and my product actually look like today.

And if you don't understand that, it's really hard to figure out. Where you should go in the future, right? It's incredibly hard to set a vision. It's very hard to give direction to teams about where you're going. And the Kata introduces that super nicely in the way that it's laid out so that people don't skip over it.

Cause a lot of times I'll see leaders go and just create a product vision out of thin air. And you're like based on what, right? But how does that relate back to what we're doing now? So it's been a great tool in helping people take that step back. Look at where we are before they actually want to leap forward and make assumptions about where we should go.

[00:11:46] Joe Krebs: This is this is super cool. I do want to ask you something about something that's often connected with cut off thinking and also product development, especially if you're looking. It's a closer at scrum or the role of a product owner. There's a very rhythmic approach through sprints and iterations.

Yes, you could do that with the Kata out. I researched product development companies out there and I think tanks. They don't necessarily work in these fixed iterations, right? So they're working more like ad hoc experimental approach. I just want to hear what your take is and how you would connect that maybe to the world of Scrum, the product owner role, and like just that rhythmic approach iterating over a product backlog.

Versus more like the experimental approach and what do you see out there companies are doing? Probably also a little challenging because sometimes product development starts much earlier before there is a product backlog, right? Or something defined, iterate over. So there might be two steps to it.

[00:12:44] Melissa Perri: Yeah, I have opinions about scrum. So here's where I think a lot of teams get stuck. There is a forcing function that's nice in scrum. Where. You say you need to break this down and make it small. And that's where the two weeks come from, right? So it's that you don't spend six months building a bunch of stuff and never showing it to the world and not getting the feedback.

And I firmly agree with the concept of get things in front of customers early, get some feedback. Now that doesn't need to be get half baked ideas in front of 20, 000 customers early. It just means like sometimes we do these things behind the scenes. Like I'll work with B2B enterprises in healthcare and finance and all these completely regulated businesses.

And what we'll do is we'll try to figure out how to test things with people early on. So we might. Build a small prototype, or we could build a even small subset of features into a product and let people use it in beta testing. So maybe it reaches 10 people, 20 people, we get feedback, and we iterate on that before we go and launch it to everybody else.

To me, That's what scrum is trying to promote is that you get things out and have those feedback loops, but it took on a life of its own. I feel and people got really dogmatic about it, especially with the two week sprints. And I have worked in industries where. It does not take two weeks to actually get something built to be able to show to customers.

So then what are you doing? You're just like giving people arbitrary deadlines and they're sprinting sprinting, but they don't have much to show for it. And again, pure scrum, people would say Oh, they're doing it wrong then. And I agree, but some work just takes longer. And to me, scrum is useful when there's.

unknowns that you have to go test. But if you have to build something and you know it's going to take six weeks and you have concrete data that's the right thing to build go build it. Like, why are we trying to sprint for two weeks into six week cycles? That doesn't make any sense to me.

So a lot of companies out there I think are using Scrum wrong, right? They're not thinking about what do we know, what do we not know about the things that we're building? These known, knowns and the unknowns of the world here. And you want to. In product development, get to a place where you're putting things out quickly and testing it with customers and getting some feedback.

And like I said, you could do that in a small way when you're not sure if the solution you're building is the right thing for the customers and that's the thing that we're testing there. What I see with Kata is it allows for the flexibility of that when you started thinking through it. And when I've used it in practice, we, and I've used it with a lot of teams, I'll say to them, what's the first small step we can take to go learn if somebody actually likes this.

And they might say, we we tried the prototypes. We think they're usably good. Now we have to build it in some small. Like that, that sometimes becomes the assumption we have to test in which case, maybe we get some beta testers. Like we said, we get 20 beta testers and we build it as code.

We release it under a feature flag and we go test it in Kata. You would ask, how long is it going to take to build? That first thing, like when can we go see, right? When can we go see our results? It might be four weeks. It might be five weeks. It might be one week. It might be two weeks, right? There's no, you want to keep thinking about slimming it down as much as you can, but it's not prescriptive about this two week cycle.

And that's why I like approaching things more like that rather than trying to time box it things into two weeks. I think time boxing is nice when you've got a Team that's not used to operating that way and it's a forcing function to get them to think smaller, right? So sometimes I'll ask them. Okay, cool.

That's gonna take eight weeks. Could you do what could you do in two? What could you do in three? But then we'd have a conversation of yeah But if we did that in two we'd only be able to do this much and we wouldn't be able to get This part of it out and that part is really valuable and you're like, okay what about three right and you have that back and forth negotiation on it?

But Scrum doesn't allow for that, right? Like it's nope, everything has to be in two week sprints. In certain forms of how people sprint. That's the part that doesn't sit well with me for Scrum, and where I think people are getting really caught up in the motions, but not thinking about why they're actually doing it.

[00:16:57] Joe Krebs: Yeah. What's interesting, right? Because you also just said that about breaking things down into smaller pieces to make them fit, right? What I have seen in the past was like the teams overreact and these items become so, so small.

[00:17:10] Melissa Perri: Oh yeah. And you don't want it to be too small, right? And that's a big thing too, where I've worked with a ton of teams who've missed Misunderstood what a minimum viable product is.

And I don't even like to use that terminology now because it's just so butchered, but they'll be like, Oh, an MVP is just putting out these core functionality. And you go what are you going to learn when you release that? And that you don't already know now, because sometimes it's like, Oh, all we're going to learn is that it's not enough for people.

They want more. And you're like, so why bother? Like why bother? If you know that's going to be the answer. Spend two more weeks and build something that's actually valuable there. And that's the conversations I think we need to be having when we think about breaking down product development and what's small and what's considered.

And I do believe there's ways to slice things down into smaller chunks where you can get it out there, but it has to be valuable, right? It can't just be small. It has to be valuable.

[00:18:01] Joe Krebs: Exactly. And I feel like that's a key point you're making here is where the Kata, it's almost like when you're talking about what's the next target condition, right?

What is, and then you're talking about some valuable things, like there's a discrepancy between where we are right now and where we would like to be. And there's a value in between, right? And if you're aiming for that, and it could be two weeks, it could be one week, it could be two days or could be four weeks.

So it's not so much about the time, but how fast can we go to that target condition? This is this is really awesome. So I love hearing your thoughts on these topics. And I hope that the listeners out there listening to this from a product management perspective or product owner role. Got some new ideas, the beauty of the Kata and the agile Kata I'm promoting a lot is that people can start anytime.

[00:18:44] Melissa Perri: Yeah. I like that.

[00:18:45] Joe Krebs: If you're listening to this and it's like, how do I. Do this, right? Everything's about experimentation. So why not experimenting with the the kind of approach and and try that and see how it works for you. And possibly make some modifications to it. And maybe the product management process itself could also be Kata-ized.

So I think that would be awesome. Yeah, that's great.

[00:19:04] Melissa Perri: I'd love to see more product managers doing it. I had actually talking to somebody in a couple of days who used it in the government with Congress people. Yeah. Doing product stuff. And I was like, that's cool. So lots of different contexts to do it.

I hope it's a good tool that can help people be better product managers.

[00:19:20] Joe Krebs: Yeah. And thanks for coming to the Kata series of Agile FM where I'm highlighting the multiple use cases of Kata thinking and how it could fit into the professional world out there. So thanks for taking the role on product management.

Thank you, Melissa.

[00:19:35] Melissa Perri: Thanks for having me.