How to close the gap between discovery and delivery | Jenny Martin (The Collaboration Coach & Author of OOPSI)

Randy Silver 0:00

Hey, welcome back to the product experience. I'm Randy Silver, and if you're like me, then every conversation you've been having lately is about how to do AI development and how to do this and how to do that. And I don't know about you, but I'm kind of sick of it because AI is interesting, it's cool, it's there's lots of good stuff about it, but there's a lot more about the way we work than just the tools themselves. And I'm delighted that we have a wonderful guest today, Jenny Martin, who's got a new book out called Oopsie, which she's going to talk about more in just a moment. And oopsie goes way back to way to more elementary parts of the product development process. So, Jenny, welcome to the podcast. How are you doing today? Good. Thank you very much for having me. So, did I get that right? Is that the the the general tone of of oopsie? Is it more elementary or was did you have a different idea when you were putting this together?

Jenny Martin 0:57

So kind of. I guess I didn't really have any idea when I was putting it together. I came up with it about 10 years ago, and um it was really for me just kind of making sense of different things. It's nothing kind of brand new, but making sense of all of the best stuff that I valued in terms of product delivery, engineering practices, test-driven approaches, lean stuff, uh, but without the kind of ceremony and the uh and all of the really prescriptive stuff. So yeah, I didn't I didn't really have it a thing in mind. I just started doing it.

Randy Silver 1:34

And you know, we skipped over one really important thing because I've known you for years and years. We keep seeing each other at conferences, and strangely enough, I think we almost always get programmed to do things at the same time. So I see you at conferences running Lego series play uh sessions and other cool things, and I've never gotten to join in one, but we get to hang out and have a drink, and uh I don't think everyone on the podcast has had that pleasure. So let's do a quick introduction. So you you call yourself the collaboration coach. Tell us a little bit more about that. How did you get into all this and and what do you do these days?

Jenny Martin 2:09

So, yeah, I I guess I've called myself the collaboration coach for about 10 years, but most of my background is in um product and software delivery. So was doing that for like 25 years, leading big software development teams. And then I set up my own company in about 2011, and that was focusing on, I guess I was all always drawn to the really collaborative practices of software development. So that was about training, workshop design and facilitation and design thinking kind of stuff. And so I've been training in product development since then, so I guess 15 years. And I guess over the last five or six years, I've been really focusing on the people side of things, you know, the the psychological safety, the learning design, facilitation, all of that kind of thing, which is where the collaboration coach and the Lego series play and the non-violent communication come in. But my roots are in, you know, delivery. So I work at all ends, I work at the peeply end, and then I work at more at the sharp end. And the book is that's where the book is. I've kind of gone back to the sharpering things, if that makes sense.

Randy Silver 3:26

Absolutely. And that was something that I noticed when I was reading the book in the over the last few days. Uh, as compared to a lot of the other things that are out there, the framework that you've put together does feel much more heavily weighted on delivery. So let's come back to that in a moment. And so oopsie itself focuses on on five things it's outcomes, outputs, process, scenarios, and inputs. And we'll go through all that in a few minutes. But why oopsie? Why this approach, what what was the problem that when you put this together as your mental model and started talking about it? What was the problem you were trying to solve by communicating this?

Jenny Martin 4:04

So, first of all, I wasn't trying to communicate it when I came up with it. It was more about keeping teams aligned on outcomes. So, you know, working in the software space quite often, folks are furiously building things without quite knowing why. Um, and so it was it was very much focused on the outcomes and it was influenced, informed heavily by practices around behaviour-driven development and work that that a guy called Chris Matz was doing. I don't know if you know Chris from kind of he was really all over the scene kind of 15 years ago. And this is kind of starting from the outside in, so that's where the outputs process comes in. So starting from the outside, focusing on the outcome. But I guess the problem it was trying to solve was trying to do trying to balance the right amount of thinking with virginity. So, how do you do enough thinking and enough collaboration at the right time so you're building the right thing, but without getting paralyzed by analysis and all that bad upfront stuff that came with the the waterfall days, which I'm old enough to have properly lived through. Um so yeah, it was it was balancing, it was balancing those things. So when when I kind of trended to explain it to you, it's the oopsie is is um it's a navigation tool when you're looking at something big and messy, but it's also a tool for helping you break things down or know that they're small enough to start focusing on. So for me, it was joining up the dots. The problem it was solving was joining up the dots between other good practices in a way that the team could be really concretely working on something, doing the right amount of thinking. That's a long answer.

