Innovation Agility

Toyota’s product development system is particularly notable for the contribution it makes to the company’s overall performance. The company’s quality-oriented design philosophy reduces product costs; the greater durability and reliability of its vehicles reduces warranty costs. This in turn provides more capital for investment in innovation, while keeping the R&D spending low as a percentage of revenue. With increased capital and shorter R&D cycles, Toyota can launch more new vehicles than its competitors in the same timeframe, trying new designs in the market sooner. Faster market feedback means less reliance on long-range “guesses” about customer preferences three years hence. This significantly reduces Toyota’s market risk.

For example, Toyota had the cash in the 1990s to be able to make long-range investments in hybrid (gasoline–electric) technology without needing immediate returns. This experimentation made it more probable that the Toyota hybrid lines, such as the Prius, would eventually become market leaders. In March 2007, Toyota announced an even more audacious goal: to create a new standard computer operating system, the equivalent of Microsoft Windows for automobile-based computer systems, to be released by 2015. For Toyota (or any company) to credibly pursue two such dramatic goals in tandem requires a virtually unprecedented product development improvement capability — a process that bypasses the costs and constraints of conventional R&D methods, and that reinvests the money saved in improving its product development even further.

It took Toyota 60 years to perfect its product development process. Fortunately, your company need not wait that long to incorporate the same type of magic into its work. The trick is not to replicate Toyota’s practices (or those of any other company) piecemeal but to find your own way to achieve the same result: an innovation process that bypasses the costs and constraints of conventional R&D methods, and that continuously reinvests the money it saves in further improving its product development.

Foundations of Success
Toyota’s product development process focuses on carefully building and nurturing a set of six capabilities that are precisely orchestrated to enable the launch project to succeed. (See Exhibit 1.) The six elements form an internally consistent, self-reinforcing system:

Structure and Organization. Development teams at Toyota have struck a fine balance between their program and functional organizations. The shusa, or chief engineer, runs the program, while a bucho, or department manager, owns and runs each of the various functional engineering teams — power train, electronics, chassis, and the like. Despite his or her responsibility for the success of the program, the shusa has minimal staff and no direct authority over the functional engineers; Toyota relies not on positional authority and compliance but on its culture — with a shared goal of program success instilled broadly through the enterprise — to make it all work.

Development Process. The Toyota development model incorporates several elements to increase resale, maintain schedules, and deliver value. Each program essentially has a custom-designed development timeline that incorporates concurrent engineering (simultaneous product and manufacturing design), early systems integration (with a great deal of communication among engineers on product launch, an activity that is often seen as a waste of time in other companies), and cross-functional checks (early coordination and testing to be sure that different aspects of a vehicle will fit well together). This intensive form of coordination, which has been compared to that of the Apollo 11 moon-landing mission, allows Toyota to run parallel-path development, manage design and engineering trade-offs, and ensure flexibility. The result is significantly lower project risk than a process based on compliance, with sequential project goals, would have.

For example, when Toyota’s managers conceive of a program, they investigate multiple approaches up front. At least one of these approaches is a fallback plan. It may not be the perfect technical answer to the problem, but it is reasonably certain to work within the timeline available. Engineering teams work simultaneously to develop this backup solution while they also prepare one or more other options designed to push the state of the art on functionality, space, weight, cost, or other important design parameters. Once the date for the integrating event arrives, a decision can be made on whether the “new” technology is ready. If it is, great. If not, Toyota turns to the backup solution. And the knowledge gained while investigating the new solution is not just thrown away. It is systematically captured, ready for use on the next program.

Extended Enterprise. Product development for critical components is handled by the long-term suppliers with whom Toyota has invested in innovative capability. (See “Win-Win Sourcing,” by Bill Jackson and Michael Pfitzmann, s+b Summer 2007.) Toyota’s suppliers, who happen to have the soundest financials of any Tier One suppliers in the world, are highly motivated partners in the company’s R&D efforts.

Institutional Learning. Toyota depends heavily on capturing and sharing the knowledge and experience of its people. (H. Thomas Johnson and Anders Broms’s book Profit Without Measure [Free Press, 2000], for example, describes how employees’ in-depth awareness of production and innovation processes eliminates the need for financial and quantitative controls.) The company makes systematic efforts to capture this knowledge, institutionalize it, and make it available to everyone in forms that allow them to assimilate it and act on it.

