The Role of Advanced R & D

The relationship between advanced research teams and their counterparts in product development is often fraught with challenges. Advanced R & D teams complain that their counterparts in Product Development don't know how to use them effectively and ignore their ideas. "We can't them to take action on our new product ideas - they just want to make more of the same." Product Development teams wonder what all those PhDs are doing up there in their ivory towers. "Why don't they come back down to earth and help us get products out?"

The key is to recognize that these are distinctly different animals, with different objectives. The key objective of Advanced R&D is to deepen the company's technical knowledge in ways that lead to breakthrough products and new business models. The key objective of Product Development is to use the company's technical knowledge base to turn out a stream of new products in response to the market's needs (spoken and unspoken).

Product Development stays focused on the next few seasons or market window. Advanced R & D looks out for the long term future of the company. A company in a rapidly evolving market that plans to be in business for more than a few years needs both functions, because breakthroughs rarely come on schedule.

The tension between Advanced R & D and Product Development is healthy for the company: it keeps Advanced R & D's big ideas grounded in the realities of the market, and it helps ensure that Product Development can incorporate new technology to address market needs with much less technical risk or invention-on-schedule.

In short, Product Development responds to the market while Advanced R & D develops the company's ability to respond.

PDMA's Role in Growing Product Development Knowledge

I spent last week at the PDMA International Conference in Orlando, FL.

I just have to say that Disney World is not a good place to have a business meeting where you want people to focus. All the cute kids running around with Mickey Mouse ears and the sight of the Magic Kingdom just over yonder don't contribute to a focused atmosphere. I'm not sure why that is - I've been to business meetings at beach resorts where the beach was a welcome respite rather than a distraction. But in Orlando, I'm always sitting in the meeting rooms wishing that I was riding Space Mountain instead.

Still, I always manage to meet one or two people at PDMA who make the trip worthwhile no matter what the setting or the agenda. This year, it was Mark Adkins of Kennametal. Mark has been involved with PDMA for many years, and he was a Lean Innovation champion for a nonprofit in Ohio in 2004-2006 (if I have my timing correct) before taking a VP position at Kennametal eighteen months ago. Mark and I talked about the efforts PDMA has made to learn more about lean product development.

I think it's naturally hard for some members of PDMA's leadership, especially those who have been around for a long time, to appreciate the value of lean product development. After all, they've seen a lot of trends come and go: cross-functional team, co-location, agile development, Robert Cooper's Stage Gate, etc. Some of these ideas prove their worth and get incorporated into NPD best practices, others fade away.

PDMA sees itself as the guardian of knowledge about how to develop products effectively. Its members have access to the NPD Body of Knowledge, the group publishes the Journal of Product Innovation Management for its academic members, authors "product development 101" books for new PD managers, and certifies New Product Development Practitioners. Given that lean product development has some of these "best practices" directly in its cross-hairs for elimination, it's not surprising that this group has taken awhile to get on board. Still, there have been signs of progress.

April Klimley, the editor of PDMA's Visions magazine for its members, has championed lean authors like Tricia Sutton, Gene Kania and myself. For the last four years, PDMA has had something about lean product development on the agenda for the International Conference - more some years than others, but it has been a consistent presence. Local chapters have put on presentations, or will do so in the coming year. I'm speaking at three chapters myself this year.

This year, Takashi Tanaka of Obeya fame presented as a keynote speaker, and they set aside a space for Tricia Sutton to do a demonstration of Visual Planning. I was there with a Lean Product Development Resource Center, and I gave a half day workshop on lean product development. After my talk with Mark, I would like to make sure that PDMA has a full day workshop and at least two other items on the agenda for next year's conference.

There are a lot of other people working with the lean world to raise lean product development's visibility. Personally, I've decided that I would rather work with PDMA to get these ideas to their membership, while we strengthen the Lean Product and Process Development Exchange to grow and share knowledge within the community.

I would encourage anyone who is committed to growing their ability to develop new products more effectively to check out PDMA, especially any local chapters in their area. The NPDP certification process is worthwhile, too as a way to ensure that you have studied best practices in product development - most of the stuff in the certification review is useful even for lean product development practitioners.