Randy Silver 5:52

No, not at all. And I like the the the way you're talking about. Then there's a metaphor that you use early on in the book, uh, and it really resonated with me, but it might be because I'm of a certain age as well. And use the video game asteroids uh as a key metaphor for this. And just explain what why asteroids, what did you mean by that?

Jenny Martin 6:13

So this it's not my analogy. I I've borrowed it. So I first saw it in Jeff Patman's story mapping book, but he got it from someone else. He got it from a guy called uh NJ, Michael James, who I managed to track down and I asked him, is this your analogy? And he said, Yes, he he's 66.66 repairing percent sure because there were three of them, it's probably him. So that was his answer, but it kind of explains the way that you well, that you navigate complexity and that you do analysis in an iterative context. So the metaphor is if you're as old as me, maybe as old as you, I don't know, and you remember the arcade game asteroids. For me, it was meteors because I played it on my BBC Basics, so it was like branded, but my hands go into the into the shift up and down left and right. But you're basically trying to clear the screen and blow up all the asteroids and get to the next level so you can level up, and you start with these really slow-moving asteroids that are chugging around the screen. Big chunks, and you'll yeah, and they're going it they're kind of going slow noise, and you're the little prony triangular spaceship, and you're kind of trying to blow it up. When you blow it up, it moves, it it breaks into faster moving pieces. So they're kind of do-do-do-do. And then if you blow one of those up, then they're in really tiny, fast, fast ones. And so if you were to just indiscriminately like fire, fire, fire, and blast all the asteroids up, you'd have millions of these tiny ones flying about the screen and you'd just get squished. And so the metaphor there is that if you think about the the meaning of the word analysis, which is breaking down, um, you know, if you think about brainstorming user stories or all the old in the olden days, writing that 700-page functional specification, that's equivalent to breaking everything down all at once and being overwhelmed by it and the complexity. So, in an iterative, successful agile or product team, you want to be able to clear up after yourself. So, so the idea is that you you leave big asteroids unexplored. And if you do that, you've got a chance of surviving because they continue to move slowly and you can move around them. Uh, so if you just blow up one of those big asteroids and then kind of mine it for all its bits, then you can much more deliberately clear the screen. And so that's what the analogy is. It's kind of trying to capture this sort of iterative moving in and moving out. So it's not just design thinking, it's multiple layers of design thinking as you examine and then come back up again and then examine again. And it's the first, so it's the first kind of analogy that has properly clicked for me. So yeah, I book I've blurred it for the book.

Randy Silver 9:16

It it worked really, really well. And one of the things that really clicked for me uh and that we talked about a a few moments ago was the idea that the book is in the framework is very delivery focused. Uh, and that feels different than a lot of the other frameworks that I work with, a lot of the people I've talked to about these things, where a lot of time we're focusing on making sure we're solving the right problem, on problem definition, on success metrics and things like that, but not so much on the second half of it, the second 80% of actually delivering value into production. And we say it's about outcomes over outputs. We say we want to focus on that, but so much of the work that we do is about the storytelling and not the actual delivery element, at least not for product managers. Uh, and the best product managers are either ones who have that ability to focus on delivery as well, or make sure that they've got a great delivery manager by their side who and a great engineering lead to make sure that this is happening. But I'm curious with your background, is was this focus on delivery really deliberate? Or is this something that uh helped distinguish why you put this together rather than using some of the existing approaches?

Jenny Martin 10:31

