Ron Mascitelli is president of Technology Perspectives and author of five books, with his most-recent publication, Mastering Lean Product Development: A Practical, Event-Driven Process for Maximizing Speed, Profits, and Quality. 
One of Ron’s earlier books, The Lean Design Guidebook: Everything Your Product Development Team Needs to Slash Manufacturing Cost (The Lean Guidebook Series) was my bible through the years of product development in my manufacturing career.
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: Lean Design interview with Ron Mascitelli
Transcription of Podcast
Joe Dager: Welcome everyone this is Joe Dager the host of the Business901 podcast. With me today is Ron Mascitelli. He is a project management professional who served as Senior Scientist and Director of R&D for Hughes Aircraft Company and the Santa Barbara Research Center. Since founding Technology Perspectives in 1994, Ron has worked with over 100 leading companies worldwide to implement his highly practical approach to lean product development. He is the author of five books, including the “Lean Product Development Guidebook” and his most recent publication, “Mastering Lean Product Development.” Ron, I’d like to welcome you and mention that I have this dog?eared, written?in, pages?taped rag of an orange covered book behind me on my bookshelf. I want to thank you for joining me. Any updates to that introduction?
Ron Mascitelli: Thank you very much again for having me. It’s a pleasure. What it says, Joe, is that you need to buy another book. No, I’ve been excitedly working, of late, with a lot of medical products companies, in fact, doing more global work, working in both Europe and Asia. I’m always excited to learn new things. Every company I work with teaches me something, so it’s always a pleasure to work in new industries and work in new parts of the globe.
Joe: I enjoyed your new book. Could you let your listeners know what is new about it and different in the new book?
Ron: OK, very good. For as long as I’ve been working in lean product development, which is eighteen years now, it’s been a collection of tools. Whether it’s A3 problem solving templates or visual workflow management tools, things of that sort, it’s always been a collection of tools without really an integrated framework so that the tools have a purpose. There is a flow and a connection. And you can really visualize the how of product development, from the very beginning of selecting projects and managing the portfolio, all the way through to production. So this book really, for the first time, puts it all together into a framework. It’s an event driven approach, meaning that we’ve crafted a number of very specialized standard work events. Each event has a set of standard tools; standard preparation and well?defined outputs, and so these transformative events actually represent lynchpins in a process that really runs front to back.
I think the other new part of this book, and the material is that it’s really set up in such a way that it’s so modular that you can install it within an existing process and lubricate that process and get significant benefits. So, in a sense, you don’t have to throw out your old process and start from scratch you can use this actually and embed it within your existing phase?gate or stage?gate process, whatever you might have, and get the benefit immediately. Highly practical, very modular and intended to be a front to back picture of product development from a Lean perspective.
Joe: You can toss it in; it’s not just like throwing out and starting anew that you can actually supplement it to your existing process.
Ron: Absolutely, in fact, the number one obstacle I think I face when I work with clients is that they have invested, in some cases, a lot of time and often substantial money in putting in place some kind of governance process for product development. In addition to a governance process, such as stage-gate, they often have a product lifecycle management software that they’ve embedded, so they have key deliverables. If they’re in a regulated environment they have some fairly heavy constraints to regulation, and I think that a lot of companies are reluctant to embark on a new process when they have so much vested and so much time just getting the old one in place. That was one of my goals in this latest book, to come up with tools, methods, and a framework that could easily, in a modular fashion be embedded within an existing process and still give you tremendous benefit. Again, it lowered the barrier to entry; it makes it much open; I think, to any company that’s looking for improvement.
Joe: I can piecemeal, your practices into mine?
Ron: Of course, in fact, actually, I recommend that. There’s no reason, if you have something that’s working for you and your company; there’s no reason to fix something that isn’t broken. In fact, it is where I learn an awful lot of what I publish and what I teach, from companies that have found an excellent way to do the job. There’s no question; every firm has things that work well that they feel very comfortable with, and then there are those rocks in the road, the things that are obviously not going so well, and fix the things that are broken. So, in this case, you literally can create future state vision that’s an amalgamation of essence of class tools that I offer, with some adaptations to your company’s needs, along with what’s working for you. And literally do a kind of first phase improvement, then as you move forward you might identify some new issues as you move a little more smoothly and a little more efficiently, and then you can address those issues again with other tools.
Joe: How long as a process does it take to intertwine, let’s say, a new product development, am I talking that I can do this in three months, or is this more of a journey that I’m making?
Ron: It’s unquestionably a journey. One of the problems with product development, unlike manufacturing and applying Lean to manufacturing, is that the cycle time to learn is much longer. Even in fairly quick turn environments some companies’ products might be in development three to six months. That’s a fairly quick turn development and a lot of companies; their products take years, so you don’t have a lot of cycles of learning there happening very quickly. In general, we’re talking about; I like to say a year for the first phase improvement initiative. You should be seeing substantial benefits; you should be seeing both efficiency in terms of time to market and, probably more importantly; you’re seeing less conflict among projects, more predictable outcomes, higher-quality products, and hopefully more innovative products.
The idea really is, I think; to take it a reasonable bite at a time, try to do it in a non?invasive way, and imagine a year to implement, say, phase one. If the company has the initiative, you do phase two, phase three, ad infinitum, until you feel as though you have, you know I don’t think we’re ever happy with anything and the solutions. There is always an opportunity to improve.
You take your high priority stuff first. You make your quick wins, and you can probably again, in about a year; you can start seeing some really substantial improvements.
Joe: From your book, I came away with the understanding that the process drives innovation, and having a standard process, standard work, accelerates not only the cycle, but the ability to learn. Am I on the right path?
Ron: Yes, absolutely. One thing that is funny about product development is that product development is really a process that guides projects. Depending upon how common and similar your product development projects are, you can factor out a lot more of the project aspect and make it more of a standard process. I think it’s really a misconception to think of product development as being similar to, again, manufacturing or more office transactional processes, where we map it out and say, “This is what we’re going to do on every project, and then we’re going to turn the key, and it’s going to run.”
Every project is different, at least to some degree. Value creation happens as a result of those differences. The more unique, the riskier a project is, the more you have an opportunity to make a breakthrough in the marketplace.
So to overly standardize and create a “one-size fits none” process really doesn’t make sense. Whatever we do in terms of a standard process for product development; we want to have standard work, but it needs to be flexible. We need to have latitude to adapt to small or large projects, high and low risk, more or less complexity, et cetera.
I think the whole idea is to define a process but one where it’s more of a guideline for how we go through the transformation of knowledge, and also how we learn, and not so much a rigid structure like a very highly?detailed process map.
Joe: Well, you seem to be event driven, and I don’t mean time-based necessarily, like a scrum sprint or anything, but could you explain what you mean by an event-driven process?
Ron: After a number of years of trying to find a way to package tools and methods that I knew were working within a framework, what I arrived at was basically, to be honest, I was inspired by going on jury duty with 11 other people that I didn’t know and didn’t particularly want to be with, in a hot-stinky room with stale donuts. Our goal in life was to reach a verdict. It occurred to me that the conversation and the consensus that was built in that room fairly quickly, were built because people had focus. They had no choice, essentially. They were going to be in that room until they got an outcome, and it was so much more fruitful that if we had, for example, tried to reach a verdict by sending each other emails and having an occasional conference call. I mean, in that environment, I think we’d still be waiting for the OJ verdict.
It, ultimately, inspired me. I said, “Well, why don’t we package a set of tools?” For example, defining market requirements. This can drift on for months in some companies, with the wrong people in the room or scope creep, or someone comes up with something, and we throw something else in.
I have a new thing called the market requirements event, in which we actually pull together for a day, focused day, with a set of tools, collaborative tools that the whole team can use, and we focus on just market requirements.
Again, it is a standard work event, but it’s flexible enough to scale to the needs of the project. The outcome is a prioritized list of engineering design requirements, the scope of work to move forward in the project. And the other events, of course, hit at critical points within the process.
We’re not doing all the design work in an event. What we are doing, however, is those critical collaborative junctures. In a sense, this is a forcing function for fruitful collaboration.
Joe: That’s an interesting take on it, because it’s not necessarily a Kaizen event? What is it called?
Ron: No. Other than the fact Kaizen events are a great example of how powerful this kind of intensive collaboration with the high focus can be. But it’s not a Kaizen event in the classical sense of being continuous improvement. It is an execution event, where you have, again, a standard preparation in advance. Everyone, within their role, comes to this very cross functional event with preparation, information, and in some cases work done. When we get in the event, we follow an agenda of tools, discussion, and prioritization. Then ultimately, we have a standard output that determines the close of the event.
In fact, if we don’t close the event properly, if we don’t reach that outcome, we reconvene in a week or whenever we can, and we continue until we can reach that closure.
I think it’s a very powerful forcing function for timely decision making and for really getting all the voices together, looking at the same issues and problems, and answering the same question.
Joe: Do these happen at phase gates or control points of the process, then?
Ron: Actually, in my perfect vision of the world, the events become the phases and gates. Our market requirement event is a knowledge gate, so is our project planning event. The rapid learning cycle event, which is to burn down your early risk on a project, each of these, in a sense, are knowledge gates. So in my perfect word, we don’t use artificial governance gates like concept freeze gate and a detail design freeze gate or whatever they might be. We actually use these events as knowledge gates. But in most companies that already have a comfortable language of governance, we just embed the event at the appropriate phase, and it will give you the outputs you need for your existing gate reviews.
Joe: So it’s really a way of distributing all the knowledge, the needs and deciding on what knowledge you need to proceed with. Is that a simple explanation of it?
Ron: Perfect, perfectly well said. If you think about it, in product development all the knowledge that is needed to create the best commercial product in the world resides in the heads of the cross?functional groups that you have in your company. It’s all in there somewhere. All they need is a problem to focus on and the ability to somehow pull all of that diverse cross?functional knowledge together in a way that’s optimal. That’s what we’re trying to get at here. Really, it’s forcing collaboration, not just names on a list, “Oh yeah, we’ve got a manufacturing person on the team. See here’s Joe; he’s listed down here on the list.”
It’s getting them in the room, break down the barriers to communication, have a common vision and a common set of tools they use so that we really do get that consensus input. Product development can’t be optimized without the contribution of virtually every function in the firm at one time, or another.
Joe: Let me play devil’s advocate a little bit here. Is this just the Lean version of Design for Six Sigma?
Ron: No, not at all. Design for Six Sigma is really very much a tool box. It offers at best a problem solving framework. It does not offer a front to back transformational framework in which you start with the market needs. There are tools in there, for example, quality function deployment or house of quality, to do initial requirements. But there’s no clear connection. There’s no derivation of the knowledge flow. It’s really much more an amalgamation of tools.
The tools of Design for Six Sigma are, in fact, in some cases, embedded in my process. I use a Lean version QFD, for example. I use failure modes and effects analysis. Then any other tools that are successful that are working in your firm, you can embed in the process at the appropriate events.
The events are very flexible. I offer a generic framework and a generic description of each event. But you can enhance them in any way you wish by adding appropriate tools for design for manufacturing assembly, whatever is appropriate for your needs, design of experiment, et cetera.
So again, in a sense, I’m offering a generic starting point for a front to back framework from the very early stages of project selection all the way through to launch. But you can enhance it with the tools that are working for you. If you’re currently doing well with Design for Six sigma, not only is there no incompatibility, there’s a tremendous amount of synergy by folding those tools into the same framework.
Joe: You talk about the Toyota 3P process as part of that, which I’m going to say, is people, process and product. But is there a difference in yours, or do you embed that in yours and maybe why?
Ron: First of all, my definition of the 3P is production, preparation, process which is taken off the Toyota model. Toyota’s ideal situation, which I believe is the most highly evolved version of this, is true parallel product and process co?development. So the production process is being planned, conceptualized, refined, and ultimately implemented along a parallel path with the product design. There is constant communication between the two teams that are developing those things. So if there’s a decision made on the design side that impacts manufacturability that decision is consulted with the manufacturing folks, validated, and in some cases, tweaked due to feedback, and likewise on the process side. The effective end of this is that those two things come together, dovetail together in a successful launch. Of course, Toyota is notoriously good at that.
My approach is a little bit simpler to implement. It doesn’t require that you have literally thousands of engineers and a billion dollar budget. So I use three events that are surgically located in the project schedule in such a way that they give you the maximum input.
The first one is called the design 3P event, which is entirely focused on making design improvements and modifications to enhance cost quality and manufacturability. We then have a process 3P, where we discuss production plan, line layout, capital investment, and new tool and equipment facilities and layout. And there’s a production 3P, where we actually refine the line and do what amounts to a line Kaizen for launch.
There is constant communication in between those events. We use standup meetings, visual workflow management to keep the whole team talking. But these three key elements really are designed to have a process, and the product meld together as one system, as opposed to being treated completely independently, or even worse, where it’s completely over the wall. The design gets thrown over to manufacturing, and they have to somehow figure out how to do it. The goal is to force very early in the process of strong consideration of cost and quality.
Joe: When you’re operating these things in parallel, is there constant communication between the parallel branches?
Ron: Absolutely. The one thing that I sometimes have to caution clients on, because you’re using these collaborative events, doesn’t mean that the people go back to their cubicle and don’t speak in between. To enforce that, we use a visual workflow management technique, which is basically a combination of frequent standup meetings, totally cross functional standup meetings, combined with a visual project board that tracks progress, highlight major issues and risks, and allows that team to do dynamic planning of the next several weeks of their project to meet their milestones. In principle at least, the design folks and I hope the marketing folks, and I hope the manufacturing folks are all talking several times a week on an exception basis; it’s not a deep?dive discussion. But any issue that comes up, any change that might happen is voiced to the whole group, and every can act on it.
Joe: You touched upon something right there that jumps at me. It used to be that engineering product development was a very internal thing, and it’s becoming more and more external and including more open innovation. But what role has changed for sales and marketing in product development?
Ron: Those of us that have come out of the design side of product development have always been frustrated perhaps by the lack of good communication with manufacturing. And it’s a frustration that’s shared on both sides. We both know we should do better, but the mechanisms just aren’t there. On the other hand, perhaps the highest leverage in critical interface has always been between marketing?sales and the design group. That’s really the very earliest definition…you have an idea for a business case, how do you translate that into a set of requirements that’s the scope of work that will stay relatively stable so the designers can go off and be efficient in developing the product?
The role of marketing and sales has shifted from being more a fountain of business opportunities that’s somehow get thrown over the wall with tons of unnecessary detail, and in some cases, misconceptions about what can and can’t be done, into a much more collaborative role, where marketing is working with design engineering on what’s possible, what can be done at cost, what can excite the customer, so that’s really, probably the most fruitful interface that I’ve been working on.
And over time, I’ve seen it evolve from again, very much of a “thrown down from on high, go thou, and design this,” to a much more egalitarian approach where there’s constant conversation and feedback and listening on both sides. And that’s really where it has to go.
In some companies, even the organizational skill structure is setup where product management is in a completely different organization from engineering, design, management, and manufacturing. And over time, I’m hoping that will evolve toward a much more product?centric organization where marketing and product management are in the same group with the same status and the same kinds of discussions as the engineers and the manufacturing people who have focused on that type of product.
Joe: I always use the line that it’s no longer marketing’s job to get the message out; it’s just as much their job to get the message in.
Ron: Yes, absolutely. And you know; it’s great to have a vision, but ultimately, any one person in product development; any one function cannot optimize that system. If engineers, given some market need, come up with what they think is the best solution; it may be overshoot for the market’s needs. It may be overly complex. It might completely miss the subtle, empathetic understanding that the marketing people have. But likewise, marketing, though they may have the empathy with the client, and understand the voice of the customer, they aren’t really able to know what’s possible, what solutions could be offered, what could be potentially brought to market. So you have to have that conversation across that boundary and likewise, manufacturing has to be in that mix, to put a sanity check on cost, quality, manufacturability, capacity, etc.
So it really needs to be all functions working together from the beginning. Marketing takes the lead initially. Certainly, there’s a shift in Lean. In a sense, it flows from sort of marketing, a divisioning part of the process to the engineering and design folks during the conceptualization and development to the manufacturing as we start ramping up to launch. But there’s a constant quality of discussion to that whole process.
Joe: Now, you talk about sustainability in the back of the book and how has that affected the role of development? Or, has it changed development in any way?
Ron: That’s a good question. We’re talking here about ? to use the banal term “green design,” but a sustainable design is probably a much better term for it. It’s interesting, because I’ve actually seen a bit of a shift in the industry over the last 10 years from essentially completely ignoring it as an altruistic; you know, “Gee; I know we all should do it, but I just can’t make an economic argument for it,” to more recently where it’s become a key differentiator in some industries. There are a number of case examples of companies that have made significant market gains, and in some cases, significant margin increases by virtue of focusing on sustainable products.
What I will say is that it is a bit of a pendulum swing. I would say probably in my latest probing of the market; I would say that it has settled down to being one of many differentiators, where it had a lot of cache about five years ago. I think it’s settled down now to being one of the many considerations that customers have for the products they buy.
In certain markets, especially in things like architecture, interior design, décor, longer?term investment, it’s still very powerful. In other industries, it was more of a gimmick. For example, in some retail products, where everything is made of bamboo and everything is sustainably harvested. I’m a huge environmentalist. Of course, I hope there’s a business case, but I’m also a pragmatist, and I realize that if a company can’t justify the investment in sustainable design, by virtue of a market pull, then it’s just not the right investment for them. They have to wait until the market comes around to realize the advantages of a sustainable product.
Joe: Now we all have what I call Apple envy, when comes to innovation. I always thought the secret to Apple was the simplicity of their product line, and how they all intertwined. They built one upon the other. What are some of the lessons that we can learn from them?
Ron: Hire Steve Jobs. I mean, in reality, I’ve been watching Apple for my whole career. Certainly, both through their glory days early on, and then their dismal days when Steve Jobs left, and now of course, in the much more glorious present. I will first of all, say that you can’t take it with you when you try to be Apple, because that company was built on a single person’s vision. The more I read about it, and the more I study it, the more that becomes apparent that this was a not so benevolent dictatorship by a person who was an extraordinary inventor, really, a Thomas Edison of our era. Very different types of products, not fundamental basic things like, light bulbs.
In this case, a vision for an entire sort of social environment that involves physical products, but not just physical products. It involves whole different ways of purchasing things. Whole different ways of connecting things together. That kind of a global vision that’s so out of the norm is not something you can replicate. What you can replicate, however, is some of the, as you mentioned, maybe more mundane lessons, like, simplicity. I would say the number one lesson that I’ve learned, and I think other companies have learned is the importance of aesthetics, of ergonomics, of industrial design in products.
To take your product above a commodity today, you have to be working on what I call esteem value. Esteem value means the product doesn’t just do the functionality. Almost any good company,today,can deliver functionality. It does it in some way that is elegant. It’s cool. It’s exciting. It somehow feeds your emotions in a positive way.
We’re at the top of the Maslow’s hierarchy of needs in most products these days. We’re not looking at you…we need to have a way to drill a hole, or something basic like that. We’re looking for something that excites us that gives us a sense of personality, personalization, and again, sort of feeds our emotions. He was really the first to…going back to the first iPod and even before that. Certainly with the operating system, the Mac operating system. It really captured our imagination at a very human level.
I think that every company needs to re-look at their products and say have we taken the time and put in the detail to make this product appeal to people beyond just core functionality. This isn’t just retail products; this is business to business products; it’s the most hard-nosed industrial products benefit from more consideration about the human element and the aesthetic element of the product.
Joe: I’ve always looked at the concept of value, and use has become so important. When I look at value, of course the functional which is the easy part for most of us and what you touched upon just there, is the emotional and social side of value. I think that’s the predominant thing that needs to be looked at even from a product or a service anymore. Are you seeing that concept of value and use being used more in development?
Ron: Absolutely. There’s a number of examples but let me give you one that is very close to my heart. I travel continuously, and I stay at the relatively generic business hotels around the country, in fact, around the world. What I’ve noticed over the last 10 years is a remarkable transformation in the quality of service and the personal attention at business hotels. When I first started traveling 15?20 years ago I found that it was a terrible experience. You go there, and the person at the desk would barely look up; they hand you your key. You didn’t get any kind of amenities; there are no fresh little cookies that are baked for you. There was no water in your room. There are no little details that made you feel comfortable. Feel at least a little bit like you are at home. That has totally changed the marketplace today.
The companies that win in that business are the ones that have found a way, for an extra couple of dollars, to deliver that real personalized service that makes people smile, good morning, good evening. How was your day, how was your stay? All of that stuff has really changed.
In fact, what I’ve noticed are European companies that send folks to the United States to stay at U.S. hotels always comment it actually makes them a little uncomfortable because in Europe business hotels are still very Spartan and very sort of cold in most cases.
They come to the U.S., and they say, geez it’s early in the morning, and people are saying good morning to me, they’re waking me up. They’re really surprised at the level of service that’s being delivered. I think it’s true in not just service but physical products, as well.
Products that have gone beyond well it does the job, it does it really well. It’s a little engineering?centric, and we need to be broader than that. It’s the perception of value that determines marketability and price. People perceive value not just from performance. The best product doesn’t always win. The best marketed product wins. We really have to be careful not to ignore those. I think I seen a trend towards more awareness of that for sure.
Joe: So is “better, faster, cheaper,” dead? Is it gone?
Ron: To some degree, I think it is because I think the definition of better has changed. There’s no question that if you push a market into commoditization, right? Where there are many equivalent substitutes, the price is the only differentiator; the cheaper part always will bear out. But what takes you out of commodity, what can actually reboot an entire market is not cheaper, cheaper, cheaper, it’s someone that comes up with something that people say, “I hate to spend more money on a product like this but I’m willing to because I really want that. I want to be able to customize my running shoe to look just the way I want it to, so I’m the only one that has a pair that looks like that.”
It’s actually a strategy that Adidas is using. They have kiosks where you can actually go in and design your own shoes in Europe and have it delivered to your house as a perfect fit. That type of personalization, the discovered detail, I think is really dominating the best or the better part in “better, faster, cheaper.”
Faster is market?driven. It depends on the sector, medical products and high technology products in fashion, faster is critical. In other markets, it’s much more important to get the right product into that market than it is to race to market. And I think a lot of companies that have a little more time, are trying to spend the time doing some of this more subtle work as opposed to again, just cranking on the additional metrics of improvement, functional metrics of improvement.
I’ll give you a good example of that would be Dyson. Really, one of the great innovative companies and great innovators, Dyson, himself. Yes, he has the technology in there that’s very effective. He’s managed to shift the whole market place for vacuum cleaners away from “more amps is better suction,” which it isn’t, by the way, to an argument that says, “It not only has to do the job, but it has to do the job in a clean and healthy way.”
And most importantly, the industrial design associated with his products is just exceptional. Things like the ball that actually is a driven ball. And the vortex, which, by the way, is a classic example of perception. Yeah, you can have a vortex, but it doesn’t have to be visible, and it doesn’t have to look cool, but his does.
And so, when someone buys that product, it’s as much having something that feels like it’s worth some money than it is something that just happens to suck well ? pardon the expression. I would argue that he’s getting a huge premium in price over a standard traditional vacuum cleaner. Most of it is perceptive as opposed to functionality.
Joe: Yes and I think that’s a great example. I think you hit the nail on the head in that description. One thing you brought up there and we’re talking about faster, the more we talk about shortening the development cycle, isn’t it time that works against you?
Ron: There’s a time when any one product and metric development works against you. There’s no such thing. You can’t optimize a system by optimizing one metric in the system. In fact, you almost always sub?optimize it. So, for example, if you have an opportunity to spend a little more time on a much more creative, innovative, maybe even a break?through product, as opposed to just fighting the clock to get to the next trade show with something new to show, you are always going to be compromising your ability to be truly innovative.
Likewise, speed can often sacrifice quality. And in this marketplace, you really can’t afford that because most companies now, quality has become table stakes, and high quality has become table stakes. So, too fast ? I guess the best way to say it is that it’s entirely dependent on the business case.
If the business case for the product says that it’s hugely sensitive to its market entry point whether it’s timing to a trade show or a retail buyer’s window or seasonal then, you do have to contort your process around trying to hit those marks. On the other hand, in many cases, you can slow down in order to go faster.
Spend more time up front thinking about the product, thinking about the market, really coming up with the highest value solution, and time it appropriately, but not necessarily your fastest possible speed. It’s a balance between driving price through innovation, driving costs and quality through good manufacturability, and driving time, and any given product, even within a market sector might have a different mix of those to emphasize.
So this mantra of “let’s just be faster, faster, faster” is like a game of Whack?a?Mole. You hit speed, then you find out you have problems with quality, and so you whack on that one, and you find out you’re not being very innovative anymore, and so it is always I think the balance of them, and that’s one advantage to lean product development that it offers you a holistic way of attacking the problem. Eliminating waste is an unambiguous benefit to all three of those dimensions. How we spent our benefit is depended on the business case. But, eliminating waste is unambiguous, and we do have?we can get better, faster, and cheaper, if we get it all.
Joe: Is there something I didn’t ask that you would like to add to this conversation?
Ron: No, I think it’s been great questions, but I will make one comment just because it’s something that’s currently pressing on me a bit is, if you really look at how companies improve product development they work in many cases hard on the process, hard on the standard work, hard on the documentation. What they fail to realize is that product development, the number one attribute that determines product development success is the quality of the team leader. Ultimately, you can have a terrible process, and if you have great team leaders, they’ll find a way to fight their way through it, and you can have the best process in the world, and without good team leadership, you’re not going to get anywhere. I’m working now with several companies who develop very robust, whole career?length plans for how to develop team leaders over time.
You know, giving them initial responsibilities, growing that responsibility, training that matches with the responsibilities they’re gaining. It is the absolute crux of product development, a great team leader that’s both inspirational and to some degree charismatic, solid interpersonal skills, and also has the fundamental skill sets of project management, of decision?making, of technical analysis.
Having those guys, and they’re hard to find, they’re kind of a golden egg when you can get them, but you’ve got to develop them over time. And I think a lot of companies just throw someone at the top of the project and say, OK, follow the process, and it’s going to all work out, and it just doesn’t work that way.
The team leader manages the risk of the project, and if you don’t have a really great team leader that risk is going to bite you, at least in some cases, and maybe in many cases. So that’s certainly something that tends to get missed when we get to process focused.
Joe: I know you put workshops on regularly is there a particular workshop for team leaders?
Ron: Actually, no, I’m just now starting to develop a whole set of material on team leadership. I’ve been very hard?skill oriented for most of my careers. I’ve bought in, to some degree, that if you give people the right tools, they’ll be successful. What I realized is that I’ve reached my limit. If I don’t have great team leadership to facilitate events, to organize standup meetings and get the most out of team collaboration, I’ve reached the limit of what I can do. So, I’m pushing forward in a little more of a soft?skill, it’s not tree?hugging or singing Kumbaya, but it’s at least a relatively well?understood skill set maturity model and development process for team leaders. So, perhaps, in the next year or two, I think I’m going to be ready to write another book, but also certainly trotting out some new workshops on that subject.
Joe: I would look forward to it. This has been a very enlightening conversation. How can someone contact you, Ron?
Ron: Certainly, they can contact me just by searching me on the web. I’m pretty much everywhere. My email address is [email protected]; company name is Technology Perspectives.
Joe: Thanks again. This podcast will be available on the Business901 blog site and the Business901 iTunes store, so thanks very much, Ron.
Ron: My pleasure.
Lean Sales and Marketing: Learn about using CAP-Do
Marketing with Lean Book Series