The Anatomy of Product

In this episode of the Scrum.org Community Podcast, host Dave West sits down with authors Sander Dur and Ryan Brook to explore their new book, The Anatomy of a Product—a practical field guide that uses the human body as a metaphor to demystify modern product management.

Dave, Sander, and Ryan dive into why so many organizations still struggle to define and manage products effectively, and how this book helps bridge the gap between theory and real-world practice. They discuss treating products as living systems, the dangers of “marshmallow backlogs,” the need for evidence-driven decisions, and why continuous care and adaptation are essential for healthy products.

The authors share insights from working with organizations like Miro, unpack common “product diseases,” and offer actionable guidance for Product Owners, product teams, and leaders seeking clarity in today’s complex environment.

Listeners are invited to connect with the authors and join them at their book launch event in Amsterdam on January 13!

Key Points

Why the Book?
Clarifies what a product is and offers a practical guide from definition to retirement.
Human Body Metaphor
Products are like living systems—interconnected, adaptive, and influenced by their environment.
Theory vs. Practice
Helps teams apply product concepts realistically, beyond Silicon Valley-style theory.
Insights from real examples
Real-world examples showing how to balance strategy, business thinking, and everyday product work.
Backlog Health
Avoid “marshmallow backlogs” by filtering work through strategic goals and focusing on value.
Validation & Evidence
Emphasizes validating ideas early and aligning efforts to outcomes, not just requirements.
Product Health
Introduces “product diseases” and how to diagnose and prevent common issues.

 Links:
Book Launch event
The Anatomy of a Product

Transcript

 0:00  
Welcome to the scrum.org community Podcast, the podcast from the home of Scrum. In this podcast, agile experts, including professional scrum trainers and other industry thought leaders, share their stories and experiences. We also explore hot topics in our space with thought provoking, challenging, energetic discussions. We hope you enjoy this episode.

Dave West  0:23  
Hello and welcome to the scrum.org community podcast. I'm your host. Dave West CEO, here@scrum.org in today's podcast, we're discussing a recently published book, The Anatomy of a product as you know, you know the particularly for people that have been here a few times I listened to a few podcasts. I'm really into product. I love it. Product is my jam, as all the young people are saying. Now, actually, probably not. And you know, product is a fundamental part of Scrum, so it's always very interesting to talk about any new work in this area. So to discuss this new book, I have the authors. I'm very lucky. They both agreed to come on the podcast. I've got Sander der, professional scrum trainer, fellow podcast hosts. Some of you may have listened to mastering for agility. I've been on that podcast, I think once or twice, awesome podcast. And Ryan Brook, professional scrum trainer, author, founder of opti learn. And actually, I've just got to be honest, I just spent a week with Ryan in Tokyo in Japan, speaking to lots of really cool, interesting companies and actually doing an event there. So apologies if we drop into our sort of like we've just spent a week together moment. But welcome to the podcast. Sanda and Ryan,

Sander Dur  1:43  
thank you for having us. Thanks you. Thank you for having us. Good to be here again.

Dave West  1:47  
It's great to be here. And so a little bit over a year ago, where you were on the podcast talking about your first book, solving for value, which talks about how you build teams and organizations that really focus on value, which is quite hard, or surprisingly hard actually, considering what the purpose of most teams is. So what motivated you to write another book?

Sander Dur  2:15  
Well, it started while, like the idea started when we were writing, solving for value. One of the things that we noticed, both when writing the book, but also in our professional scrum classes, working with our clients, is they often have no idea what a product or what their product really looks like. Is it a component? Is it the entire thing? Should we focus on this specific user, and even there, the stupid consultant answer applies, it depends. It really depends it really depends on perspective, how we want to focus on what is our product. So ultimately, we figured we're going to write a book and try to shine some light on this specific topic, and how to approach this love what is involved and what is not, and how, how to build a product from end to end. Because ultimately, Scrum teams, or product teams, should be accountable from the beginning, from the conception until it's been decommissioned, right? So these were all concepts that were vaguely existing but never really understood by many organizations that we worked with. Ryan, how was that for you?