Next year's conference is at Disneyland. I'll just have to sacrifice my weekend to get Space Mountain out of my system BEFORE the conference this year.

Not a Brain Cell to Waste

I've been fortunate since I started my consulting practice. I've met some amazing people. I've had a lot of fun in places as diverse as Quebec, Minneapolis, Penang, Amsterdam, Orlando, San Diego and Providence, RI to name just a few. I've done well financially and I have enough people coming to me that I don't need to "sell" so much as just ask good questions of the people who come my way.

But that's not what gets me into every morning. If it were just about the fun or about the money, I wouldn't do it - there are easier ways to do both. No, the thing that gets me up every morning is my commitment to the engine of innovation, and its ability to solve problems that make peoples' lives better.

In yesterday's New York Times, Thomas Friedman wrote an article Georgia on My Mind (registration required) where he questioned the two political candidates' commitment to driving the engines of innovation. He took an American perspective on this - claiming that the United States must continue to invest in new technology development to thrive.

I take a more global perspective. I believe that we need innovation to solve many problems that don't begin or end at the borders of any particular nation: eliminating the possibility of terrorism as a tactic while addressing the root causes that foster it, finding alternative clean energy sources, solving public health issues, providing food and clean water to six billion people, bringing developing nations into the global economy, etc, etc. We are here because the engine of innovation opened up lines of communication and possibilities that we could not even imagine at the beginning of the 20th century. We have so many challenges left to solve in the 21st century.

The principles and practices of lean product development help ensure that we use the best of our knowledge to make decisions and eliminate wasted effort, reinvention, unnecessary activities, etc. so that we can solve these problems at the pace we need to solve them.

Whatever product your company makes, your shareholders, executives and customers need you to do it as well and as fast as possible. However your products contribute to the greater good (and we all do, somehow, or our products would not deliver enough value to sell), we also need your best work.

For all of us to live in peace and prosperity, we truly don't have a brain cell to waste.

The Chief Engineer Function

All the books about Toyota's product development system describe the critical importance of the chief engineer. Books like Jeffrey Liker's The Toyota Way have told the stories of legendary chief engineers like Takeshi Uhiyamada, chief engineer for the first Prius and Ichiro Suzuki, chief engineer for the first Lexus. The chief engineer is the person who shepherds a car through the development program, providing deep knowledge, a guiding vision and the day-to-day decision-making that create exceptional products.

With the recent ruling that Toyota's chief engineer for the 2007 Camry Hybrid died from overwork, it is no surprise that questions come up about whether or not a single person can handle all the responsibilities embodied in Toyota's chief engineer, and whether or not that role is required for an organization to reap the benefits of lean product development.

Of all the practices within lean product development, the chief engineer is one that is guaranteed to raise questions and eyebrows during my presentations. I hear everything from, "That can never happen here!" to "They just named me the chief engineer. What am I supposed to do?" Assigning a single person is impossible today in most U.S. companies because old conventional wisdom about product development discourages people from developing into the kind of person who can be a true chief engineer.

In American companies, even creating the role of a chief engineer is often fraught with political difficulties, because it upsets the power structure within product development. A true chief engineer will interact with engineering, marketing, manufacturing AND senior management in ways that run counter to the way most of us think about product development. If the company is ready for that type of disruptive change, this is a good thing - since the thinking patterns that resist the chief engineer are the same ones that slow down product development, increase costs and lower product quality needlessly.

For most companies, however, changing all those thinking patterns takes time. Rather than throwing a new chief engineer at the problem and hoping for the best, it is better to take a more measured approach while the company develops its lean thinking skills. If we can't assign a single person, we can at least ensure that the current product development leadership structure has the ability to perform the same integrating function as a chief engineer.