I find that question interesting because I don't think of it as a delivery thing. I think of it as a as a joining up of discovery and delivery. So one of the things with it is that it brings together product, engineering, you know, design folks into the same conversations. And that's a gap that I've seen for for 20 years, I guess. And so when I was started doing this stuff, it was sort of pre-product. So product wasn't even a thing at the time, and I was always motivated by starting the team off, focusing on on the why and the purpose and the outcome. So I always I was probably um not a normal thing for a delivery person to be very focused on the outcomes, but uh, but I kind of uh I could see how much difference it made to people's decision making and motivation when we all spent time on that, if you kind of get what I mean. And so Boopsy makes sure that the engineering practices are joined up to the product thinking and the outcome-based thinking. And it's it's exactly that, it's exactly bringing those things together so that everybody's working on the right thing. Because it's one of the biggest problems that I see. Well, you know, you mentioned my um Lego series play. So I do this uh activity in my training that I've been doing for years, where where I get everybody at the beginning, at the beginning of this three-day training to say, build a plane in your product teams, like build a Lego model that represents some kind of pain. And a really common metaphor that people use is uh a customer or stakeholder up on a huge pillar with a with a microphone and a crown. So that's a really universal thing, and then and and normally facing the wrong way, and the other thing that people build is um a big wall with engineering teams on one side and product teams on the other, or business representatives on the other, and then they often build um an idea of what business and product folks want over here, and then a completely different mess over here, and so those kind of um problems are universal, and and folks from different teams, you know, different industries have been building those that same problem, you know, for as long as I've been doing LEGO Series Play, certainly, which is 10 years. So it's a kind of attempt to bring those things together.

Randy Silver 13:09

Yeah, I don't I don't think uh if I came across how saying this is purely a delivery framework, that's that's not what I meant to say. It's the fact that most of the other ones don't uh include the such an emphasis on it as well. So this feels more complete that it's got the focus on the what is it we should be doing and why are we doing it, but it also completes the loop and has the delivery element that I'm not always seeing in some of the other things, or it doesn't feel as prevalent. Um yes, yeah. So before we get into the framework itself, I'm just curious about uh how you actually use this. A lot of the examples in the book are feel like they're at specific product team levels. So, you know, one team or maybe a couple of squads working together. So is that where you usually employ this, or is it a higher level planning exercise, uh coordination exercise across uh maybe a division or an entire company as well?

Jenny Martin 14:11

The the answer to that, I'm really sorry, is it depends. It it depends on your it depends on your starting point, right? So the thing it's it's like I was talking about with the boulders, the the thing with analysis is that the lens that you start with can be any level. So it could be a really big, could be a really big thing, in which case um oopsie is more kind of in the large, like navigating the asteroids. Or it could be um, and this is like some how some folks have been using it already for the last sort of five or six years, is it could be more at the um delivery end where somebody takes something off the backlog. And in that case, oopsie helps you split stories or it helps you have the right conversations. But because of the nature of it, you could either be taking the pen in a room just and stealthily saying to a stakeholder, tell me about tell me about the outcomes, okay, tell me about the outputs. It could be as as light as a conversation structure, or it could strategically help you uh deliver an entire big initiative or portfolio of initiatives. So you can because it's analysis, it's starting with breaking down and exploring, it can it can start at any at any point. And I'll go into that in the book. Um I have a mirror board uh a mirror verse template as well, which shows a kind of in the small and an in the large example.

Randy Silver 15:46

Fantastic. Okay, we'll definitely put a link to that in the show notes. Um let's let's go through each of the stages of this, each word of this. So the the first one is uh the O for outcomes. And this is gonna sound really dumb, but I want to hear what your definition of an outcome is because there's so many times, I can't count the number of times I've worked with companies, worked with people, where their definition is a number on a spreadsheet. We want to get to 100 million ARR or something, something like that. What do you count as a good definition of an outcome?

Jenny Martin 16:21

So for me, an outcome is a change in the world. It's it's a change, a benefit, something that has got better, faster, less friction, more is a word that has a has a change associated with it. So yeah, uh a meaningful change in the real world that that creates value for somebody, for more definition of an outcome.

Randy Silver 16:48

And specifically, is there an anchor there? Is it who are you trying to create value for? Is it the value for the company? Is it value for the customer? Is it mutual value? Uh is there a right and a wrong for that?

Jenny Martin 17:04

So typically it would be value for a customer, could be an internal customer or an external customer. Yeah, so that's the that's the same framing, the same way that you would start in the product space when you're looking at um opportunities. Um and so it's it's very much influenced by because of what I was saying before, Haran, so Teresa Torres's prioritize opportunities over solutions, it's kind of taking that bit of product thinking at the beginning and hooking it into the lower-level engineering practices.

