Why good ideas get lost between teams | with Jenny Martin (The Collaboration Coach & Author of OOPSI)

0:00Randy Silver: Is it a goal of yours to make more money in 2026? My name is Travis Chappell and I'm the host of the Travis Makes Money podcast. It's the only podcast on Spotify that brings you two episodes every single day on how to make more money. From side hustlers to real estate investors, brick and mortar owners to online creators, beginners to billionaires, every conversation will give you the ideas, inspiration and practical tools you need to make more money and earn your dream life today. Subscribe right now to the Travis Makes Money podcast on Spotify and I'll catch you over there.

0:31Randy Silver: 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 more elementary parts of the product development process.

1:11So, Jenny, welcome to the podcast.

1:14Randy Silver: How are you doing today? Good. Thank you very much for having me. So did I get that right? Is that the general tone of Oopsie? Is it more elementary or did you have a different idea when you were putting this together? 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 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, but without the kind of ceremony and all of the really prescriptive stuff.

2:01So, yeah, I didn't have a thing in mind. I just started doing it.

2:06Randy Silver: 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 serious play 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 I don't think everyone on the podcast has had that pleasure. So let's do a quick introduction. So you call yourself the collaboration coach. Tell us a little bit more about that. How did you get into all this?

2:38Randy Silver: And what do you do these days? so yeah I guess I've called myself the collaboration coach for about 10 years but most of my background is in 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 always drawn to the really collaborative practices of 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 peopley end and then i work more at the sharp end and the book is that's where the book is i've kind of gone back to the sharp for anything if that makes sense absolutely And that was something that I noticed when I was reading the book over the last few days.

4:03Randy Silver: 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 OOPSY itself focuses on five things. It's outcomes, outputs, process, scenarios, and inputs. And we'll go through all that in a few minutes. But why OOPSY? Why this approach? 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? So, first of all, I wasn't trying to communicate it when I came up with it.

4:40It 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. And so it was it was very much focused on the outcomes. And it was influenced, informed heavily by practices around behavior driven development and work that a guy called Chris Matts 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.

5:17But 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 waterfall days, which I'm old enough to have properly lived through. So, yeah, it was balancing those things. So when I try and start to explain it to you, 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 up.

6:10So 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.

6:24Randy Silver: No, not at all. And I like the way you're talking about it. There's a metaphor that you use early on in the book, and it really resonated with me. But it might be because I'm of a certain age as well. You use the video game asteroids as a key metaphor for this. I said, just explain, why asteroids? What did you mean by that? So this is not my analogy. I've borrowed it. So I first saw it in Jeff Patton's story mapping book, but he got it from someone else. He got it from a guy called NJ, Michael James, who I managed to track down. And I asked him, is this your analogy? And he said, yes, he's 66.66 % sure, because there were three of them, probably him.

7:07So that was his answer. but it kind of it 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 basic so it was like branded but my hands go into the into the shift up and down left 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.

7:47Randy Silver: Big chunks. Yeah. And they're kind of going. It's a slow noise. And you're the little tiny triangular spaceship and you're kind of trying to blow it up. When you blow it up, it moves. 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 guiding 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 product team you want to be able to clear up after yourself So the idea is that you leave big asteroids unexplored.

9:05And if you do that, you've got a chance of surviving because they continue to move slowly and you can move around them. 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 kind of analogy that has properly clicked for me. So yeah, I've got a blurring for the book.

9:48Randy Silver: It worked really, really well. And one of the things that really clicked for me and that we talked about a few moments ago was the idea that the book is in the framework is very delivery focused. 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.

10:25Randy Silver: 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. 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 and a great engineering lead to make sure that this is happening. I'm curious, with your background, was this focus on delivery really deliberate? Is this something that helped distinguish why you put this together rather than using some of the existing approaches? I find that question interesting because I don't think of it as a delivery thing.

11:07I think of it as a joining up of discovery and delivery. So one of the things with it is that it brings together product, engineering, design folks into the same conversations. And that's a gap that I've seen for 20 years, I guess. And so when I 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 was I was probably not a normal thing for a delivery person to be very focused on the outcomes but but I kind of 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 rid of me and so So Boopsy makes sure that the engineering practices are joined up to the product thinking, the outcome based thinking.

12:08And 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. You know, you mentioned my Lego series play. So I do this activity in my training that I've been doing for years where I get everybody at the beginning of this three-day training to say, build a pain in your product teams, like build a Lego model that represents some kind of pain. And a really common metaphor that people use is a customer or stakeholder up on a huge pillar with a microphone and a crown. so that's a really universal thing and then 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 an idea of what business and product folks want over here and then a completely different mess over here and so those kind of 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.