The "chief engineer function" is the ability of an organization to integrate its best customer, technical and process knowledge into outstanding products. One good first step is to tear down the wall between marketing and engineering, perhaps by assigning marketing leads who co-locate with their product engineering teams. I have seen groups assign a marketing lead and a technical lead - and then give them a shared office with just a few feet between them, so that they are in constant communication.

Over time, the company's needs and ability for a chief engineer will develop. As the company leans out its development process (especially project status reporting waste), develops a strong base of shared knowledge about its products and processes, and deepens its customer knowledge by having the senior technical staff go-and-see customers for themselves, the chief engineer function will grow. The people who are capable of becoming chief engineers will emerge - sometimes from unexpected places. At the same time, the need for this integrating function to happen as fast as possible will arise. At that time, it may make sense to designate a chief engineer - and then give that person everything he or she needs to succeed in that role.

Impedance in the Knowledge Flow

What things impede knowledge flow in your organization? Where are the places where knowledge flows - just not as quickly or as clearly as it could? Here are the top 5 sources of knowledge flow impedence I see in my travels. Which ones apply to you?

• High Noise - Low Content Communication Channels: Over-reliance on communication channels that tend to hide or distort information. These include audio-only conferences (especially those done late at night at the kitchen table to deal with time zone differences), slide sets with more than 1 slide for every 2 minutes of presentation, most email, memos and reports that are longer than two pages or anything that requires access to a system that is hard to navigate.


• Overloaded Resources: Don Rienertsen's Managing the Design Factory lays out a strong case demonstrating how overloaded resources slow down development. But did you realize that they also slow down the flow of knowledge? People juggling too many projects in too few hours will be driven to take shortcuts that stop the flow of knowledge. They will stop taking the time to talk to others working on similar problems to figure out how to share solutions, and they will resist requests to share their knowledge with others if it doesn't help them with their immediate to do lists.


• Artificial Organizational Barriers: knowledge-sharing works best in an organizational structure that is a balance of both strong functional and strong cross-functional teamwork. On the one extreme, departmental silos prevent knowledge from spreading to related functions. On the other extreme, product-centered teams don't share knowledge effectively across products.


• Lack of Common Engineering Tools: Knowledge gets stuck when one set of tools (product data management systems, for example) can't talk to other tools. This is one area where the benefits of standardizing on a common toolset is well worth the pain. Teams working on similar problems need access to each other's information in ways that can be easily shared.


• Complex Knowledge Management Tools So-called "knowledge management" tools often become write-only databases because it is too hard to store information in them, and then too hard to retrieve it. With new search technologies like Google Desktop, you don't need a specialized tool to manage knowledge. Simple, searchable file shares of electronic A3 reports may be all that you ever need.

As you can see, most of these barriers are structural - embedded in the organizational structure, culture and IT systems that support the organization. This list contains few ideas for quick wins. The companies that have strong flows of knowledge in their organizations have worked for it, relentlessly identifying and eliminating the barriers to knowledge flow.

What can you do? Individuals working on their own can greatly improve their knowledge sharing effectiveness by attacking the high noise - low content communication channels within their direct control.

If you lead a product development organization or work on a lean product development team tasked with improving knowledge flow, it would be worth your time to identify the specific impediments to knowledge flow within your organizations, and invest the time to fix them as part of your lean product development efforts.

A3 Reports: It's All About the Paper Size

I occasionally run into people who don't like the term "A3 Report" - they think it's an obscure title for a simple tool. An A3 report is a document written on either A3 (metric) or 11" x 17" (U.S.) paper - twice the size of letter paper - to capture the essential information about a problem under investigation or a piece of valuable knowledge. You can find examples of them here in my Resource Center.

I encounter a lot of people who want to call these things "knowledge briefs" or something similar. I'm normally fairly flexible about the language people use to describe their work. But I've been resisting this trend with my clients, for two reasons.

The first reason is that everybody else calls these things "A3 reports" - so if you want to find out how other people are using concise, visual reports to solve problems, you want to search on the term "A3 Report" to find the answers. For example, you'll find the excellent book released this year by Durward Sobek and Art Small called Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System.

However, that's not the only reason I resist. Answer this question: how long is a Knowledge Brief?