Randy Silver 17:37

Yeah, like I said, this is incredibly basic, but the fact is, there are so many times I go into places and they're missing this as the most basic element. Is it is that something you see commonly or yeah, yes, totally.

Jenny Martin 17:51

So, and and it's actually when I'm when I'm talking about um IPSI and I'm in a room, the first thing I ask the audience is what do you think the difference is between an outcome and a deliverable, or an outcome and an output? And and there's always different answers in the in the room. And it can be quite a so that change to outcome-based thinking, I think, is really important. And and in the various environments that I've worked in when I've been trying to make these kinds of changes, it, you know, it might not be that I'm in there implementing oopsie, but I'm trying to get there, you know, trying to get them working better together and with better outcomes and accelerated delivery. The first thing is for me is about getting people to think in outcome-based language, think about outcomes. So people you have to keep, keep, keep reinforcing it, reinforcing it, reinforcing it. Um yeah, and oopsy doesn't really care how you do that, how you explore outcomes and how you prioritize them and how you define them, just that you do it with focus.

Randy Silver 18:56

And a number on a on a spreadsheet is not the outcome uh in in and of itself. It's that's never going to be the answer.

Jenny Martin 19:04

No, I mean it might be a chain of whys that where there's a number involved in it, someone. But um yeah, it's being able to join up the work through all the levels of the whys to attach the the customer outcome, the change in the real world, and also uh have an understanding of how that impacts the business KPIs as well. So you would you would want to understand how how this customer level outcome is is affecting the bottom line, how you know what what the things that you're going to measure that make sure that you're doing that work.

Randy Silver 19:37

Okay. So going to the next level, that's that's outputs. Um, and you're using that to help focus the team on what are the things that they actually need to accomplish to to achieve that outcome for the customer. But how many outputs do you try and focus them on? Are you trying to do just the most common scenarios, or are you looking at edge cases and the full the full uh sweep of things? Or how do you balance this?

Jenny Martin 20:04

So each layer of oopsie is an opportunity to prioritize. So, you know, I believe in in the the Parito principle at play. So kind of, you know, you you might have a load of different outcomes that you want to you want to explore, but there's going to be kind of 20% of those that deliver 80% of the output, of the impact, not the output. Same is true at the level of output. So this is quite this is quite unique to oopsie is the outputs level, and is it can be where people trip up. So by outputs, I mean the not the outputs of the process, of the software delivery process, or or the things that the that the developers are doing or that the team are doing, it's the the things that you verify that are happening as part of the product or system along the way that deliver the outcomes. So, for example, if you were implementing a an ERP system, a really important output would be a pay slip. Or a really important output would be that the bank balance is updated. And so when you collaborate around those and explore them and look for them, you can see this is the systems thinking part that informs oopsie, that there's real value there in those things that that you can interrogate as a customer or a user, or or they're an important part of the system's behavior that you know that it's working. So when you when you hunt for outputs, you find valuable things. And to answer your question, 20% of the potential outputs that you could produce probably deliver about 80% of the value. So depending on how big and complex the thing is, and how you want to use oopsie. You might be doing something very new and you might be very uncertain about it, in which case you'd look for a really small number of important outputs to get started. If you were doing something that you'd done before, you'd done it loads, it was well understood, you're making some changes, you might take a lot because you already understand them. So it depends how you're using Oopsy and the complexity of the space, whether you're probing and prototyping or whether you're getting on with something that's well understood.

Randy Silver 22:35

And it sounds like this is the level where you'd use a lot of the prioritization tools or impact mapping and things like that in conjunction with it to help decide. It also sounds like this is something that really works well based on top of uh what Jeff Patton does with story mapping, and this is almost the chapter headings or a certain level of uh of uh visibility for of the tasks.

Jenny Martin 23:02

Yeah, so it it oopsie has got those things embedded into it. So at the outputs layer, at the outputs layer, that's when you break them down into opening game, mid-game, and end game, like in Jeff Patton's story mapping. And if you do it with oopsie, you actually avoid a load of the rework and the waste. So it's is like pre-story mapping. We don't need to do story mapping because the oopsie kind of takes takes care of it. So yeah, it's like story mapping with um outputs, it makes sure that each horizon of value, if you're using it to navigate something big and complex, each horizon of value tells a complete story that you're kind of growing over time, if that makes sense. It's hard to explain in a few minutes, isn't it?