Ryan Brook  3:12  
Well, the reason we kind of wrote the book is you kind of forced me to sander, no. I mean, in more seriousness, we, we kind of, we do a lot of product consultancy, right? We believe that the people who train kind of product stuff should also be the people consulting. And this kind of tangible idea of product was so poorly or intangibly understood that we wanted to try and make a field guide that kind of talks you through lots of different sections. And so that's what we've tried to produce, using a lovely

Dave West  3:39  
metaphor of the body. And I just want to lean in a little bit about that metaphor. I picked up on this, this metaphor, and it actually meant I spent longer on it, honestly, because it was super interesting, and I loved it. This, this idea that a product is has an anatomy is composed of parts that are dependent on each other, which, if you change one thing you have, it has an impact on another thing. This the idea, a bit like you never really understand it, really, yeah, which is reason why it's called practicing medicine, which I always worry every time I go and see a doctor, but it was really interesting, interesting metaphor. Why did you do that? Why did you use that and anatomy of a product as the sort of like the glue?

Ryan Brook  4:28  
Fundamentally, when we work in products, we just think the word complexity is used all the time, and you've just talked about practicing medicine, there's so much that we still don't understand. You know? We try something, we see what happens, and then we try and hopefully realize a benefit, realize some value when it comes to bodies, we kind of wanted to use this metaphor because it tells a story. There's so many sections that we can all relate to. But also having a metaphor just creates those knowledge hooks for people to be able to go, you know reproduction? Well, actually, reproduction is about scaling a product, right? You know, creating a. Be. Let's not go into that one in too much is a spark of a DNA or creating something new.

Sander Dur  5:04  
I think it's interesting that in professional Scrum, in our class, we always talk about living artifacts, right? Yeah. Interestingly, when, when the product has gone to production, it seems like it's that is the end state for many teams like we've put it to production, and it's not the living artifact anymore that we want it to be. It needs to be adapted. It has things that can change, that has it. The whole thing is alive, whereas almost feels like the end point for many teams, and that's the thing that we want to avoid. So much like the anatomy of a body. This has like, it has a skeleton, it has a spark of life. It has like, the first steps that you want to take to pick up, and it needs to evolve until some products, you know, they don't not every product needs to continuously stay alive. At a certain point you want to pull the plug and you want to decommission it, that's completely fine. But also, some products are so good that you want to build an entire family about this. What if we get to that scaling point that we have many products. How do we deal with that stuff? Like it's never a single standalone thing if you're in a scale organization. So how should we set that organization up? How do we deal with those kind of elements? And again, it's a completely living system that we need to take into consideration. And yet, those are topics that many organizations don't really consider in how to set up and how to think about their whole product, thinking,

Dave West  6:26  
Yeah, I love, I love the metaphor. I love the digestive system that always it creates a lot of imagery in your head and about junk food, good food. How do you feed it? You know? And I guess that's part of the backlog. My experience of backlogs is that they have a lot of really bad food in them as a rule. Unfortunately, it also, I love the, you know, the idea that, just like any living thing, it's part of an open system. Usually, most products don't live in isolation, unless you're on a maybe on a spaceship or something, and even then, probably not. I thought that was really, really interesting. The circular system really, really interesting. This, this flow of value, I thought was nice and minimal. Lovable product was kind of cute. I love that we're

Unknown Speaker  7:21  
keeping it professional here. Dave, yes, obviously,

Dave West  7:25  
I just thought the the difference between viable and lovable is such an interesting you know, it got me thinking, and I'm not sure it's totally right, but it got me thinking and and that was perhaps, you know, what the book was trying to do, right? It was trying to get you trying to get you thinking. And I thought it was really, really good. So tell me a little bit about, you know, both of you scrum obviously, I met you because you're both professional scrum trainers. I've been very fortunate to spend quite a lot of time with you, talking about Scrum and product, because that's, that's my passion. The book, though, you mentioned that you felt you needed it when you were writing solution, solving for value, and you were seeing how much, how disconnected organizations were from the idea, the idea of a product, and actually what they were doing. What does it what does it do? What as it's taken us beyond frameworks? Why? Why did you really realize that you needed a book that wasn't what we'd had already? You know, what was that big change?