People Development. At Toyota, monozukuri (“making products”) emanates directly from hitozukuri (“making people”). The company takes great time and trouble to develop its best people. Its engineers, for instance, typically spend several months at the start of their career in sales or manufacturing positions to broaden their experience. The system reveres technical and functional excellence, and nurtures it in every way possible — in part through a strong mentoring system. One example is the shusa role itself; it’s not just their positions, but their required high levels of technical and managerial skill that place these individuals prominently among the company’s true “car guys.”

Culture. The success of the Toyota product development system ultimately depends on the company’s strong culture, which centers on a number of core values, including personal accountability, continuous improvement, collaboration, and elimination of waste.

Your company’s product development system may already have some of these qualities. At the same time, entrenched practices and mind-sets may hinder your ability to realize your innovation potential. The key is to be realistic about your current approach, to design a more agile and value-based alternative, and then to develop a plan to incorporate these ideas over the course of several years. The progression of change would not map directly onto the components of the new system — for example, you would not work first on structure and organization, then on the development process, and so on down to culture. Instead, you would embark on a set of initiatives that might look something like what follows.

Rethinking Goals
Competitive advantage can be defined as the spread between the cost of making your product and its value, as perceived by customers, relative to that of your strongest competitor. Companies can widen this gap by increasing perceived value, reducing manufacturing cost, or both. The overall competitiveness of any research and development operation is thus determined by its contribution to increasing this spread over time.

The Toyota R&D system is, in fact, explicitly directed toward widening the gap between product value and product cost. Since value is defined by the customer, Toyota’s up-front conceptual designs concentrate on clearly articulating the product’s customer value proposition. That includes the explicit articulation of ambitious and apparently contradictory goals for each project, from the 1989 Lexus LS400 to the 1997 Prius.

Toyota’s approach to competitive advantage sounds straightforward and logical. Yet many companies take the opposite approach. When they launch a product development program, they start out by focusing primarily on the cost target rather than the value target. This policy — whether explicit or implicit — hamstrings their ability to create any true competitive advantage. For example, they become incapable of distinguishing the fine product details that customers truly value from haphazardly executed “shovelware” (features that are easy to include but that customers ignore).

Therefore, the first step in an R&D change initiative is a significant focus on customer value, with intense  participation by the most senior executives in product development. Your R&D operation undoubtedly has market research and customer satisfaction inputs, but go back and look frankly at your past launch records. To what extent have these inputs yielded significant knowledge about your customers’ needs? To what extent have you incorporated these inputs into your designs? When you have overruled them, on what grounds have you made those decisions? What questions about your customers’ needs and desires remain unclear at the product development level? Since every company is different, the answers to these questions will vary — but the time you spend answering them should be substantial enough to reveal the information that has not occurred to you so far, or the reasons that improvements have been difficult to implement.

These sessions can also provide an opportunity to rethink your supply chain relationships — with both suppliers and distributors. If you work for an automotive company, for example, to what extent do dealers contribute their customer awareness to your product development considerations? How much insight do suppliers provide into component design, and why do they propose particular features? To what extent can a more knowledge-based sourcing model help you reduce your product development costs and time frame?

Developing Long-Term Talent
The next step will be to reconsider how you develop your engineering staff, from the bottom to the top of the product development process. The best approach will not be the same in every region. Toyota benefits from a rigid labor market in Japan, where turnover is very low, especially in the automotive industry. Fast-track engineers in North America and Europe, where turnover is higher, expect to rotate through a variety of functions as they rise through the ranks. As engineering shortages continue, there is a real danger that high performers will walk away, preventing your company from building and retaining a strong engineering knowledge and experience base. Rethinking your people development strategy thus requires balancing the inclination to build functional capabilities through long tenures with the desire to provide wide-ranging experiences for the engineers. Your resolution of this dilemma will shape the identity of your engineering leadership.

