Matt Barcomb, founder of OdBox, has over 18 years of experience as a product development leader that takes a pragmatic, systems approach to change. 
He partners with organizations to help leadership teams develop and deploy strategy, optimize product management and development, and evolve traditional HR functions into modern talent development practices. Matt can be found on LinkedIn or on Twitter.
Download PDF Transcript of Podcast
Note: This is a transcription of a podcast. It has not gone through a professional editing process and may contain grammatical errors or incorrect formatting.
Related Podcast: Taking a Pragmatic Systems Approach to Change
Transcription of the Podcast
Joe: Welcome everyone! This is Joe Dager, the host of the Business901 Podcast. With me today is Matt Barcomb. He has over 18 years of experience as a product development leader that takes a pragmatic systems approach to change. He partners with organizations to help leadership teams develop and deploy strategy, optimize product management and development. He enjoys challenging mental models, simplifying the seemingly complex and uncover the ‘why’ behind the ‘what.’ Thanks for joining me Matt and can you give me a little background or that elevator speech on Odbox?
Matt: Sure. Odbox is just a little company I started a few years back to kind of do my own thing and like you said, I tried to partner with companies both as a subcontractor or directly to improve their product development practices in both the development side, the product management side, the product design and delivery side. And then I’ve been integrating more aspects of business especially in the last couple of years around the HR policies, organizational structures, and sales policies and structures too.
Joe: Well you’ve been in the Lean product development area for a long time, looking at your background, how did that evolve? I mean were you a Lean guy that got into product development, or were you a product development guy that got into Lean?
Matt: Probably more of a product development guy who felt that the — I think I was following principles of Lean before I ever would have given it that name. It’s kind of a blur where did it start because I started life as programmer, but I mean actually started programming like really early in life, kind of at 5th, 6th, or 7th Grade. Eventually, I started getting paid for programming which was kind of cool and from there, it was just I wanted to learn more. I liked bigger and fuzzier systems for programming, started learning more about all the other aspects of what I kind of think of as holistic development. So I started figuring out what does it take to do real testing and not just like QA checking. What does real design mean?
I started growing out the craft to software development. I was working at a giant corporation at the time, and I started seeing bigger and bigger limitations that seemed to be just organizational choices, policies, structures and things like that. So I eventually kind of moved into management to try to take over a team, to try to overcome some of the obstacles that it felt like you needed to be a manager to overcome. It kind of grew from there. I started helping my team, and that worked out pretty well. I started helping other people’s teams and then eventually, somebody came along and was like, “Why don’t you do this for lots of companies?” I said I didn’t know that was a thing, and I started jumping on airplanes and the next thing you know, here I am. I discovered Agile; I discovered Lean and a lot about systems thinking and systems design and it all just sort of clicked and I’m very happy to have workers to put the concepts, and that’s cool.
Joe: You didn’t just wake up one day or go to some Webinar or go to some conference and almost attached Lean to product development or anything.
Matt: No, not at all; not at all. I mean I definitely read some books. Actually, my journey was a bit of a long one. The same kind corporation that I was working at, it was kind of the place where you needed a Master’s Degree if you ever were going to make it to director. I was a lot younger then and just being a director at a large corporation seemed like the right thing to, do I went to get my Master’s Degree. I was studying Operations Research and Artificial Intelligence because it seemed interesting. I’ve gone about halfway down that path until I realized like the only jobs you could get in OR and AI focus is either for the government which I never want to do again or go into getting a Ph.D. which didn’t seem very interesting at the time.
I actually switched over into a Project Management degree with an Operations Research concentration. I was really excited because I’m like yay, something practical that I can use until I got my first book, and it was literally like everything wrong with software projects that I had ever seen written down in one place. That’s when I kind of discovered the PMI and not that I have any problem with the PMI but there are a lot of good things that had been misapplied. So because of those books, I kind of discovered other books. The first book was Johanna Rothman’s Manage IT, and that showed me the word Agile. Agile led me to Alistair Cockburn’s methodology book called Crystal Clear, and that led me to Extreme Programming, that led me to Crystal, that led me to Kanban. Kanban led me to Lean, that led me to Mary Poppendieck’s textbooks about Lean software. And that led me to other Lean aspects; things like 6-Sigma the Toyota Way, Hoshin Kanri, and just all sorts of things and it all just sort of fits to help with the team problems, the portfolio problems, the organization problems that I was experiencing. And I’ve loved to read; I’ve always been an avid reader, and I like apparently getting on airplanes, so it all kind of worked out.
Joe: It’s interesting because you talk about your experience and you’ve certainly gotten your hands dirty during the time and gotten involved with things, but before the podcast, we just touched on them briefly and you’re working more that mid-management level, above the team concept towards leadership. What’s that space like and how do you describe your fit to somebody when I say that?
Matt: Yes, I’m definitely not a one size fits all. The stuff that I like to try to poke in that area, people have to be willing to want to hear, people have to be wanting to try something different for some reason. Part of the problem that I try to address is that of many organizations, I kind to think of it as there’s both a vertical or a horizontal problem and the scaling wide going horizontal or helping teams understand new principles, try new practices and techniques are good, but a lot of times, you can only get those teams to go so far until they hit some other barrier that’s outside their control. Usually, that next step is something like program management, or portfolio management, or organization strategy, or direction. Realizing that something as simple as strategy deployment is not usually making it down from the most senior levels in an applicable way that can help people make decisions, and so you find these vicious cycles of people that treat strategy as a plan instead of intent, and so therefore they try to make things more perspective and more detailed and put more controls, and then they don’t realize that that’s just causing the feedback loop to create more of the problems they were trying to solve in the first place. It feels like my entire career, I just sort of went where I thought I could help and then I kind of hit a problem and as soon as I felt that problem, I started moving in that direction; so that following a problem has just taken me into middle management and senior leadership.
Joe: Is that space different? Is it messy? I mean is it hard to define the problems in there?
Matt: I think it’s equally messy in some ways. I see the same patterns I guess. It’s all people problems. To some extent, the specific nature of the problems, I mean obviously things like at the most senior levels, senior leadership, people are worried about the financials, they’re worried about the direction of the business, they’re worried about all those things. If you can’t speak that language, it will probably be very complicated and very hard to build any type of credibility to get people to understand a little bit of where you’re coming from, so you can understand where they’re trying to go. I’d be lying if there wasn’t a little bit of ego involved with folks when you get at that level and a little bit of — by many definitions of success in this country, you are successful if you’ve gotten to that level, so you can’t just go in swinging saying you’re doing it wrong. By many definitions, they’re not doing it wrong; they’re doing it well, they’re doing it right, they’ve been successful.
Trying to tap into both the logical but also the emotional aspect of like how can we improve, what are your goals, are you personally aligned, is your business aligned, is your strategy aligned; it all comes into play. I mean even down to the lowest level with the teams, a lot of times it’s not the technical problems that are there. I mean those exist certainly but it’s all the right people talking to each other, our teams talking with each other. I see the patterns are very much the same patterns. It’s people not aligned with their objectives. They’re not being honest with their own goals and figuring out better ways to collaborate and work together to get things done.
Joe: When you’re describing this to me, what I picture in my mind is that you’re trying to build the not this — the vertical platform as much as some bridges across silos, is what you’re talking about and sometimes to get there, you may have to go vertical and back down because there’s not a clear path.
Matt: Yes, exactly. I think of it as a giant jungle gym, or I mean I really think of it as a network. I see all these people or these groups or these departments as almost like parts or organs in a larger system, and this larger system is just like any other organic being. If you imagine your body, there’s no one part that you might say is in charge but all different parts have their own function and they all have to function together in order for you to do whatever it is that you do. You’d be less happy without your kidneys, but your kidneys aren’t in charge of your body. Your brain, you might think it’s like it’s how you think, it’s how you make decisions, so yeah your brain is really important but you’re not just your brain. So too often I think organizations are organized sort of mechanistically where we want to separate the heads from the hands, we have the people on top are in charge, and they know how to make the decisions, and then there’s the people that are on the bottom are below, and they’re just there to do the work.
It’s not so much about trying to change organizations to reinvent themselves or go flat or any particular initiative. It’s really about helping them understand it as the business landscape, the market changes, it gets faster paced. Technology shifts more quickly. Organizations need to learn how to be more resilient and be more adaptive rather than just become more large and monolithic. Helping companies understand that if you can be more fluid, if you can understand that these groups, these parts, and the people have a function and people have their — they’re functioned to perform, and they have to figure out how to message and communicate back and forth to have the right kind of connections, then the organizations become more like an organism and can kind of grow and adapt as their ecosystem changes around them.
Joe: One of the things that I associate you with, of course, is software and product development, but it seems that umbrella has started to incorporate more parts in the company, and it’s affecting and becoming an integral part of other parts of the company. How is that affecting your work because you talk about a lot more type of organizational work, a lot more type of work with HR – is software the push into it or is it just your growth in trying to make people work together?
Matt: That’s a good question. I would probably say it’s a nice little cocktail of both. One of the reasons I got into human resources, talent development is again through client work. I would go into a place, and they were having problems hiring people that could fit for the skills and we started talking to them and then they’re kind of following a very traditional or recruiting through Monster or whatever, and they ask for help, like how do you find talent, and so we can talk about that. We wound up kind of rejiggering how they do recruiting, we kind of talked a little bit about how should they do promoting, what are their current performance plans and structure, what do those things look like, do they make sense. It’s just sort of pluck a little thing here, and you try a lot of things; a lot of companies are willing to try some things. Not every company has been willing to try all my crazy ideas, but some of them are just things that make sense. I mean I can’t remember ever being at a company ever who thought that how they did ratings, and rankings, and performance, and tying it to compensation was a wonderful, fair and equitable system that everybody enjoyed. So given that that’s never happened, one of my first principles is like well what happens if we get rid of it? Instead of trying to figure out a way to make it better or improve it or add something to the system, what if we try to simplify it first? Not that that will solve the problem, it will very likely cost other problems. But let’s take the thing away first, so when we do try to inject something, we’re injecting something into a simpler ecosystem.
Like HR is one area where we try to grow it more towards talent development, where to find people, how to promote people, how to make that a collaborative thing and I’m kind of a proponent of setting up structures such that transparent salaries could be possible. I want to be clear that I don’t necessarily advocate for going all the way towards actually making salaries transparent; it just really depends on the context. Working with sales organizations was sort of the same way. I started working more with product management as part of product development, this idea that you’ve got a group or an organization that’s sort of incented or they’re going like this to help create a product or sweeter products that has a strategic fit for a market and that they’re sort of always butting heads with this other department in the organization who’s incented to hit quarterly revenue targets at almost whatever sales price, that incented to drive some crazy behavior. I’ve seen product development departments get thrown under the bus because they couldn’t make the features fast enough, and they could have made their numbers if product had just delivered faster. I’ve seen sales departments reel because the BP of product are really hard-lined pricing strategy, and that was not allowing them to make their numbers. So trying to encourage them instead of trying to just throw sales under the bus and say, “Oh sales guys are coin-operated, evil, moron people. They should just go all be car salesman…” Let’s figure out what we’re really trying to achieve through sales.
I mean that’s a pretty obvious problem, we need the company to make money. So how we change sales and how do we change software and how do we change the product to all work together? I mean again this just taking a page out of the systems thinking kind of playbook of how are we not aligned? We have these different functions, we need a strategic fit to a market, we need to make sales, we need a revenue, we need to develop product – how do we get these three things to swim together instead of feeling like they’re often tearing the company apart?
Joe: Do you see sales and product development playing a different role together now? Is it something that is, I’m not selling this as much as maybe there’s more collaboration between the two or sales or bringing ideas to product development. Is there a good side to all of this?
Matt: Oh definitely. I mean well, I wouldn’t be doing this if I didn’t think there was an upside. I’d grow vegetables in my backyard or something. From a house sales benefits product perspective, I mean those are the people that are out in the field. I mean hopefully we’ve got product managers also out on the field. If product managers are just sitting in their office, maybe they should do something else. But these sales guys that are out there, they’re the ones that are talking and having the relationships with the customers. Now that’s a gold mine of data and information, to be able to leverage those relationships to do user research and market research and they’re absolutely — they’re just like a golden pipeline that can feed product development, product management.
The flipside of that is that the developers, the product managers – they need to understand how to actually use that. A golden shovel doesn’t do you any good if it’s just digging you a deeper hole. But sales needs to learn how to not just sell the road map and that’s a challenge because as an industry, we’ve definitely sort of set this expectation with both sales departments but so buyers of enterprise software. This idea that sales should just go out and sell whatever isn’t kosher; they shouldn’t just be selling the road map. This idea that sales need to know what’s on the roadmap, sales needs to be able to sell the future, to be a little provocative — when I get to talk to sales departments and I’m like, come on guys, even used car salesmen don’t sell the future so you should be at least as good as a used car salesmen who can sell the car that’s in front of them now.
There’s a little bit of — I’m not going to say that all products should be able to sell themselves, but I would say that sales needs to be able to tell the product that they have today. If they truly can’t, there’s a very different problem to solve I think which is how do we make the product something that’s a sellable product. It might be that maybe the product needs enhancement, it might be that maybe the product has a low quality, it might be that there’s not actually a market for the product and those are some hard questions to answer for some companies. If they can learn how to sell first the product they have in front of them, then they can start leveraging some of these good technical practices. They don’t need to become engineers or even sales engineers, but they can understand concepts like continuous delivery, continuous deployment and they can understand that what product management does from a strategic fit. Like sales can learn to sell the fact that we’re sensing the market, sensing the direction that we’re doing it, that we’re getting it right, that we do care about customers, they can sell our support, they can sell our services, they can sell the fact that when we do sense the market that we do release things quickly, and they can sell the history.
Now, of course, a lot of places don’t have this history yet of being able to deliver frequently, deliver in small batches, so it’s going to take a whole team effort, like a whole organizational team effort to get better at market research, user research, fast, frequent deployment development, good support staff, good sales staff. They all have to work together, and they all have to swim in the same direction.
Joe: Here’s a software team here I have this product and the continuous deploying benefits and features to it and in such small iterations that I may not even know it’s happening; it just evolves. And so as a sales guy, I’m sitting here thinking what am I selling?
Matt: I’m a consultant so I would have to say it depends at least once, right? I think it does depend on the nature of what you’re putting into your software. Now if you’re talking about Gmail, or Facebook, or Twitter or whatever, sure, deploy the hell out of your stuff and you put some models in, you introduce users to some new features and maybe it’s not a big deal, but we are talking enterprise stuff especially any kind of software as a service-type product. It’s a bigger deal, and I think part of how product management is changing especially with SaaS solutions is they need to understand the true total cost of releasing their software to their clients. You can’t just push out any update, so we need to start thinking about what are the other categories we can push. How do we inform not just sales but a lot of times there’s a sales component, a support component, a professional services component. How do you keep all these people informed and in sync with what you’re releasing?
You could address this through having releases that are sort of fixed and like the stuff that’s coming up and this releases known and it’s either in or out, depending on if you make it or not. There are all sorts of ways of categorizing like if you’re doing small enhancements or fixes, then sure, maybe you can continuously deploy those. But again this kind of comes back to software as a service being about a relationship and about problem-solving for both sales and product management. Because if you don’t understand the nature of how your customers move as a market but also your actual individual customers are using your software, that’s not a problem that continuous deployment is going to fix. It might actually make it worse. Making sure that you understand what your customers are, how they’re using it, do they need to integrate to that, do they need to restart anything, can you just push them stuff whenever. Most shops are not awful with this, but I definitely see there’s still a long way to go.
Joe: I want to ask you about your upcoming presentation at the Ohio State Leading Through Excellence Summit. Can you tell me about that?
Matt: The summit itself, it’s a pretty cool event. I went three years ago or two years ago, and it seems to be a pretty cool event. They pool industry people together and some thought-leader type people together and it’s just a pretty good coupling of some sessions and some breakout workshop style things, and that’s actually what I’m doing. I’m doing a short breakout session workshop. It’s like 75 minutes, and we’ll have them do a little bit of a practical activity with concepts kind of laced throughout the time.
Joe: One of the things that jumped out at me was a couple of your mapping things – benefit mapping and flow-based road mapping. Can you briefly describe them for me? Is that what the presentations are about?
Matt: Yes, exactly. It kind of covers three main areas: flow based roadmaps, concepts of real options or options thinking, and then this idea of benefit mapping or how we rethink about development planning in general. The concepts behind flow-based road mapping, I’m not going to lie, it’s a lot of stuff that has kind of been borrowed from the studies and stuff that I’ve done with lean or like Kanban for software. Jim Benson is a friend of mine, and he wrote the book Personal Kanban and I really like that book particularly because it talks about some of the psychology planning in Kanban. There are other good books on Kanban out there. I follow a rule of you should read at least three books on Kanban; any three but start with Jim’s.
There are a lot of stuff in flow-based roadmaps that are just some of the basics; like visualize your work, we’re a work in progress, pull work through the system – so kind of pretty basic concepts like that. A lot of places might call this like a portfolio Kanban or an organizational Kanban. I try not to use the ‘K’ word too often, mostly because as it’s become a thing and people have written books about it, people start to understand it as a method and really what I want people to do is just start thinking about the roadmaps through the ones that flow. I don’t really care if it’s Kanban or a method or anything else, but I do want them to stop trying to make big, giant Gantt charts that are time-based schedules that don’t really help us coordinate flow throughout the organization.
Joe: What’s benefit mapping?
Matt: Sure. Benefit mapping is a way, one way – I don’t think that there’s a one right way to try to help collaboratively assess what the value, kind of the whole value is for some of the things that we might do that are in a roadmap. So part of what I kind of will be preaching a little bit about at this workshop is that a lot of software product development specifically sort of still uses a construction mindset when we do planning. So we over focus on things like costs, we over focus on schedule, we over focus on utilization and it’s not that those things are unimportant. It’s just that if we think about what the nature of development work is, maybe we should be focusing primarily on value, thinking a lot more about risk than we traditionally do and then keeping track of costs or understanding costs as sort of after we get going.
Part of one of my quotes would be something along the lines of ‘development work is work that by its nature has to be started to be able to be known.’ So there’s a lot of complexity theory, systems thinking, and that stuff. What benefit does is it’s a simple mind-mapping technique that gets whatever group of people into a room to start mind-mapping out the various benefits or value that could be created from a list of projects with options in a roadmap. From there, we just take those things; we identify kind of the key drivers of value. I usually ask people to kind of cope with a small subset because if everything is driving value, it’s sort of like nothing is. They just kind of rank them and weight them, and then kind of come up with a scoring rubric to be able to quantify some of these sometimes subjective things like customer satisfaction or brand awareness or things like that. We basically are able to use that to come up with like a benefit score which will help us understand things like cost of delay, and then we can use that as our value. We can divide that by whatever cost or duration we have to kind of come up with a benefit-cost ratio, and all that really does is both inform us the priority of work that we should be doing in our roadmap, but it also helps us understand what it’s kind of maybe costing us to not get that work done and don’t pay that work.
Joe: That sounds like a full 75 minutes.
Matt: It’s only 75 minutes. I might need to cut some content.
Joe: It sounds like you could have a book in the works. Do you have one?
Matt: That would be awesome. If I had enough attention span, I might write a book. It’s on my to-do-list.
Joe: Is there something that I didn’t ask that you’d like to mention?
Matt: I hope that more people would be interested in these kinds of things. I wish more people would come out and speak about their experiences and share them. I certainly don’t feel I have any special talent or trait that makes me able to do this, and I think the community as a whole, we don’t need thought leaders anymore. I mean that’s great to have people that are pushing the edge, but we need practitioners that are going and doing and trying new things and sharing with all of us what worked for them and what didn’t in their context so we could learn and apply that in our context.
Joe: I think that’s very well said. What’s the best way for someone to contact you and learn more about what they’re doing?
Matt: Well if they’re cool with my Twitter stream being quasi-professional and usually PG13, they can just hit me up on Twitter @mattbarcomb. They can email me. I have no problem taking emails. Matt@odbox.com.
Joe: Well I appreciate that very much Matt. I look forward to hearing how your presentation went, and I look forward to getting the Podcast out there and get some feedback on it. I’d like to thank you very much.
Matt: Great! Thank you.
Joe: This Podcast will be available on the Business901 iTunes store and the Business901 blog site. Thanks, everyone!
Lean Sales and Marketing: Learn about using CAP-Do