Sander Dur  8:41  
There's a couple of things in here. Let's start off with that theory and practice often are two vastly different things, right? We teach, we talk about the picture perfect scenarios, how things should be. There's, there's a whole myriad of many theoretical perspectives and how things should be that often don't apply in many people's organizations. Stuff that has been discussed in Silicon Valley often only adhere to and apply to Silicon Valley because it's such a such an anomaly in the whole product space, which I think is awesome, but it's not necessarily very applicable to the other people, and therefore making these books almost redundant. So we wanted to build that gap, or fill that gap between theory and practice, and also create, like a connection between all these theoretical books, like all these specialists, they all have their specialism, awesome, but we are more like the general practitioner that you go to for the wider adoption, and we can refer you to specialist on certain topics. That's where this idea also started. And to make this more applicable, we use the knowledge of the awesome company, Miro, or Miro, however you want to call it, and how they apply the concepts that we discuss in the book, and how. They bring that to life?

Ryan Brook  10:03  
Yeah, I think I'll come at it from a similar angle. The reason we wrote this book was because we're very fortunate to work with thought leaders in this area, but we have to acknowledge that the vast majority of product professionals are not thought leaders, right? They are. They are trying to just do the best for their product. So I kind of talk about this being quite a humble book. This doesn't expect anything of you. It's not vastly theoretical based. It's how do I use this scenario, in our case, Miro? How do I take these concepts using a simple metaphor of body that we all understand to help us all take something away, and that's why we felt the book was needed. Take it away from that abstracted theoretical level for something practical,

Sander Dur  10:43  
it gives people, literally the questions, almost homework, to think about reflective as well as reflective at the beginning of every chapter will have everyone think ahead about the topic that's about to follow. How do you think this applies in your organization, followed by the content, followed by Miro, and then followed by some reflective questions. So how can you now improve this stuff? So it's not just a here is the theory. And now, good luck with this. We make people actively think on what they can improve and how they want to do this.

Dave West  11:11  
Yeah, it made me feel a little bit like it was a training class that I was experiencing myself through a book, because that okay, let's think about the topic, get some framing, which is what we do, and then teach you some stuff, and then look at how that applies in your context tonight, which I thought was really good. So it's

Ryan Brook  11:30  
interesting to say that, because when I look at it, I basically see the PSP away class for those people who haven't ever experienced it, advanced toolkit, product based class. This is an expanded version of quite a lot of the curricula there,

Dave West  11:44  
and when you can obviously have at home on your desk when the real stuff's happening for it for an inspiration. How did that work with Miro? So you work with Miro, right? Or Miro or however you say their name. First rule of products have a name that everybody can say, but the you work with them. How did that change your perspective on a day to day basis? It Was it really that taking this sort of more practical approach? Is that? How it made you think about think about the work of product?

Unknown Speaker  12:19  
Yes, and

Sander Dur  12:23  
the amount of work and the amount of knowledge work that goes into a product that they serve and how they balance this, this out also, we've been fortunate enough to work with UX researchers. We've been fortunate enough to work with product managers, but also a founder of a company that's called butter. Milo acquired the company, so how they then deal with integrating that stuff and also thinking about, how can we prevent this waste? How can we prevent our system, our body from bloating? Made it in a very interesting thing for us as well. We learned a lot from both Milo itself and also our perspectives changed at some point, and how this integration and the more business side of things integrate in product thinking as well. To me, it was incredibly interesting.

Dave West  13:13  
Yeah, the practical so I love all those theoretical books about product I, you know, I lived in Silicon Valley. I've worked in Silicon Valley. I love lot of stuff happens there. But when you actually take to and apply it, it is actually a lot different. Silicon Valley is unique because you highlighted sander and and everybody goes, oh, I want to be like Silicon Valley, but you can't be. You don't live next door to a, you know, to somebody that works at one of your competitors that you have dinner with, you know, once a week. You can't, you know, the flow of skills in that environment is very, very different. And honestly, just, I don't necessarily believe that they build for their users. They build for themselves more. And I don't necessarily always like the things that come at us in black. So it's very interesting that you've you've taken that now slight different topic. Tell me about Marsh mallow marshmallow backlogs. You know, I love a good marshmallow. I particularly like a small and so that's when did that come into this nice