The only possible answer is "it depends on what you mean." However, an A3 report is - by definition - on A3 paper. If it's on letter paper, or it's two or five pages - it's not an A3 report.

The paper size drives the right behavior to foster rich discussion, true knowledge sharing and good decision-making: distill the problem to the essential information, keep all the essential information visible at all times and use visual models to improve the flow of knowledge. To describe your problem on a single sheet of paper, you have to think about what's essential, and you learn pretty quickly that it's easier to be concise when you use pictures and other kinds of visual models rather than text.

Occasionally, I'll run into a company that has difficulty with the paper size - maybe they don't have printers equipped to print that large, for example. However, the visual models on an "A4 Report" (letter sized or 8.5" x 11") have to be fairly small to fit, and the reports have to be distilled down to the point that essential information has to go on a separate sheet. If you print the missing information on the back of the "A4 report" you have just hidden essential information, since I can no longer see it all at once.

Rather than go that route, I would rather solve the mechanical problem of "how do I print on A3 paper?" The small expense of installing a few large format inkjet printers for A3 reports is far outweighed by the benefits of using a format that has been demonstrated to lead to faster, better decision-making.

Re-Reading Allen Ward

On a long plane flight yesterday, I spent some time re-reading Allen Ward's Lean Product and Process Development. I had first read the book in a blitz right after I got my hot little hands on a copy at the 2007 Lean Transformation Summit. It's been a reference book for me since.

This re-reading was prompted by my attempt to introduce some of this material into the introductory talk that I do about lean product development. That didn't go over so well. There are so many new concepts embedded in that book: the entrepreneurial system designer, trade-off curves, set-based concurrent engineering, development cadence, etc - that 45 minutes of speaking time isn't enough to scratch the surface of the material. There is a lot of dense information in that book, but it may be difficult for someone new to the field to figure out how to get a toehold on this new world of product development that Dr. Ward envisioned.

The answer to "This is great - now what?" is found in the foreward at the beginning of the book by John Shook and Durward Sobek, where they describe the LAMDA cycle of learning. The act of simply Looking at your product development process - not the forms and slidesets, but at the stuff you actually produce - is a good first step, followed naturally by Asking why? Why do we repeat the same mistakes? Why do we have design loopbacks late in development? Why was one product a hit and the next one a fizzle?

LAMDA didn't make it into this version of the book, which he wrote three years before his death - he hints at it, but the idea isn't yet fully formed. Later on, Ward and his clients recognized that LAMDA supplies the necessary foundation for lean product development. An organization's ability to effectively execute the other practices depends upon the quality of their LAMDA cycles.

LAMDA is the on-ramp for lean product development. It is easy for an individual to try on his or her own to get a taste of lean product development, and build the company-specific case for it, and it is the first thing that an organization needs to spread across development if they want their lean product development efforts to bear fruit.

String Quartet Uses Lean to Support Creativity

"Lean" has spread from the manufacturing floor into the accounting office, order fulfillment and occasionally even the strategy process. But a string quartet?!

According to Benjamin Wolff, Associate Professor of Music at Hofstra University and the member of a string quartet, lean principles help his ensemble and his students make the most of their rehearsal time, by improving the routine processes to free up more energy for the creative process. Professor Wolff gave an insightful presentation at this month's AME Regional Conference in San Diego.

Ben's presentation showed his quartet rehearse a specific piece for an upcoming recital. Without necessarily telling the group what he was doing, Ben began using lean principles to rethink the rehearsal process. For example, all four members of the quartet play string instruments that must be retuned at least once during the rehearsal. Ben has used lean thinking to reduce the amount of time it takes to tune the instruments, and to ensure that the tuning process produces a more consistent result each time.

The major takeaway from Ben's presentation was this: creativity thrives in an atmosphere of disciplined practice and routines. By using lean processes to standardize and improve the supporting processes (the microprocesses), the musicians have more time and energy to innovate where it counts: the musical interpretation.

LPPDE A Hit!