13:41Randy Silver: Yeah, I don't think, if I came across, I was saying this is purely a delivery framework, that's not what I meant to say. It's the fact that most of the other ones don't include 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. Yes. Yeah. So before we get into the framework itself, I'm just curious about how you actually use this. A lot of the examples in the book feel like they're at specific product team levels.

14:27Randy Silver: 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 but the answer to that i'm really sorry is it depends it depends on your it depends on your starting point right so the thing is 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 or 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 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.

16:07I have a Miro board, a Miroverse template as well, which shows a kind of in the small and an in the large example.

16:18Randy Silver: Fantastic. Okay. We'll definitely put a link to that in the show notes. Let's go through each of the stages of this, each word of this. So the first one is the O for outcomes. And this is going to sound really dumb, but I want to hear what your definition of an outcome is because there are 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 like that. What do you count as a good definition of an outcome? For me, an outcome is a change in the world. It's a change, a benefit, something that has got better, faster, less friction, more is a word that has a change associated with it.

17:11So yeah, a meaningful change in the real world that creates value for somebody, for more is the definition of an outcome.

17:20Randy Silver: And specifically, is there an anchor there? 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? is there a right and a wrong for that? So typically it would be value for a customer, could be an internal customer or an external customer. Yeah, so that's the same framing, the same way that you would start in the product space when you're looking at opportunities. And so it's very much influenced by, because of what I was saying beforehand, so Teresa Torres' prioritise opportunities over solutions. is kind of taking that bit of product thinking at the beginning and hooking it into the lower-level engineering practices.

18:09Randy Silver: 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 that something you see commonly? Yeah, yes, totally. And it's actually when I'm talking about OOPSI 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 there's always different answers in the room. And it can be quite a... So that change to outcome-based thinking, I think, is really important. And in the various environments that I've worked in, when I've been trying to make these kinds of changes, it might not be that I'm in there, in the menjoo, oopsie but i'm trying to get that 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 if you have to keep keep keep reinforcing it reinforcing it reinforcing it um yeah and oopsie doesn't really care how you do that how you explore outcomes and how you prioritize them and how you define them just how you do it with focus.

19:28Randy Silver: And a number on a spreadsheet is not the outcome in and of itself. That's never going to be the answer. No, I mean, it might be a chain of whys where there's a number involved in it, someone. But yeah, it's being able to join up the work through all the levels of the whys to attach the customer outcome, the change in the real world, and also have an understanding of how that impacts the business KPIs as well. So you would want to understand how this customer-level outcome is affecting the bottom line, what are the things that you're going to measure that make sure that you're doing that well. Okay, so going to the next level, that's outputs.

20:13Randy Silver: And you're using that to help focus the team on what are the things that they actually need to accomplish 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 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 same is true at the level of output so this is quite this is quite unique to oopsie is the outputs level and it's 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 the things that the developers are doing or that the team are doing.

21:20It's 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 an ERP system, a really important output would be a payslip 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 OOPSY, that there's real value there in those things that you can interrogate as a customer or a user, or they're an important part of the system's behaviour that you know that it's working.

22:08So when you hunt at 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 OOPSY, 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.

22:54So it depends how you're using OOPSI and the complexity of the space, whether you're probing and prototyping or whether you're getting on with something that's well understood.

23:06Randy Silver: And it sounds like this is the level where you 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 what Jeff Patton does with story mapping. And this is almost the chapter headings or a certain level of visibility for of the tasks. yeah so 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 pattern story mapping and if you do it with oopsie you actually avoid a load of the rework and the waste so it 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 up to explain in a few minutes isn't it it is but it's also it makes perfect sense in terms of concept-wise, but as always, the trick is in the details of implementation, but relating it back to these tools that many of us have used before, it does make a lot of sense.

24:39Randy Silver: Okay, so the thing 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 before I read the chapter, I was thinking, is this the software development process? So let's talk about what you mean by process in this case. So by process in this case, I mean the interactions that 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.

25:31And that's an important output for the user to see because it's saying, okay, I'm going to 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, type search for a product, receive the search results. So the process is the set of interactions that generate the output. 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, evaluate tax rules, check to see if Jenny's paying a pension.

26:20There might be a whole load of different processes. And then here's the pay slip.

26:24Randy Silver: If I wanted to relate that back to the agile process, this feels very much like the story level of what we're doing. Is that a fair analogy? it's a very it's a 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.

27:29So it's exactly that. And in fact, one of the ways of story splitting is by process. Another way story splitting is sometimes referred to by outputs. So OOPS is like enforcing that breaking down in good practice so that you end up with something that's a nice vertical slice.

27:49Randy Silver: I love how you're talking about this, because 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, following the way it was always intended to be done. But a lot of us slip up along the way. We drift and we lose sight at times. So this is just helping to enforce better ways of doing it. 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 gira you could be you know creating your backlogs in a certain way you could be having all of these 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 enforces the feedback loop.