Ryan Brook  14:26  
and squishy and tasty, right? I've got that sound to take this one. I'm conscious. I know he just answered the last question, but you've got to take this one now, dude, it's

Sander Dur  14:35  
similar to bloat and like the size of the expansion, talking about scale and waste in the system. A marshmallow. Even though it looks very nice, it looks very tasty. It doesn't have that much nutritional value. Same with these. It's, I know it's shocker. Now you learn something again. There you go, Dave,

Dave West  14:56  
it's disappointed. I'm very disappointed, but, yeah,

Sander Dur  14:58  
I'm sorry, but that's. The same with these kind of backlogs, it seems very nice to have all this stuff, like there's so much work to do. But it doesn't mean that everything is valuable, right? That's Yes, howing He is known for, for the for saying, or for bringing his thoughts out on scaling, saying, it's more about minimizing the amount of work and try to get this maximum value out of as least as little amount of work. And that's the same with with your backlog. Try to minimize the amount of marshmallow stuffing that's in there, and really focus on the core nutritional bits. Get those in and keep your try, keep to try your try to keep your body as lean as possible. And that's it's the same with having people stay busy, right? It's resource utilization, etc. Doesn't mean that they're actually valuable. Having people just be busy is the same as a hamster running in his wheel, like they go, Wow, there's a lot of motion, but there's no progress. And that's that's the same with these, these backlogs. And before you know, your marshmallow backlog becomes a graveyard backlog, where ideas come to die again. Motion does not equate to progress. Yeah.

Ryan Brook  16:06  
A nice tip to try with your teams. For people who are listening, assuming you've got a product goal, or at least some sort of strategic vision, just go through your 100 200 items and just put a tick next to each one that actually contributes towards that goal. You know, if you're looking at 1015, 20% of those items contributing towards your goal. What's going on? What are you doing with the other 80% you know, perhaps you have got a marshmallow backlog, or a graveyard backlog. I think we also call them in the book, very similar, the place where ideas go to die. Don't let that be your backlog. Let it be a store of potential value.

Dave West  16:40  
It's it's really challenging, though it's easy to say that, but it's actually kind of hard to do it, because, well, if you look at your team, and you look at the skills that they have and the experiences and their biases, etc, and then you look at the work that's coming in most managers sort of do some sort of connection between those two, and then that ultimately determines what you're working on. What you're saying actually is like, yeah, that's that's cool, but you really need to, as Ryan said, tick the things that are connected to the goal, and that might mean that some of your teammates aren't necessarily as busy with, you know, as you would expect, right? Or as your manager wants that utilization idea. And that might mean they'll have to work on things that are outside their comfort zone, partner with other people, etc. So it is hard. Sanda, don't

Sander Dur  17:40  
you think, yes, that's more on like, the skill set of people, but when we talk about backlog management, is fairly easy, I would say, maybe not always as fun for the to be on the stakeholder side. But yeah, do you know the tool, Chaos Monkey from Netflix that breaks random? I recommend product owners to be just like Chaos Monkey, just, you know, rip something off your backlogs. You starts to scream. If no one screams, apparently it's not that valuable. So maybe you find some waste in the system. And that's something that you can do with developers in that sense as well. Let's, let's dive into what is valuable here and what's not. And how can we actually move the needle in, even if it's in, like a turtle or tort is actually slowly moving rather than just keep busy?

Unknown Speaker  18:28  
Yeah, yeah. I think

Ryan Brook  18:29  
there's, I think there's a lot to be said about the complexity of product backlog management and also how it's not just about the product, it's also about the people, right? You know, when we say things are easy, things are easy theoretically. And that's the reason why we kind of brought in a story towards this, this entire book, so that people go, do you know what? I'm not alone. And when we talk about marshmallow backlogs, what we really mean is just ensure you have that coherent idea that you're forcing you know that your team is working towards. Because without it, all you will end up doing is, you know, the duck the legs under the water, pedaling faster, actually, not moving that that quickly. So just make sure you know what you're aiming for.

Sander Dur  19:09  
Yeah, it's also a lot of has a lot to do with collecting evidence as well, that an idea is a good idea, and what we expect to get out of this?