If a single element of the Toyota product development engine ties the entire management process together, it is the shusa. Few Western companies have product development program leaders with similar long-term continuity, technical experience, and business acumen, and fewer still imbue them with the authority to carry a program through to completion on their own terms, and without much interference.

The shusa’s responsibility is wide ranging. As the chief engineer, he or she is responsible for the technical success of the program, making key decisions regarding system specifications and performance. The shusa personally signs hundreds of drawings and is deeply involved in technical decision making. He or she is also the general manager responsible for the critical cost side of the program’s business success — involved in product planning, in market research, in focus groups, and generally in defining the ways a product will create value for the end customer. Although other stakeholders influence the car’s price and volume targets, the shusa’s ability to meet cost/value targets governs the overall success of the project.

By investing the shusa with these multiple roles, Toyota gives that person the authority to quickly and effectively make the necessary trade-offs between technical and cost requirements for the benefit of the program. But this shusa-style authority can be vested only in someone with the technical skills, business acumen, and managerial experience to warrant it. And developing such skills takes time: At Toyota, becoming a shusa is a 20-year process in which promising engineers, with a good 10 years of experience in a particular functional area, are promoted to assistant chief engineers, where they need another 10 years of seasoning before being promoted to shusa.

Is it appropriate for other companies to develop a shusa-style chief engineer? We believe it is, but not in a vacuum. First, establish for each significant launch a single person with authority over and accountability for engineering-related decisions. This should be the most qualified person available — someone with top engineering skills, business experience, and management clout. Then look freshly at the career paths of engineers throughout your company. Like Toyota engineers, for example, perhaps they should begin their careers by developing deep technical expertise in a particular discipline. They may also need to spend time working with marketing teams, deepening their understanding of customers. As they move up the hierarchy, they would assume broader responsibilities within vehicle programs while still representing a specific function. And in doing so, they can serve as mentors for junior engineers, transferring both their explicit skills and their tacit knowledge.

You may choose to emulate Toyota’s approach to shusa candidates; top engineers shift into product planning and project management, where five years or more is spent learning how to lead vehicle programs. This period is intense: The candidate must master technical competencies in areas beyond his or her functional specialty, while developing the ability to make complex technical decisions as a vehicle development leader and to supervise an organization made up of several hundred program engineers.

Having rethought future career paths, examine the promising engineers in your current operation. What gaps exist in their backgrounds, including gaps in customer, operations, or financial knowledge? How can you use cross-platform training and mentoring to fill those gaps? What incentives can you put in place to help each candidate develop more in-depth capability? Can you use resources outside the company, including rotation through jobs at other companies or in university programs? How can you build the kind of trust and investment that leads your most effective staff to commit their future to the company?

Leveraging Function–Product Tension
A typical product development program must balance an implicit tension in the organizational structure. On the one hand is the goal of making everything different: distinguishing product features to give them market appeal. On the other hand is pressure to make everything the same: to scale production and reduce costs. At most companies, this tension manifests itself as conflict between the overall product development leaders, who champion differentiation to target their markets more precisely, and the functional leaders, who support many different products and seek as much commonality across them as possible.

Rather than try to resolve, or deny, that tension, you can leverage it for more effective product development. At Toyota, the functional areas are led by buchos, who occupy the same level in the management hierarchy as the shusas. Buchos are evaluated not just on their ability to run their functions efficiently, but also on the ultimate success of the development programs they participate in, so it’s in their interest to cooperate closely and productively with the shusas.

Translating that spirit of cooperation to a Western context isn’t easy, because it demands aligning the goals of all product development programs as tightly as possible. It won’t work without two types of people in place: a true chief engineer for every program (a shusa equivalent) and every functional team (a bucho equivalent). Both individuals must have the experience to succeed and the respect of all players on their teams. A successful R&D career at such a company may include time spent as both a shusa and a bucho — and, most importantly, time spent internalizing the needs and priorities of both sides.

Reclaiming Knowledge
Most Western companies take a process-driven approach to product development, involving elaborate handbooks, compiled over decades, that prescribe hundreds or thousands of deliverables, checklists, and coordination meetings — all no doubt good ideas when they were developed for some long-forgotten project. But because engineering teams rarely have the time, resources, training, or inclination to meet all these requirements, management often appoints “process police” who are charged with driving compliance with the handbook, while mandating sparsely attended, high-level “gate reviews,” all in the name of keeping the program on track. Well-intentioned as the system may be, the result is a project development team that spends far too much time — and money — on compliance and reporting, and not enough time on experimentation and technical problem solving.