I spent last week at the Lean Product & Process Development Exchange, and it was wonderful! It exceeded my expectations by far. We ended up with around 100 enthusiastic and engaged attendees, give or take a few each day.

Monday was Workshop Day, with four workshops. The most popular was Jim Luckman's Value Stream Mapping for Product Development. That one was a bit crowded but very well-received. The workshop I conducted with Jamie Flinchbaugh, Leadership Skills for Lean Product Developers also had a nice group. This was the first time he and I had done this workshop, and we learned as much as the participants. We had an engaged group with lively discussion that took us where we needed to go. The two half-day workshops also filled up, and received good reviews.

Tuesday and Wednesday were the meat of the conference. The big surprise was the real-time debate between Ellen Domb, a TRIZ expert and Michael Kennedy, the knowledge-based development expert. Michael encourages his clients to understand the trade-offs inherent in product design, while TRIZ encourages developers to transcend trade-offs to find ideal results. The synergies between the two approaches became crystal-clear as the debate proceeded over the two days, and I am looking forward to seeing what the two of them come up with as they put their heads together.

The Open Exchange sessions on Wednesday also exceeded my expectations. We really didn't know what to expect. The participants nominated over thirty topics on Tuesday. Voting and combining narrowed those to eighteen topics for Wednesday afternoon, split between three sessions. Although our intention was to have small groups of ten or less, many topic groups became larger than that, and were resistant to splitting up. Instead, one group took over the hallway to get enough space for everyone, and another merged two circles into one. We had assigned a thought leader or presenter to each group to facilitate, and they did a good job of leading the discussion, whether the groups were a handful or much larger.

The topics included things like SBCE, Metrics, Global Product Development, SW Tools and Knowledge Creation and beyond. I participated in sessions on Synergies between Agile and Lean, Integration Events and SBCE. Many of the participants who planned to leave early were sorry to miss the experience. We will definitely do this again next year.

We also learned that many of the participants wanted more opportunities to learn about the basics of Lean Product Development. We will address that with a tutorial webinar series this fall, and with more targeted workshops next spring.

The week before the conference, the LPPDE Board approved the 2009 Lean Product and Process Development Exchange! We have already begun to look at locations and will announce the final dates by June 30, 2008.

I hope to see you there!

LAMDA is Fundamental

A client of mine helped remind me about how central LAMDA (Look-Ask-Model-Discuss-Act) is to lean product development. LAMDA is Allen Ward's expression of Plan-Do-Check-Act, which is itself an expression of the scientific method we were all taught in seventh grade science. It is the problem-solving tool that Taichi Ohno used to invent the Toyota Production System. If PCDA works for Toyota, then why do we use LAMDA for lean product development? Because Allen was teaching impatient Americans who couldn't wait to get to the Act step.

I was guilty of this myself. I would do a little bit of Planning, Do a little bit, spend a few quick minutes Checking and then run off to Act - if I bothered to do all the steps. More typically, we'd skip the Plan-Do-Check (we know what to do already and we know it's going to work), and jump straight to Act. Is it any wonder why casual implementations of lean tend to fade away?

Allen dug a little more deeply into the kinds of things that went into the Plan step to find out what was actually happening. He found Look: go to the source, get direct experience with the problem , then Ask: seek the root causes, look for reusable information. He found heavy uses of visual and physical Models to eliminate misunderstanding, improve communication and drive better decision-making by making a person's thought process visible to others. Then seemingly endless (to an American) rounds of Discussion to deepen understanding and build commitment before arriving at a decision. But the actions worked and the decisions stuck, saving enormous amounts of time and energy over implementing a solution that does not work, or revisiting a decision because it does not have everyone's commitment.

The LAMDA cycle is foundational to lean product development because product development is fundamentally about solving problems as effectively and rapidly as possible. The cycle creates the conditions necessary for deepening our personal technical knowledge and developing solutions that make the most of our organizational knowledge. It directly attacks the wastes of reinvention, unproductive meetings, organizational silos and product-centered development.0

For more information, check out my LAMDA knowledge brief.