Randy Silver 23:52

It is, but it's also it makes perfect sense in terms of concept-wise, but it as always the trick is in the details of implementation, but yeah, relating it back to these tools that that many of us have used before, it it does make a lot of sense. Okay, so the thing that uh that levels up into outputs are the processes. And process is one of those words that can mean a lot of different things. And when I first look at it uh before I read the the chapter, I was thinking, is this the software development process? So let's talk about what you mean by process in this case.

Jenny Martin 24:30

So by process in this case, I mean the interactions that the the customer or the user of the product would have in order to generate the output. So one of the worked examples in the book is a shopping app. And one of the outputs of a shopping app might be the search results that you see on the screen that the user sees on the screen. And that's an important output for the user to see because it's it's saying, Okay, I'm gonna make a decision now about what I put in my basket. So a search results as an output is important. The process would be open your mobile app, uh type search for a product, receive the search results. Do you sort of mean so that the the process is the set of interactions that generate the output? If it if it was a back-end system without that much user interaction, there might be a number of process steps and then the output. So it might be in your ERP system, there might be run payroll, um, evaluate uh tax rules, um, check to see if Jenny's paying a pension. There might be a whole load of number of different processes, and then here's the pay slip.

Randy Silver 25:53

If I want if I wanted to relate that back to to uh the agile process, this feels very much like the story level of what we're doing. Is that a fair analogy?

Jenny Martin 26:05

It's a very it's an absolutely fair analogy. So that's where the thing is looking most like a user story. And this is one of the things, one of the reasons that oopsie came about, because the problem with user stories is that you don't know what level of detail they're at when you look at them. And so it could be much too big. And oopsie helps you split it down until you've got those discrete process steps, and then each one of those is useful as a user story. But because you've come at it through outcomes and outputs, there's some really big meteors, asteroids that you haven't explored, and now you're getting to the now, you're getting to a level of detail where you can actually build something that works and test it and prototype it without having explored everything. So it's exactly that. Then and what in fact, one of the ways of story splitting is by process. Another way of story splitting is sometimes referred to by outputs. So it's so oopsy is like enforcing that breaking down in good practice so that you end up with something that's a nice vertical slice.

Randy Silver 27:18

I love how you're talking about this as I was reading and as we've talked in the past, this is not a new thing. This is just a refinement of existing practices so that you're doing it in terms of best practice, uh following the way it was always intended to be done. But a lot of us slip up along the way, we drift and we we lose sight at times. So this is uh just helping to uh enforce better ways of doing it.

Jenny Martin 27:46

Yeah, that's exactly it. It enforces principles. So with other frameworks, you could be doing all of the ceremonies, right? You could be having your daily stand-ups, you could be using Jira, you could be, you know, creating your backlogs in a certain way, you could be having all of these uh ceremonies and all of this mechanics, and still not know what you're working on, and still not know how to get started quickly, and still not how to split work up in a way that gets you started and gets the and enforces the feedback loop. So I was really frustrated by all of that kind of religious, agile with no without any conversations about outcome or value. I found that really enormously frustrating. And so um, yeah, oopsie. If you follow oopsie, you can't miss those principles because it's embedded into it, but it's still flexible enough for you to apply it in any environment.

Randy Silver 28:44

Okay, so we've hit oop. Uh, let's get moved on to C. And so the the uh the SNC is scenarios, and that is uh a lens that you're seeing this through. But one of the things that struck me about this is you talk about how it's related to behavior-driven development and things like that. What is the difference between what you're talking about scenarios and what everyone else is talking about these days as evals for for AI-driven product development? Is there fundamentally any difference there?

Jenny Martin 29:16

