» » next post - Jim Morgan: Great people make great products
« « previous post - Jim Huntzinger: It’s in the Relationship Process – Production and Product
Michael Balle

Michael Ballé: Learn to solve your engineering problems of today to design better products tomorrow

By Michael Balle, co-author of The Gold Mine and The Lean Manager - Last updated: dimanche, février 24, 2013 - Save & Share - Leave a comment

First, beware:  there be dragons. My advice would be to take out “rapid” and “deploy” out of the vocabulary concerning new product development work. Any mistake made on the production shop floor can be fixed by putting the process back the way it was and catching up the missed production over the night shift or a week end shift. Mistakes in new product development won’t appear for a couple of years, and can cost the company its life – so slow and careful is the order of the day.

The one catastrophic mistake to be wary of is to hire consultants to apply production-born techniques to product development processes, you know, 5S, VSM, re-engineering, A3s and etc. before you know what you’re doing and why. You might really regret it later. Without a doubt, the lean principles apply to NPPD and there are some specific lean tools, but the both the environment and the nature of the work are very different, so tools don’t apply in the same way. I’ve seen many disasters, and been party to some, so I’m now quite passionate about this: before jumping to chapter 2 of lean thinking, it’s important to spend a lot of time on chapter 1: what is value?

To my mind, the three main issues of lean product and process development are: 1) how do we create products that people like and buy, 2) how do we do so within target cost, which means not burdening the production and supply processes with waste and, 3) how do we do 1) and 2) effectively, in order to have a reasonable development lead-time and no over-run development costs.

I have yet to come across a smart way of prioritizing projects. As I understand it, lean thinking asks the same question in a very different way: what are your customer segments and what is the innovation takt in each of these segments. Customer segments in this sense are not marketing segments (young professionals, couples with babies, active seniors, etc.), but groups of customers with stable preferences. I recently flew to Italy with a colleague with a low cost airline and hated the experience. We have very similar profiles (sociological type), and are flying together as part of the same job (usage) and yet are in different segments: he prefers low cost, and accepts the indignities imposed by the airline, I’d rather spend more, and travel more leisurely. Segmenting your customer base correctly is probably one of the most strategic choices of the entire development process, and in many companies I know, this is implicit and rarely looked at. I’d say the first activity is to hansei the segmentation.

Then, on each segment, we can pick a takt at which we know we have to release a new product for that segment. It can be a matter of weeks if you’re making mobile phones, or decades is you’re selling glass jars, but in any case, there will be an innovation takt in your business, and customers will expect a rhythm of releases – and buy from the first (or more regular) to market. As you take a step back, you’ll soon see that establishing a takt by segment quickly runs into capacity issues, and forces serious prioritizing decisions. The question is no longer to come up with the product that will take all the market, but to come up with a product in order not to lose existing customers on the segment.

The second strategic decision to make once the rhythm of each segment is defined is the choice of “chief engineer” to design the product for this segment. The chief engineer is the creator who will deliver the product – and thus who will turn his or her understanding of customer requirements into technical parameters. The success or failure of your product depends on his or her skill in doing so. For instance, when Toyota imagined it could create a luxury brand out of nothing, it expressed luxury customers preferences as “the drive of a Mercedes with the comfort of a Cadillac.” One of the many aspects of this challenge was the luxury aspect of the car. The chief engineer then decided that the gap between panels was key to giving an impression of “German made”, and then decided the panels of the first lexus would fit more tightly by half than in any other car in the industry. As you can imagine, this came with armloads of technical issues – which Toyota eventually overcame. The chief engineer turned a customer perception, the feel for German-made, into a technical parameter. In this case, he got it right, and the car was a runaway success. But Toyota is not always so successful, particularly with less experienced chief engineers. Who designs the product (for what segment) is the second important decision you’ll make – like choosing the director for a movie project.

Before design even starts, the next step is to figure out how to cost-effectively make the design imagined by the chief engineer. This involves a number of activities such as tear-down of competitor products (most companies sorta kinda do that, but in lean, tear-down is a center-piece activity), visiting factories and suppliers so see what existing processes can handle quality and cost-wise, and what they can’t. The aim of this early stage is to separate what we already know how to do and what we don’t. At this stage, it is critical to identify the few technical issues critical to the success of the product that can’t be handled by today’s manufacturing techniques.

The unique lean practice is then to explore various alternatives on how to solve these problems, all the way to manufacturing. The idea is not to jump on the first available solution, but to develop competing possibilities as far as possible, although we know we won’t use several of them. The focus is on learning and understanding as much as we can about technical problems we have no experience with. Customers are not part of our learning process. Because of that, we invest heavily in the upfront part of the process to explore deep technical issues before they blow up in our faces downstream.

This for what we know we can’t do. On the rest of the project, the main lean notion is to develop as close as can be to existing engineering standards. Standard mostly come in the form of checklists resulting from intense work with manufacturing engineering. For any new design, it’s essential to know at the time of conception what the manufacturing process can (and cannot) handle. Engineering standards are the hidden part of the lean engineering iceberg. Standards concern main technologies by functional families, detailed technical process capabilities, standard costs for current parts, technical solutions used by competitors, standard performance of various technical alternatives, reliable suppliers, points of attentions on drawings, anything, really that impacts the engineering know-how.

In order to be able to develop a new product at takt, on time, and with minimal fuss, the gist of lean engineering effort lies in continuously developing standards and checklists in an on-going collaboration between manufacturing engineering and product design. In my experience, the hard part of applying lean thinking in product development is not so much about product design itself, but the foundation of collaboration between product functionality and process realities that first need to be established through constant problem solving: first, customer related quality problems, then quality problems spotted at the end control on the lines, finally quality problems spotted on the station itself. Joint problem solving is the key to developing both the relationship and the checklists which can then support more upfront work in designing leaner products.

To answer your question more specifically, I’d not worry so much about the product pipeline in a product by product way, but focus on drawing out a product strategy based on customer segments, and a rhythm of new offerings demanded by the market. Then, before shooting from the hip and starting any lean program to speed up the development cycles, I’d take the deep dive in getting product engineers work with manufacturing engineers to solve existing quality issues and start developing both a working relationship and the experience of work standards. This will, in all likelihood, dramatically impact your product reputation and current sales. The next product’s development can then be designed with 1) customer preferences and 2) engineering standards in mind. Ironically, these very standards are the main source of true flexibility at the customer front end. By mastering engineering standards, you can identify the few open-ended problems you want to resolve before kick-off of the design process, and, once these are resolved, have a detailed design phase that delivers on time without mishaps (the ever-elusive goal is zero engineering changes after tooling ;^)).  Learning to solve the engineering problems of today is the key to knowing how to solve the engineering issues of tomorrow.

Post to Twitter

Share this post...Tweet about this on Twitter
Share on LinkedIn
Buffer this page
Share on Facebook
Email this to someone
Pin on Pinterest
Share on Tumblr
Posted in Uncategorized • Tags: , Top Of Page

Write a comment