Dave West  19:18  
Yeah, I think it's testament right. 70% of features are rarely or never used. And you know, you just need to open up Excel, or many of the apps that are on your desktop, and you're like, oh, there's a lot of stuff here. Why? What is it? And and you appreciate it.

Unknown Speaker  19:37  
So I love that

Ryan Brook  19:38  
statement, Dave, 70% of features are never used. Well, if we extrapolate that to arguably 70% of your effort, then is wasted. But my problem is that the level of validation that I see in product teams right now does not equate to 70% and it worries me that we are wasting 70% and that limited validation. It does not help us find out where those 70% reside, hypothetically, 70% but if I asked any team, where is that 70% waste? Not in our product. It's not for us, no,

Dave West  20:13  
because what Sander was saying, really talking about evidence, talking about flipping requirements to actually outcomes, you know, to trying to define what are we trying to achieve, the why, rather than how we're going to do it, which we can spend an awful lot of time focusing on. There's also an interesting set of choices you have to make about quality and about, you know, these, these very bizarre cases that you build into your product to support certain case. You know, think situations that happen, 00000, 1% or maybe never happen. And instead of saying, Okay, we just boot that to a human being and they deal with it. We build all this elaborate capability, which is which then is an overhead to manage and to and to

Speaker 1  21:10  
change, yeah, but I

Dave West  21:14  
guess at the end of the day that doesn't mean we don't like marshmallows, sander, right? We can still eat them, even though we have to, I know your body's a temple, but we just have to be, we just have to be mindful managing our marshmallows.

Sander Dur  21:30  
And even there, the beauty is in the eyes of the beholder, right? If you value marshmallows, You're my guest.

Dave West  21:37  
And if you talk to my children, I think they would, they would, they would definitely value them, as my son does. The how many marshmallows can you fit in your mouth game? Which is which one day I think he's going to end up choking himself to death or something. So I'm, I'm very mindful of

Sander Dur  21:56  
that's what a lot of teams play too. Like, how many product backlog items can I collect before everything blows up,

Dave West  22:03  
yes, and yeah. It is, yeah. I look at my own backlogs, though, and it is, it's taking that time. And I guess this is true, just to take that analogy of the Met, you know, the human body, and it's taken the time to assess, to do that, you know, to check in, do your temperature, put that ring on. That gets you all sorts of data. I know, I know Ryan loved his, though, interestingly, took it off in Japan because it all it was telling him was he needed to slow down and go to bed earlier. It was like, Well, I'm not, I'm not ignoring that didn't work, did it?

Sander Dur  22:45  
But, oh, there. That's where those texts came from. Ryan and

Unknown Speaker  22:50  
we don't talk about the photo

Dave West  22:52  
suddenly, yeah, we certainly don't. But what was interesting is, though it's taking that time, right? Make being mindful and being focused on balance and understanding taking that step back. And I think that that is definitely true of any good any good background, and any good human, you know, body as well, having having that data, spending that time and thinking about those things.

Sander Dur  23:20  
Yeah, like anybody, our products can get diseases as well. And luckily for us, Radhika Dutt, author of radical product thinking, she wrote the four forward of of the book. She talks about product diseases a lot, and we have some that we touch upon this, in this case, as well as, don't assume that your product will always be healthy, even if it's your cash cow, even cows can get sick, right? You want to prevent these, these things from from creeping in. The other one was the other one. Person who wrote them forward was Alex Van benicum, one of the co founders of the Agile Manifesto. So even to us, this is, again, it's been a wild story.

Ryan Brook  24:02  
Yeah, I think for us, this idea whole of Anatomy of a product. I love Grey's Anatomy as a TV program, and we're sitting there watching it, don't judge Dave. I love my Meredith. And what we were thinking is that, not necessarily, this is not supposed to be a textbook. This is not supposed to be the official Grey's Anatomy, the real book that exists for medicine, right? But it is hopefully something you can dip in and out of, right? Yes, you can read it end to end. But all products are at different stages, and this book talks about products in different stages using a theme of Miro. But, you know, do you want to learn how to look at metrics, well, maybe go and have a look at the nervous system. You know, do you want to look at how you could scale and talk about more of a product family? Then maybe reproduction is your area. So that's what we wanted to try and do for people. Give them 10 to 15 pages. How can you do this? And that's where we ended up.