So I I see a difference. I mean, they're both they're both of our kind of testing, right? So Boopsi is trying to use specification by example and BDD practices to bring forward thinking around detailed examples and tests so that you get it right at the first time. So conversations about examples, conversations about concrete examples that help you do the right thing and consider the complexity with with uh collaboration where it's needed. So where that's needed. Oopsie kind of gets you to do that, which is TDD, BDD, Pad informed stuff. And evals uh in terms of AI uh includes all sorts of checks and evaluations and criteria that you could say are tests. They often are happening after the event, but you could use those evals to inform development as well. So I guess the thing is that the way I see it is mostly when we're thinking about e-valves, we're talking about thinking more about ways of testing and evaluating more qualitative type procedure. So, for example, to deal with how empathetic a response is or whether the language was useful or not, because AI always comes out with a different answer, there has to be uh ranges and scorings and things like that for happening. Um, in terms of the scenario chance and the influence of BDG in the specification by example, is particularly useful when it's more quantitable. So, where you know the thing that can't have a range, like the the amount of your pain right in in the ERP scenario, there's there's not like kind of range of suitable answers for that. It's like either right or wrong, and it so that's where it's the expected result that says, and this is what you expect, and so in that way, AI Evals could benefit from that a lot because you know there's some evaluations are qualitative and we care about scoring and how confident we are in the the answer. But the really, really important stuff will be in that concrete uh quantitative data. So that's where kind of that's where the S of boop C comes from. Mostly talking about data-rich logical systems that you can define in advance.

Randy Silver 31:58

So they're it has to do when it's deterministic in or non-deterministic. And yes, yeah, so you need to use the evals when it's non-deterministic, but you're trying to put something uh um determinant uh deterministic ranges around non-deterministic outcomes, which is probably a terrible way of saying it, but I think we we know what we're trying we're trying to say there.

Jenny Martin 32:22

Yeah, yeah, we do. And and Ipsy um you know, defining all of those test conditions up front wouldn't be beneficial in that scenario, right? If for for that type of eval. And so, and so yeah, you you would, I guess, use a mixture of eval-based ARI tests and the best part of um.

Randy Silver 32:48

Makes sense. Um, so okay, so the last one is inputs. And we talk about outputs and outcomes and things like that all the time uh in my world, but inputs less so. So, again, what do you mean by inputs here? What's the what's the secret sauce?

Jenny Martin 33:06

So um by inputs, I mean the concrete test data that normally comes with a test. And so testers will be familiar with this when I talk about specification by example, because often we leave things really ambiguous, and uh because we're we're kind of abstracting the rule of whatever it is that we're building, and that that might exist in an acceptance test, some kind of um user story acceptance test. But oopsie encourages you to actually collaborate around the specific input data and preconditions that may need to be arranged to make the thing work as expected. And from it, so in my early years, I was a tester and a test consultant and a test manager and just have that lived experience of all the assumptions around the really ambiguous requirements documents, and then it's only when you get to use realistic data and try something that you realize nobody's thought of a whole load of things or made massive assumptions about the structure of the data that's being used to drive uh the test. So it sounds like a lot of it sounds like um a lot of detail, but it's it's not somebody always has to do the thinking. And if you if you choose, if you choose important examples, you know, using this kind of hunt the value sort of lens that we've applied at all the different layers, uh, then then this bit of collaboration around exactly what this functional test might look like gives you a really clear target for development. So you're kind of going, it's kind of narrowing right into something very specific.

Randy Silver 34:53

I'm gonna go back to what I said earlier. This is the the S and the I, the scenarios and the inputs, talking about the criteria for testing and everything else. A lot of the time when we talk about product world and design world, we talk about falling in love with the problem. And people get very romantic about that, but they're not always falling in love with solving the problem for people, just the possibilities around it. The actual build and delivery of stuff is messy, it is difficult, it is fiddly. And the fact that you're talking about uh all this from the perspective of someone who comes from a testing and building and delivery background, but who also is focused on why are we doing this, who are we trying to impact, what what did they get out of it? I think that's squaring the circle and bringing it all together in a way that a lot of the time we stop at the point of, okay, now we're gonna hand this off to other people to actually ship.

Jenny Martin 35:49