Instead, establish an event-driven approach in which various key decision points (events) are laid out in sequence, along with the engineering results that will be needed to make each decision. Hold your engineering teams accountable for meeting various technical objectives by a specified time. In the course of their work, they may use checklists and procedures to keep track of their progress. But leave that to their discretion. Invest your oversight in helping them make better technical decisions based on rigorous data and experimentation.

Simultaneously, refine your knowledge processes: your means of capturing information about processes and products and making systematic use of that knowledge. Expect design engineers to maintain their own benchmarks, industry standards, technology trends, and supplier data for the components they work on. That might include the creation of checklists, trade-off curves (plotting diagrams of component performance), A3 reports (detailed breakdowns of technical problems, which take their name from the A3-sized tabloid paper on which they are plotted), teardown analyses (detailed evaluations of competitors’ product costs), and other quality-oriented forms of observation and analysis. Engineers should also be trained to synthesize this information and articulate what it means in the wider scheme of the product development process.

A well-designed knowledge-building process will help you build both technical problem solving in the short run and more extensive capabilities in the long run. This type of learning doesn’t just happen. To develop such a system of your own, you will undoubtedly apply information technology in innovative ways, but the most important aspects are human: engineers continually thinking about the significance of what they observe, and management continually rethinking the way knowledge is put to use. Can you design a system in which engineers “pull” the knowledge they need, as they need it, rather than having someone “pushing” knowledge at them? Can you manage such critical processes as teardowns so that every engineer is responsible for his or her part in the process? And can you institute a more effective program “postmortem,” capturing and institutionalizing the lessons from each launch, to the benefit of future projects?

Instilling a Flexible Risk Ethic
Every product development project brings with it inherent risks: technical risk (will it work as planned?), schedule risk (will it be ready in time?), market risk (will people buy it?), and financial risk (will pricing, costs, volume, and program life come together in such a way that you can make money?). Many companies aspire to eliminate risk by embedding a system of constraints in their product development processes. When programs go over a cost threshold, miss deadlines, or leave too many problems unsolved too long, “red flags” are raised that bring unwanted attention and sometimes penalties. Then all work on the project halts while the issue is dealt with, often in the hastiest manner possible to bring the project back into line.

A company can be much more productive by instilling a flexible risk ethic, making people accountable not for compliance with process rules, but for results. But that’s doable only when the company has confidence in the system, in the people, in the capabilities that have been put in place, and in the project’s leadership. For Western companies, that means reinforcing the shift in authority embodied by the chief engineer: He or she presumably has the experience, knowledge, and authority to manage risks flexibly and to determine the trade-offs necessary to keep the project on track. You may need to set up a council of engineers, to establish the backup that even the best engineers may need when considering risks and trade-offs.

Getting Started
Some companies facing this unfamiliar way of organizing product development may start with a pilot project. Choose a manageable development project such as a new component, not an entire new product platform on which the future of your company rests. Find a chief engineer — a natural leader — to head up the project. Provide him or her with the tools and the authority needed to begin creating a system for capturing and institutionalizing the knowledge gained in the course of the project. Give the chief engineer freer rein to work collaboratively with suppliers. And most importantly, give him or her the power to rethink and transform the business goals of the project — from profit to value.

We have also seen companies succeed through a more comprehensive effort, driving changes systematically across their organization. Either way, the first task is to develop a value-based goal — and then the kind of structure, people development process, knowledge capture process, and approach to risks that will reinforce that goal. Within a year, you should know if you have succeeded, because success will breed success: More of your talented and ambitious engineers will work toward building the technical expertise and business savvy that could give them a chance at becoming a chief engineer. The functions will strive to align themselves more tightly with successful product programs. The value of the knowledge captured will become apparent in succeeding programs. And suppliers will sign on, knowing you’re on their side.

Finally, the transformation will become part of your corporate culture