A Few Nuggets on Lean Product Development
I have spent as much time on lean product development as I have on any other area over the past 10 years. That’s largely because, for most companies, manufacturing products a little faster or cheaper is nothing compared to the overall business results delivered through a stronger product-development engine.
I’ll have more to write and share on this topic in the future, but in the meantime, to trigger some thoughts that are worth sharing, I listened to this webinar (archived, which you can listen to here) by my good friends at Lean Frontiers. The interview is with Norbert Majerus, the Lean Leader responsible for driving lean in Goodyear’s R&D organization, and the story is captured in his book Lean Driven Innovation. Norbert is one of those in lean product development who spent a significant amount of time with a deep, hands-on transformation before becoming a consultant, and he’s been a tireless advocate for better practices in lean product development.
The topic of the webinar was that fast is better than slow, but the webinar did not go in-depth on this topic as it was a teaser for a now-past conference speech. Of course, when it comes to technology and product development, we can agree that fast is better than slow.
Three points came up briefly in the interview/discussion that I would like to elaborate upon:
Make problems visible
Every problem should be visible within seconds. When you go into a huddle or huddle room or team area, it should be visual enough to see where the problems are. This is often the difficult work of lean in product development. It often involves trying to make the work both better defined and more granular. For example, if you measure tasks in weeks, start measuring them in days, and problems will become more visible.
The result is that you have the ability to address problems early without even knowing or worrying about their eventual impact. If you address those problems immediately, they are much easier to solve. Take this analogy. If you’re driving along, using a map, and only stop to look at the map when you need to pull over for gas (the old way), then your granularity is very low, and if there is a problem, it has potentially grown into a big problem. If, however, you have the high granularity (almost infinite) of GPS, then as soon as you make a mistake you know you’ve made a mistake, and the consequences generally remain very low. The point is this: make the work visible at a granular level and you’ll be better able to maintain predictability and ultimately speed.
Where is the waste?
I have disagreed with people who have argued that the traditional types of waste don’t apply to product development. Most efforts to create new lists of waste types are articulating common causes of waste, but these still end up causing the traditional types of waste at an observable level. Most of the waste in product development is created from overburdening or uneven workflow. Partly because we haven’t made the work visible, as noted above, workflow problems such as bottlenecked resources are very difficult to see and solve. This is particularly true for shared resources that become the bottleneck because everyone can see (usually through experience) that they can solve their problem just by getting their work moved to the top of the list. Of course, this solution cannot scale for the whole organization, and efforts to prioritize the work often mask the real problem which is to relieve the bottleneck.
Standard work in a non-standard process
Technology and product development don’t often follow a linear path. Problems are encountered, forks in the road taken (thanks Yogi!), and loop-backs are necessary in product development processes, especially when you start pushing into new territory.
So how does standard work apply?
Standard work has a place in R&D and product development. You gain quality, especially speed and flow. You don’t want to waste your energy, or that of your key resources, on thinking through basic tasks. Instead, you want people focused on the higher-level thinking necessary for success. This comes in standardizing things that are repeatable, such as criteria for making key decisions, or criteria for preparing a product test. The most productive things to standardize are the connections between resources. This is because you don’t know WHEN a connection needs to be made, but when it is needed, you need that connection to be effective and timely. Otherwise, you end up with errors and delays.
The interview in the webinar is a buildup for a LPPDE (Lean Product and Process Development Exchange) conference. It is a non-profit that has been around for years and has an emphasis on the E = Exchange. I have keynoted their conference twice and while smaller than most conferences, I’ve always found the spirit to be highly collegiate and learning-oriented. I recommend giving it a shot if you can.