Yeah, exactly. And uh one of the principles of of oopsie about using examples to guide conversations is trying to include those examples at every layer so that you're able to visualize your understanding of what that means. And that's that's why there's lots of illustrations and lots of collaboration. And yeah, and I mean that's how that's how I worked when oopsie was developed. So I, you know, I used to work in a in a startup uh going back kind of 10, 12 years, and we weren't using oopsie per se at that time, but we were building brand new capabilities, totally green field in the retail space. We were defining our APIs and how our product would work, and we were uh we actually defined the exact test data we were going to use in the example, showed it to the customer, big retail customer, and said, if we test this and show you this output, if we do that in a couple of months' time, will that be the right thing? And they they saw an error, a fundamental assumption in in our model, a piece of data which they didn't have available to us, which was wholly fundamental to our understanding. And if we hadn't done that, we would have wasted three or four months' work. And then the other thing is when we were showing we, you know, we're going to produce this type of example, they'd say, Oh, um, but if you use this different example, that would be better because it will help us get confidence in your progress. And so often we assume that there's a too much detail for business folks or too much vision stuff for engineers. But the value of having everybody, just a select number of people, you know, collaborate at key points through the product development process just is really powerful.

Randy Silver 37:43

So, Jenny, this has been fantastic. I think we've got time for for just one more question. And uh it goes back to the the adoption of this, because this is all makes perfect sense. This sounds just elementary and sensible, and I know it is it isn't. Uh so which step or what part of this do you see most teams get wrong or have the most trouble making sure that they're uh doing it well?

Jenny Martin 38:10

I guess with with the oopsie framework itself, the output bit takes a little bit of thinking in terms of the actual output they're seeing rather than a process step. But this the problem in the world, particularly with AI, everybody going fast in the wrong direction is the outcomes, the outcomes thing. So, yeah, the the the outcomes has the biggest impact, I think. The outputs is a really useful uh opportunity to prioritize. But in terms of the implementation, this is the funny thing, is that um I was originally doing this oopsie thing kind of 10 years ago. I was on the BDD conference scene, I I wrote a couple of blogs, I did lots of different um conferences and meetups, and then I got involved in other things. And it was actually um Jeff Patton who who DM'd me and said, my big client in Estates is using Oopsie to underpin their whole development framework. And I was like, what? And at the same time, I heard that it was being used in a big global consultancy and another big, huge tech giant company, and they've just latched onto it because it's easy. And it's it's the thing that stuck with them. So this is why I wrote the book, is because it's been, you know, it hasn't left me alone. So it keeps coming, rearing its head again. And then when I started to, when I started to do some digging, you know, I found that it was being adopted all over the place just from this one book that I'd written.

Randy Silver 39:52

That's fantastic. And I want to encourage you, everyone listening, because I had something like this happen to me this past week where something I'd written a while ago uh that I assumed nobody was using, a couple of people came up to me in the past week and told me they were using it, not at the scale that people were coming back to you and Jeff Patton was not uh DMing me about about my thing. But if you don't assume that just because you're using somebody's framework, that they know about it, definitely drop them a line. It is such a a wonderful thing to hear from people that uh and we're all very open to it. If you can reach out to Jenny if you're using Oopsie, reach out to me if you're using my stuff, reach out to anybody if you're using their stuff, because it is so reassuring, it is so welcome, and it's so it's just a wonderful thing to do.

Jenny Martin 40:42

So yeah, it blew away. Yeah, it really did.

Randy Silver 40:45

Jenny, thank you again so much. This has been fantastic. I love the book, I love the approach, I love how complete it all is. And uh, where can people get the book? Anywhere in any good bookstore or special places?

Jenny Martin 40:58

Um, so it's on Amazon. Um, I think it's on Amazon everywhere. Uh, if you're in the UK, then if you go onto the Oopsie website, which is oopsie.org, um then you can get a copy from me. It's the same price. The the copy from me is slightly better quality. Um that's the only that's the only difference. It's the exact same book. But only in the UK. You can only check it in the UK.

Randy Silver 41:24

Fancy. So, Jenny, thank you again so much. Uh thank you for coming on.

Jenny Martin 41:28

You're welcome. Thanks for having me. The product experience hosts are me, Lily Smith, host by night and chief product officer by day.

Randy Silver 41:37

And me, Randy Silver, also host by night. And I spend my days working with product and leadership teams, helping their teams to do amazing work.

Jenny Martin 41:47

Lou Ran Pratt is our producer, and Luke Smith is our editor.