Like what you heard? Check out our podcast page for more episodes full of interesting discussions, agile insights, and helpful resources.
Transcript
Intro: [00:03] Welcome to Agile Coaches’ Corner at AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile experts, Dan Neumann.
Dan Neumann: [00:19] So with me today is Ryan Dorrell the chief solutions officer and one of the co-founders of AgileThought and we’re going to be exploring the topic of product management. So thanks for joining Ryan.
Ryan Dorrell: [00:30] Thanks Dan. Great to be here.
Dan Neumann: [00:32] Right. When you think of product management, maybe you can, um, can you give us a little bit of a taste for what comes to mind for you around that topic?
Ryan Dorrell: [00:41] Sure. So when I hear the term product management, and I’m specifically talking about software product management, um, I think about all the, all the stuff that you’ve got to do to, um, think about really defining what that software product is, uh, what market it’s for. Um, who are the personas of the people who are going to be using it? How are you going to create an experience for them that’s very delightful and fun to use and highly engaging and gets the job done in a very, a very clean and nice manner. Um, and something that solves something that perhaps solves a problem in a unique way that uh, that maybe they haven’t thought of, uh, solving that problem like that before. So it’s a, it’s a different kind of skill than I think what a lot of us in sort of the software delivery world or are sort of use to, it’s a little bit of a higher level thinking, um, around what is the product we’re a building, why are we building it? Who are we building it for? What problems are, are we are, are we solving?
Dan Neumann: [01:49] Yeah. That’s completely different than what I was used to in your project management world. Or even as a developer when we were delivering things, when I was fresh out of college at a different place, you know, we would get a requirements document. It was all the stuff that we needed to do. And then even, even as we got into agile and scrum at another place, we were still it consuming backlogs. There wasn’t really much of a concept of product. It was still largely a product sense.
Ryan Dorrell: [02:16] Yeah. I think, you know, and I’ve kind of experienced the same thing throughout, you know, throughout my career is that that what, what we’re building and how we’re going about building it, excuse me, how we’re going about building it can be two really disconnected things. Um, and I think particularly in enter in enterprise software delivery, I think the, you know, it’s my opinion and that is that the product management aspect of it kind of largely gets ignored or we just don’t know how to do it or we don’t think about actually needing to, um, do it. And then to your example of, uh, you know, you get a requirements document or you get a backlog of work. I mean, I think that’s the experience of most people in enterprise today who do enterprise software development. You know, they’re, they’re, they’re given orders. They’re given, uh, they’re given a list. They’re like the, they’re like cooks in the back of the kitchen, the ticket comes in with the order on it, and that’s what they have to make. And they don’t get a lot of input on it exactly. Um, you know, why that might be a great solution for the individual who ordered that meal. Um, so there’s two things are pretty disconnected and I think, I think there’s, there’s, there’s a lot of thinking going on, but I think, I think that hasn’t really been married in terms of the, the, the, the software delivery side of it and the product management side of that. I still think there’s a big disconnect in our, in our industry right now between those, between those two things.
Dan Neumann: [03:46] Yeah. And why do you think the industry struggles with that disconnect? Or why does that disconnect exist?
Ryan Dorrell: [03:55] Why does that disconnect exist? Well, I, from one, I think we struggle with it because it’s, it’s hard. It’s hard enough to, to deliver software and then to have to kind of think about the product management side of it. It’s, it’s becomes quite a bit, it’s a little bit of a, a diverse, um, a skillset. Um, so just the sort of breadth of it maybe is too much cognitive load for, for somebody to, uh, think about. Um, and I, you know, and I think I think our particularly the agile software development community. I think it’s done an outstanding job over the last decade really kind of solving the problem of delivering software. So, you know, given a nice clean backlog of work to do, um, to go from there to software in production. I think those problems, you know, there’s still some, some certainly some challenges, but, but by and large, that’s those problems or have been solved. Um, you know, we have techniques, many, many techniques for doing team based software delivery. Um, obviously the rise of DevOps in the last several, you know, last couple, three or four or five years has been pretty huge, so we understand how to flow software out through from, from teen to production really, really quickly and smoothly. Um, but I think if you take a step back, there’s, there’s all this work that needs to happen up front to figure out what the heck we’re even building in the first place. Um, I don’t think the agile community has addressed that, um, in the way that, um, other parts of the software, you know, overall software development community has. Um, you know, and I’ll, I’ll pick on scrum here a little bit and I’m a huge, you know, scrum advocate, but it doesn’t say really hardly anything about about how to manage a product. Um, and, you know, maybe it wasn’t designed to do that, but, but that’s, uh, that’s a critical skill you need to have if you’re going to create a software product and take it to market or, you know, take it to internal or external customers. Um, and it’s, and it’s largely ignored. Uh, so I mean, I, I think, I think there’s a, there’s a lot of good thinking and work that are being done out there around product management. We’ve got to bring those two worlds together.
Dan Neumann: [06:11] Yeah. I’ve spent a fair amount of time in scrum training classes delivering those. One of the points that we make all the time is scrum is a framework. It, it’s super lightweight and it doesn’t tell you a lot of the house and you’re spot on. It doesn’t say anything about how the product owner is supposed to come about having a backlog that is optimized for. Right. And then you, you also touched on the diversity of skill sets. So if we’ve got somebody who is in the scrum product owner role, who’s working with the team to make sure they understand a prioritized backlog for value and they’re working with a diverse set of stakeholders, you know, a lot of times going out and really doing market research or personas. Um, you’d mentioned kind of looking at the experience that person has. There’s not enough hours in the day for that. So it, it does make me think it’s not a one person job to do the product management as well as the product.
Ryan Dorrell: [07:05] Yeah. And I think it is a different skill and it’s, um, it’s a hard skill. It’s a lot softer skill. Um, it doesn’t require technical understanding as much. Um, it requires a lot of creativity, requires, um, you know, just a very different kind of mindset towards what, you know, how to solve problems. Um, and it’s very hard for people who I think are in software delivery to make that leap sometimes because it is such a different, a different mindset towards it.
Dan Neumann: [07:37] It is a different mindset. So given that it’s a different mindset and requires a different skillset perhaps, and it’s not within the most popular agile framework out there right now, what, what can folks do to fix it or how, you know, what kind of tips or techniques do you have for people around that?
Ryan Dorrell: [07:58] I mean, one is to to go start learning, um, and, and at least, and at least start to, to, to understand, um, that that aspect of taking products to market. Um, and there’s tons of good resources out there and I think we can talk about those a little bit later cause I’m reading a couple of things now, but, um, that I’d like to share with everyone, but, you know, start learning start at least, and I’m not saying become an expert but, but start understanding, you know, that that aspect of it and, and that sort of universe that exists over there. And I think, I think it can be pretty enlightening for a lot of people. It’s, it, it is, it is, you know, product management can be really fun, energizing, hard work, just like doing software development and delivery is, but, but it’s, it’s very different kind of creative outlet for you as well. So, um, that, that, that’s where I would get is go, you know, and we’ll talk again. I think we can talk about these later, but there’s a, there’s a lot of good. Um, there’s a lot of good stuff out there around product management, lean product management and there’s, and there are people in the agile community who are, are talking about this as well, who I would kind of lump into the agile community. Um, Jeff Patton, doing a lot of doing a lot of great stuff. You know, he’s got his book, “User Story Mapping,” which is a great, a great place to, to um, start. Um, Chris Spagnuolo here at AgileThought he does, has, has done a lot of really cool stuff in the product of, you know, product management and product design space. Um, but you know, again, it’s probably, it’s like, you know, picking up a whole new, a whole new career path. If you say, well, I’m a, I’m a scrum master, but I want to be a product manager. Well, you might not be starting from scratch, but you’re, you know, you’re going to have to learn a lot of new skills, techniques, um, you know, to understand how to create and build and design a software product. And I’ve been very explicit here to say product as well. Um, and not project cause I think in our, in our industry we get, we get confused with that a lot too. We, we use those terms interchangeably. Um, and in fact they are, they are very not interchangeable.
Dan Neumann: [10:19] Right. A project for me brings to mind a very defined start and a defined end. You’ve got a certain set of dollars set aside for that timeframe and you probably have a team kind of in mind for it, at least a team composition and they’re fairly easy things to, you know, you manage them, you, you have a process to begin, then you have a process to end them. Uh, whereas product, I think one of the things people struggle with is, well, it’s never done. That product can go on for a very long time until, you know, potentially you sunset. And so what kind of challenges are you seeing maybe on the financial side of how to budget for a product? Or what impact does it have on the way we do the math on the back end?
Ryan Dorrell: [11:00] Um, I mean, I’m not an accounting expert, but I know there’s, there’s different ways to account for those things. Um, you know, like kind of like you said, projects are constructs and most often in enterprises, they’re accounting constructs, um, you know, we’re going to build some thing and we’re going to allocate some number of dollars people in time to that. Um, and at the end of that, uh, you know, I don’t know what happens next. Sometimes you know, somebody got to take that over. So, you know, it’s, you create, you have a project for six months to go build a piece of software. It’s not free to, after those six months, that piece of software’s not free. You’ve got to address, um, some sort of continuous investment in that to, to keep it going. Um, you know, be it maintenance or bug fixes or, um, you know, responding to change. And I think that’s a big, a big thing, right? If you’re, if you’re taking a whole, um, I mean that’s the whole deal behind agile, right? We want to be able to respond to, to a change, well, if we’re doing start and stop projects and there’s a stop at some point, how are we being responsive to change after, after that. There’s nobody to go, go make that change, you know, we don’t know how to deliver it back out to our customers. Um, so we’ve got to, we’ve got to think about, you know, long term investment streams in products, not just projects that have defined starts and ends. And there’s a lot and there’s a lot of good conversation happening in the agile community right now around project versus product. Um, that people can go, can you be, become engaged in and, and, um, there’s some really, really interesting thinking around that and there are people that are like, heck a lot smarter than me who can talk very eloquently about the pros and cons of each of those things. And I don’t know if projects have any pros, but, um, certainly it’s, it’s a different way of thinking about it and there’s a lot of value in thinking about a product portfolio and not just managing a bunch of projects.
Dan Neumann: [13:18] Yeah. I felt like we needed that legal disclaimer does not constitute accounting advice when you started talking about it.
Ryan Dorrell: [13:24] But yeah. Well actually I do want to share one anecdote around that. Right. So, so I was consulting with the organization, this is actually several years ago now. Um, and they were a, a, you know, not a, not a huge IT organization, um, around 70, 80 people. Uh, but they, um, you know, projects was their world, right cross matrix. Everybody was on two or three different projects. Everybody did these extraordinarily complicated time sheets to make sure that we’re accounting for their time, which is dollars, which can be assigned to projects. And then that project has some potential, uh, return value on it. And there was, there was a significant amount of overhead just in capturing that information, having people try to say, okay, well how much time did I spend on that last week versus this project, I’m on three different projects. And, and then all the accounting and, and you know, approvals and workflow that has to happen to go to create all this data that is probably not being used or not very valuable anyway. Um, and that organization that have going through an agile transformation over a period of a couple of years. And I remember very distinctly one huge milestone, which I was very, very happy to see with them is they, they really went from that project focused delivery to product focused delivery. So a big part of their agile transformation was to align into product delivery teams. Um, and their whole budgeting process then became, instead of, you know, trying to, you know, they would have over a hundred projects to do in a given year in each one of those had an, it had a distinct budget. They had their there I think 12 or 13 teams and they knew exactly what that team cost every a year and they knew what products were supported by that team and that was the math. If you know, they, for example, they had a, um, they had an iPhone and an android app that they supported for their, that supported their business and they had a small team of people that work on those two applications. So they knew what their investment in those two products was every single year those three or four people salaries plus overhead and they can make investment decisions in those two products in a very, very simple way without having to come up with projects and budgets for those projects. It was, it was much more simple math and it got to the point where they stopped timesheets and all the, all the staff, there were certainly very thrilled about that. Um, the only thing, I think they had to sell it a submit a time sheet if they took any vacation just to record that, but they didn’t have to record time against their um, against their project codes. Um, so huge amount of organizational overhead was just gone and cognitive load for those individuals was gone and they can focus on the products.
Dan Neumann: [16:33] Yeah, I think projects and waterfall pair very well with each other. So you know, you have a beginning and an end and now we have all the, the change management that goes around that and shifting to teams and backlogs which also then pairs well with having a product that lives on. You don’t have to haggle over, oh, is that a missed requirement? Is that a change that we’re going to put in? And what does that mean from a dollars and time standpoint and in all the energy that goes around that. So yeah, teams with products and you’re right, the math is simple. How, how many people, how much did they cost each year? And that’s a big chunk of your budget for that, for that product.
Ryan Dorrell: [17:12] That’s pretty much it. Yeah. And actually I, I, there’s a brand new book that came out and it’s called “Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework.” And it’s guy by, um, uh, Mik Kersten, I think I’m pronouncing his name right or their name right. Um, and it’s got a foreword by Gene Kim who has been, you know, big, um, evangelist in the DevOps space, written some written, some great stuff around that. And um, it, it kind takes them through from the project model to the product model through a continuous flow framework. So, you know, how do we continuously deliver value in, you know, aligned with products and services that our organization provides to our customers. It’s kind of, I haven’t had a chance to read the whole book yet. It’s literally just came out, so it’s Kinda hot off the presses. Um, but it, you know, I get the sense from kind of flipping through it, that’s, that’s what it’s aligned around, which is stop doing projects. Think about a continuous flow of value, which really is supposed to be the core part of the agile development front of, you know, agile, the agile principles, right? Let’s continuously deliver value. Um, and we’re getting some good work done now to start to articulate that into the agile, into the agile community.
Dan Neumann: [18:42] I’ll have to check that book out. It’s, do you know if it’s one of the, one of the recent trends seems to be everybody writes a novel, like a business novel that has the lessons in it. Is this one, do you have a sense for whether it’s more, um, I don’t instructional, I liked the more academic books myself. I’m just kinda curious.
Ryan Dorrell: [18:59] Well I think you might like this one and this one, it looks a little more academic. I don’t think it’s a, um, it’s not an, it’s not a novel from what I can tell by out, by looking at it. Um, but what I do think again, I’ve, I’ve literally done nothing more than flip through it, but in the few paragraphs that I have read, I have seen a lot of sort of like mini case studies where they were talking about, you know, in fact I’ve got it in my hand right now and I’m looking at it and um, uh, it talks about the BMW group at one of their plants over in Germany and what they did around automation. And so I think there’s a lot of sort of, um, anecdotes around that are from that are from the real world, which I think is really, which is really, really valuable to understand that now this is not just academic stuff. You know, organizations that are innovating are doing, are, are doing this kind of work. It’s time for you to start doing it too.
Dan Neumann: [19:54] That’s fantastic. Very good. So thanks for that. Yeah. We teased out that book a little bit earlier and so thanks for that. And it’s impressive you actually have the paper book.
Ryan Dorrell: [20:18] I do, I did my paper book kind of guy.
Dan Neumann: [20:21] That’s okay. There’s, there’s some research that indicates the reading paper books actually helps the, the brain remember what it’s read better than ebooks.
Ryan Dorrell: [20:29] And it’s a visual cue that I own that I own the book cause it can sit on my desk or on my, on my nightstand next to my bed and if it’s on a kindle or something, I don’t see it. So I forget that I have it. Yes. And it looks nice.
Dan Neumann: [20:42] Yeah. You can show off your, your bookshelf at the office. Otherwise you have to print like little or something to show which books you’ve read. How do you brag if you don’t have the paper? That’s awesome. You mentioned a Chris Spagnuola here at AgileThought he does a bunch of work on the product side and one of the, one of the frameworks we use his story mapping and that helping to figure out, um, you know, kind of where that minimum viable product is, what are walking skeleton is what, what don’t we need for version one that can go on later. So that’s, that’s one of those frameworks that you mentioned. And then we also did a design thinking workshop recently. So really trying to get people to build empathy with their customer and understand their needs cause he might come up with a solution that that customer or that user had never actually thought of that they needed. And so design thinking is another one of those tools. Yep.
Ryan Dorrell: [21:37] Yeah. So, yeah. And so, um, yeah, we’re kind of back to what I was saying earlier. It’s, it’s a different skill set and it’s, it’s, it’s actually really fun work to do. But, you know, take a, you know, take somebody who spent their entire career in doing waterfall or agile type software development where they’re, you know, they’re trying to, they’ve got requirements documents or maybe they are they got some product backlog and user stories. They’ve tried their best to kind of cobble together through, you know, different grooming sessions and things like that. Now lay in tools like customer journey maps and user story mapping and design thinking workshops where you say words like empathy. And I think that it really, it can really rock somebody’s world in a very positive way. Like, wow, okay, there is ways to solve this better. That’s not very good English there, but there’s, there’s mothers there. There are ways to address this issue of what the heck am I supposed to build in a way that is very different and very positive, um, and uh, much, much more valuable than just getting a couple of stakeholders in a conference room and saying, okay, tell me what you need. You know what I’m kind of really excited about, you know, the more and more I learn myself go through a journey of learning more about product management and then all those great techniques that are really, I think in the, you know, they’ve probably been around a little while, but I think in terms of the agile community, there’s somewhat emerging, um, and, and through the products as a career is, I would call it still sort of an emerging career. Um, but there’s just some, some incredible stuff being done out there to help people visualize a solutions to problems and go through collaborative sessions to, uh, to solve those problems in a way that’s very different than what a lot of enterprise software people are or I used to.
Dan Neumann: [23:32] Yeah. I wanted to pull into a term, you’ve used the term enterprise software folks, and I was curious if, um, you’re referring to that as people who are building, let’s say, a large applications that will be deployed internally or if it’s enterprises building customer focused things. Could you maybe elaborate on what you mean by enterprise in this context?
Ryan Dorrell: [23:54] Yeah, sure. You know, and I, I use that word with intent. Um, cause that’s, that’s largely where my personal, um, experiences come from is, is around, you know, large scale enterprise, large scale software development for internal customers at, you know, decent sized organizations and I say decent sized like made $500 million and up with, you know, complex IT environment, um, perhaps a very wide variety of stakeholders in a complex business domain. And there’s a lot of that out there. Um, I’m talking less about the, um, you know, customer focused or you know, silicon valley type of, you know, trying to solve some problem to, you know, rent an electric scooter to, you know, buzz around town on. That’s to me, that’s my experience and again, kind of my perspective, my experience is going to be maybe a little bit different from that, um, people who live in, in that world. But I’m kind of talking really at the people who, um, are out there building those, uh, those business systems that run large organizations behind the scenes. And there’s a, there’s a lot of that out there and you know, but occasionally those people need to go build something for a customer as well for an x, for an external customer of that, um, of that organization. Um, and that’s even maybe a little bit of a different skillset. So, um, when I say enterprise software development, I’m talking about those people who are, are uh, building those big apps that run, run the, the back offices of big, big companies.
Dan Neumann: [25:38] Okay, thanks. That’s helpful. And one of the things I find is an interesting dichotomy with that is they are for internal customers, but a lot of times it’s really tricky to get the time of those people or whether it’s the users or the stakeholders. So they’re there, they’re in your own organization. You don’t have to go find them in the wild, but getting their time and then really engaging them on the product management side I think is, is a big challenge for a lot of folks. Is that what kind of, how you’re seeing it as well?
Ryan Dorrell: [26:10] Most certainly can be. Um, it depends how you, uh, uh, engage with the, have traditionally engaged with those in those internal customers. Um, cause they have a job to do as well. Um, so I think you can use some of the techniques that, um, uh, you know, more external product focused organizations use, which are, you know, doing, you know, not, not, you know, they don’t necessarily bring their, their customers in for, you know, multiple days to do, to do long things. Um, they do a lot of user research, you know, using different techniques that are, that are, um, less time constrained on those folks. Now I think for, for, for, you know, building sort of internal apps, oftentimes those business domains are so complicated that you need somebody who’s an expert in that thing and you just have to get that engagement. But yeah, that can be, it can be very, very challenging. And I’m thinking about one thing, um, or one product we built for a customer very recently and is an extraordinarily complex business domain. I mean we would not theirs and it, and it has to work the way it has to work because it’s in a highly regulated type of space. So we really needed engagement from, from our customer to, you know, help us understand the depth of complexity that are in with some of the regulatory requirements. Um, so sometimes you just kind of can’t get around that and you can’t go make up a new way to solve a, a problem that the US government tell you, tells you you have to solve it this way.
Dan Neumann: [27:50] Yeah, even though the domain is regulated and the way certain internals might work has to be that way or the types of proof for, or things like that are set, it seems like that still leaves potentially a lot of room for how do you make that a usable product? How do you, you know, use the modern agile and how do you make people awesome when they’re using this product as opposed to, um, you know, just taking something that maybe has a paper form regulation from the government and then turning that into a screen with, you know, an awful user experience. Is that where you see some opportunity to innovate with the, on the product side, when things are regulated?
Ryan Dorrell: [28:33] It is, I think in like a regular, in a regulated environment, you often have to end up with something very specific and say, oh, it has to meet these requirements. These are non negotiable. This piece of data must be captured. It must be signed off in this way, et Cetera, et cetera and whatever those are now the, yes, the, the way an individual, um, interacts with that system and what they see and what they touch, um, that can be, can be a lot more creative. Um, and yeah, so, so that’s, that’s where we are, you know, here at AgileThought, I know we’re doing some really some really cool stuff around different ways to engage with those customers. To, to get, to get feedback loops. But there is some certainly some creativity that can be expressed and implied there to, to create some, some awesome user experiences. So maybe, you know, maybe the, the path to that end point is a little bit different or is, is a little more seamless, a little more streamlined, um, or even, you know, nice to use. Um, uh, there’s the app there, you can do some great. So you can do some stuff there with, around really addressing the user experience and um, you know, making systems fun to use or delightful to use and not just like, oh, this is a ugly enterprise app with grey buttons everywhere and now there’s no reason that can’t be, can’t be slick and, and fast and work as good as Google and Facebook and Twitter and all the other, you know, silicon valley kind of apps out there.
Dan Neumann: [30:07] That’s outstanding. We’re getting kind of near our time box for this. Are there any additional resources or tips you wanted to point people to?
Ryan Dorrell: [30:18] Yeah, sure. Um, so, uh, if you’re on Twitter and you want to and you want to read about what, what the conversation is in the agile community around projects versus products, um, there’s a hashtag #noprojects. So if you go look at that Hashtag, um, you’ll kind of see lots of different conversations happening, um, that I think are really, really, really good. And, and, and you know, pretty, pretty positive. Um, there’s a book from uh, uh, uh, two guys, Shane Hasty and Evan Leyburn, um, around, nope, around the culture of no projects, um, and I think has a lot of really good, a lot of really good stuff in it. Um, and like I said, that that book, “Project to Product,” I haven’t read it yet, but it, it appears to be very well reviewed and, um, I look forward to reading it very soon. It’s just came out maybe a couple of weeks ago from, from um, right now. So those are a couple of places I’d start thinking about projects versus products. Um, on the pure product management side, um, stuff I’m reading right now. I’ve got in my stack, I’ve got “User Story Mapping” by Jeff Patton. I think that’s a metric good. I think bridge between agile software development and doing and doing some, some more effective product management. Um, there’s a book called “Inspired” by Marty Cagan. He’s from the Silicon Valley product group. That’s a good one. Um, another book from O’Reilly called “Mapping Experiences” by Jim Kalbach. Um, I’ve actually been reading this one a little bit lately because it’s got some fantastic visuals of um, things like customer journey maps and serve as blueprints and lots of great, really nice visual pictures of how a product managers, product designers are creating user experiences and, and being able to align those with a business strategy. So that’s a great one as well. Those are my current recommendations.
Dan Neumann: [32:26] I love it. And we will be sure to put those books and links to those up on the show notes and that’s it. AgileThought.com/podcast where people can go find those. And we try and make it easy for people to get those resources. Great, so thanks a ton, Ryan. I appreciate you taking time to join today to share your thoughts on product management.
Ryan Dorrell: [32:47] My pleasure. Appreciate it, Dan. Thanks for the conversation.
Outro: [32:50] This has been the agile coaches corner podcast brought to you by AgileThought, get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.