28:51So I was really frustrated by all of that kind of religious agile without any conversations about outcome or value. I found that enormously frustrating. And so, yeah, OOPSI, if you follow OOPSI, 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. Okay, so we've hit oop, let's move on to C.

29:20Randy Silver: And so the essence is scenarios. And that is 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 AI-driven product development. Is there fundamentally any difference there? I see a difference. I mean, they're both about kind of testing, right? So Bootsy is trying to use a specification by example and BDD practices to bring forward thinking around detailed examples of tests so that you get it right the first time.

30:05So conversations about examples, conversations about concrete examples that help you do the right thing and consider the complexity with collaboration where it's needed. So where that's needed, OOPSI kind of gets you to do that, which is TDD, BDD, Paragon, Form, stuff. and evals in terms of ai 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 i guess the thing is that the way i see it is mostly when we're thinking about eval we're talking about more about ways of testing and evaluating more qualitative type stuff so for example to deal with how empathetic the response is or whether the language was was useful or not because ai always comes out with a different answer there has to be ranges and scoring and things like that are happening and oopsie in terms of the scenarios part and the occurrence of BDE is best to case with my example is particularly useful when it's more quantitative so where you know the thing that can't have a range like the amount you're paid right in the erp scenario there's there's not that kind of range of suitable answers for that it's like either right or wrong but so that's where it's 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 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 data so so that's where kind of that's where the s of oopsie comes from mostly talking about data-rich logical systems that you can define in advance.

32:32Randy Silver: Yeah, it has to do when it's deterministic or non-deterministic. And yeah, so you need to use the evals when it's non-deterministic, but you're trying to put something deterministic ranges around non-deterministic outcomes, which is probably a terrible way of saying it, but I think we know what we're trying to say there. Yeah, yeah, we do. And OOPSY, you know, defining all of those test conditions up front wouldn't be beneficial in that scenario, right, for that type of eval. And so, yeah, you would, I guess, use a mixture of eval-based AI tests and the best part of OOPSY. 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 what's the secret sauce and by inputs i mean the concrete test data that normally comes with the test and so testers will be familiar with this when I talk about specification by example because often we leave things really ambiguous and because 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 user story acceptance test but OOPSI 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 realise 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 the test.

34:50So it sounds like a lot of detail, but it's not. Somebody always has to do the thinking. And if you choose important examples, you know, using this kind of hunt the value sort of lens that we've apprised at all the different layers, 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 narrowing right into something very specific.

35:24Randy Silver: I'm going to go back to what I said earlier. This is 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 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?

36:05Randy Silver: Who are we trying to impact? 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, OK, now we're going to hand this off to other people to actually ship. Yeah, exactly. and one of the principles 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 i mean that's how that's how i worked when oopsie was developed so you know i used to work in a startup going back kind of 10, 12 years.

36:51And we weren't using OOPSI per se at that time, but we were building brand new capabilities, totally greenfield in the retail space. And we were defining our APIs and how our product would work. And 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 sharing 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.

38:15So Jenny, this has been fantastic.

38:18Randy Silver: I think we've got time for just one more question. And it goes back to the adoption of this, because this is all makes perfect sense. This sounds just elementary and sensible, and I know it isn't. 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 doing it well? I guess with the oopsie framework itself, the outputs bit takes a little bit of thinking in terms of the actual output they're seeing rather than a process there. But the problem in the world, particularly with AI, everybody going fast in the wrong direction is the outcomes, the outcomes thing.

39:04So, yeah, the outcomes has the biggest impact, I think. the outputs is a really useful 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 and 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 pattern who who dm'd me and said my big client in the states 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.

40:03And 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. It keeps coming, rearing its head again. And then when I started to do some digging, you know, I found that it was being adopted all over the place just from this one blog that I'd written.

40:24Randy Silver: 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 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. Jeff Patton was not DMing me 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 wonderful thing to hear from people that, 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.

41:09Randy Silver: It is so welcome. And it's just a wonderful thing to do. Yeah, it blew my way. Yeah, it really blew. 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 where can people get the book? Anywhere in any good bookstore? or special places? So it's on Amazon. I think it's on Amazon everywhere. If you're in the UK, then if you go onto the OOPSY website, which is OOPSY.org, then you can get a copy from me. It's the same price. The copy from me is slightly better quality. That's the only difference. It's the exact same book. But only in the UK.

41:54You can own each of it in the UK.

41:56Randy Silver: Fantastic. Dr. Jenny, thank you again so much. Thank you for coming on. You're welcome. Thanks for having me. The Product Experience hosts are me, Lily Smith, host by night and chief product officer by day. 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. Luron Pratt is our producer and Luke Smith is our editor.