Dave West  24:56  
It's very practical. All right, so talking of practical, what's the. Biggest takeaway on mind, shift change that you would hope readers will walk away with after reading this book. What's the outcome that you you were you sort of were thinking or you were bearing in mind as you wrote this book?

Ryan Brook  25:18  
Oh, that's a brilliant question. Do you want to go first to go first? To give me time to think, Sandra, are you going to force to go first?

Sander Dur  25:25  
Yes, to both. No. I think it comes back to the idea that your product is is a living thing, and it's not just your output. And then, you know, you can get your hands off, and not my problem anymore. It's you have to maintain this thing, assess it. See if there's any way see how we keep it healthy? Do we, are we just keeping it on life support, or do we need to end its misery? And, you know, pull the plug, just be mindful of where you're at, what it's actually delivering. And do we, what do we need to do next? I think that, to me, is the is the biggest takeaway that I hope the reader goes on with.

Ryan Brook  26:00  
Yeah, I think mine would be almost exactly the same takeaway as I said in the podcast when we did solving for value. And I've just gone into our final word, actually, while Sanda was answering, and it's four words, you are not alone. And whenever I write, I say whenever I write books, a second book, but no, when we wrote the last book and we when we wrote this one, it's not written for this vacuum of potential readers. It's written for the person listening to this podcast right now, the person reading this book. We want to say we've been there. It's not perfect. Here are some of the ideas we've gained from from the trenches and maybe being 510, years ahead of you in experience, what can you what can you hopefully learn from us, but we're also really keen please connect with us and tell us yours. At the end of the day, there's already a third book potentially in the in the running. And we love we love stories, so please, please connect with us and

Sander Dur  26:52  
talk to us. And if I can do one shameless self plug here, January 13, we have the book launch event in our office in Amsterdam, where we gather with all the audience that wants to sign up. You can go to the NL scrum page on meetup.com. You can find it there. Join us for workshops. Join us for free dinner, drinks, free copy of the book. Ali, I'm Benny. Come again, one of the co founders of the Agile Manifesto. He's going to be speaking there. We'll present the book. And again, everyone goes home with a book. It's free, and we hope to see you all there.

Dave West  27:26  
That's awesome. We will obviously include those links in the show notes, so there'll be below this, this podcast on scrum.org so you'll be able to find that link, or at least just click on it. And if you're in the area, I definitely recommend it, gentlemen. Thank you for spending this time with me today. I love the book. Love the metaphor. The metaphor just keeps delivering fabulous things. You know. I love the fact that you obviously, just like any athlete, you know, you obviously build the system in support of the goal. So if you're running marathons, you best not be, you know, 400 pounds and really muscular. If you're a defensive lineman on American football, you need to be more like that. You know, there's so many ways in which this metaphor delivers value when you're thinking about your product. So I really appreciate you opening my mind to that. Thank you.

Speaker 1  28:27  
Thank you for that. Thank you for having us. It's always a pleasure to talk to you, Dave, and thank you for reading it. You write in a very, I don't know, addictive way.

Dave West  28:37  
I don't say it like that. It's kind of easy to read. Which was, which is a good thing. It's a good testament. So that's, that's awesome. So, so and listeners, thank you for listening today. Today, we were very, very lucky. Had two awesome people on sander, professional scrum trainer, fellow podcast host and Ryan Brook, professional scrum trainer, author and founder of opti learn they join me to talk about their new book, anatomy of a product. It's should be out as this podcast hits. So feel free to, you know, find it. We'll put some links in the in the show notes so you can easily find this book. And you also were invited. Sandra invited you all to the to the book launch party, where I heard free drinks and food, which is and book and book, you get a copy of the book to take away. So that's awesome. That doesn't mean you can't buy it now, though. So I mean, you can never have too many of this, of this book, right? Which is, which is great. So thank you for listening today. Today's to scrum.org, community podcast. If you liked what you heard, please subscribe, share with friends, and, of course, come back and listen to some more. I'm lucky enough to have a variety. Variety of guests talking about everything in the air, professional Scrum Product thinking and of course, agile, thanks everybody and scrummarg. You.

Transcribed by https://otter.ai