How Do You Know What Your Product or Service Needs to Be?

To answer this you need to consider both the customer and the business needs. As the best product from the customer’s perspective without a viable business model is all waste. And without customers it is hard to have a viable business model.

From the business perspective you need to figure out:

  • If you can make money.
  • If you can design it.
  • If you can build it.
  • If you can distribute it.

Though without a customer for the product it doesn’t matter how well you do any of that. Without diminishing the importance of the business needs, how can we understand what the product needs to be for the customer?

You could ask your customers what they value, but that has limitations as this quote attributed to Henry Ford[i] points out:

“If I had asked people what they wanted, they would have said faster horses.”

So if you can’t just ask your customers, what can you do to understand what your product or service needs to be?

At Toyota, and other companies that have embraced it, the chief engineer immersion process is used to understand how current and potential customers will use the product. For example, Yuji Yokoya the 2004 Sienna chief engineer drove in every U.S. state, all provinces and territories in Canada, and throughout Mexico to understand the North American market, which led to many design changes[ii]. In addition to experiencing the North American market, he also observed how vehicles were used including Americans loading 4’ x 8′ sheets of plywood into competitors’ vehicles[iii]. This deep understanding of what the product needs to be for the customer is used throughout the development project and captured in the chief engineer concept paper. The concept paper outlines the chief engineer’s vision for the product and gives the marching orders for the development program[iv].

Design Thinking, as practiced at IDEO[v] and elsewhere, uses direct observation to understand what people want, need, like, and dislike about products[vi]. When using design thinking project teams work in three spaces: inspiration, ideation, and implementation. Inspiration is the circumstances that motivate the search for a solution. Ideation is the process of developing and testing ideas. Implementation is the path to bring the project to market[vii]. Projects will loop back and forth through these spaces as the team is learning what the product needs to be through observation. As the team learns they update the project brief, which provides the framework to design, objectives to be realized, and benchmarks to measure progress[viii].

Menlo Innovations uses High-Tech Anthropology where potential end users are studied and observed in their native environment including understanding differences between users[ix]. What they learn is captured as user personas. The client then selects the primary persona to drive the product design. Primary, secondary, and tertiary users are captured on a persona map with the primary persona in the middle.  As the product is being developed the high-tech anthropologists use low fidelity mock-ups to get the product in the primary user’s hands to observe their interactions[x]. These observations enable the product to be further improved to better meet the user needs.

And then there is Clayton Christensen’s “Jobs to Be Done” theory developed over two decades and triggered by the realization that knowing more about customers doesn’t translate into knowing what people need from products. More important than knowing about your customers is knowing what your customer or potential customer is trying to accomplish in a specific circumstance – their “job to be done.” [xi] Or said another way:

“What problem is your product or service solving for your customers?”

What is learned about the circumstances and job to be done is translated into a job spec with the functional, emotional, social aspects and any tradeoffs customers are willing to make to provide guidance for the innovation process[xii].

The project that started this thinking was how to sell more milkshakes for a fast-food chain. They originally took the traditional approach of asking customers what they wanted. Many experiments were run to give the customers what they said they wanted and there was no change in milkshake sales. At this point the question was reframed as: “I wonder what job arises in people’s lives that causes them to come to this restaurant to “hire” a milkshake?” Through observation and directed questioning around the circumstances of the purchase the team discovered that a lot of milkshakes were purchased in the morning to “help me stay awake and occupied while I make my morning commute more fun.” And that milkshakes sold in the afternoon had a very different purpose.  They figured out that unique solutions were needed to sell more milkshakes in each situation.

All of these approaches can be effective to understand what products and services need to be. Consistent across them is the role of observation in real environments and synthesizing that knowledge into something tangible to guide the product and process development process.

How do you understand what your product or service needs to be?

How do you translate what the product or service needs to be to provide guidance to your product and process development process?

Editor’s note: LEI LPPD Senior Coaches Katrina Appell and John Drogosz will speak more about understanding what your product needs to be to provide customer value in their new workshop, Designing the Future, at the 2018 Lean Transformation Summit, March 28 in Nashville. Participants will experience the use of observation and a concept paper to guide development from concept to manufacturing. Learn more and register for the summit and workshop here.


[ii] Liker, J. K. (2004). The Toyota way: 14 management principles from the world’s greatest manufacturer. New York, McGraw-Hill.

[iii] Liker, J. K. (2004). The Toyota way: 14 management principles from the world’s greatest manufacturer. New York, McGraw-Hill.

[iv] Morgan, J. M. and J. K. Liker (2006). The Toyota product development system: integrating people, process, and technology. New York, Productivity Press.

[viii] Brown, T. (2009). Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. New York, HarperCollinsPublishers.

[x] Sheridan, Richard (2013). Joy Inc.: How We Built a Workplace People Love. New York, Portfolio / Penguin.

[xii] Christensen, C.M., T. Hall, et al. (2016). Competing Against Luck: The Story of Innovation and Customer Choice. New York, HarperCollinsPublishers.

Better Design Reviews, Better Products

Design reviews are a common process in product and process development. They can enable knowledge sharing across an organization and prevent the same mistakes from happening across different groups. But not all design reviews are effective and how and when they are conducted varies widely across different companies, and even within a company. To have more effective design reviews that enable real-time innovation we can learn from Jim Morgan and the tips he shared in one of his e-letters, The Crucible of Innovation.

We can also learn about the process of improving design reviews from the experience of one organization that recently did that. The lessons learned include both tips for successful improvement projects along with specific learning on conducting more effective design reviews to enable better product and process development.

Prior to the improvement project, different groups used different processes for design reviews, which were inconsistently followed. Design reviews were often held close to design releases making it difficult to make changes based on what was learned in them without negatively impacting the project schedule.

The planning phase of the plan, do, check, adjust (PDCA) cycle was very important for changing the design review process. This started with creating a project team with a mix of the people who do the work and management that can influence and help implement the change. Management involvement was important to be able to address system-level issues. The project was also scoped appropriately to be able to manage the amount of change that would happen. The project focused on mechanical design reviews and within that had clear boundaries for what was in and out of scope.

Many of the engineers thought they knew what was wrong with design reviews prior to grasping the current condition. But taking the time was important for both understanding the problems and getting people to want to change how design reviews were done. This included surveys, case studies of problems not found, and attending design reviews. During interviews people had time to reflect on past projects and design reviews. And managers had data to make decisions rather than using opinions or gut feel. While the engineers were initially right on approximately 60 percent of the problems, they would have missed the other 40 percent of problems if they hadn’t taken the time to understand. It became clear that when design reviews failed to identify a problem, 70 percent of the time someone else in the company knew that it would be a problem. The organization had the knowledge, but it wasn’t easily accessible. Effective design reviews and/or design guides could have caught these problems.

A root cause analysis was used to better understand repeat issues. Some of the issues found in that analysis were:

  • Teams were not set up to be able to follow the design review process effectively.
  • Vague expectations led to everyone interpreting them differently, doing different things with different results.
  • The teams didn’t have the right knowledge of who the appropriate people to attend the design reviews were.

Countermeasures that were put in place were:

  • Defining design review timing in a template – ensuring there is sufficient time after the reviews to mitigate identified risks prior to milestones including design freezes.
  • Creating a design review template with standard content – providing clear expectations of what should be reviewed.
  • Creating a standard template for attendance at design reviews. Attendance includes both reviewers who are consistent across all projects to facilitate organizational learning and key cross-functional point people to determine who within those functions has the appropriate knowledge to contribute to the design reviews.
  • Creating a design review process flow, including a follow-up template. This ensures there is consensus on the risk mitigation plans with monthly follow-up to close the issues.

The benefits of changing the design review process have been realized relatively quickly. Identified risks are resolved earlier in programs, preventing late tooling changes. And knowledge is more effectively shared across projects. After the success in mechanical design, the organization intends to expand the improved design reviews to other functions and to the system level design.

Jose Ferro

José R. Ferro is a senior advisor to the Lean Enterprise Institute and president of Lean Institute Brasil, a nonprofit organization founded in 1999 to disseminate the principles and practices of Lean Thinking in Brazilian companies.

Ferro authored chapters for the Brazilian edition of the following books, all published by Editora Campus, Rio de Janeiro: Lean Thinking, Mentalidade Enxuta nas empresas, by James Womack and Dan Jones, 1998; Collision, Colisão – GM, VW e Toyota, by Maryann Keller, 1994; The Machine That Changed the World, A máquina que mudou o mundo, by James Womack, Dan Jones and Daniel Roos, 1992. He is co-author of “Brazil: a New Pattern of Industrial Relations” in After Lean Production, coordinated by MacDuffie, Kochan and Lansbury (Cornell University Press, 1998). Ferro has worked with Autosector, an association of labor, industry, and government that aided the auto industry in Brazil. He also has worked with the National Association of Automotive Manufacturers, the Brazilian Association of Vehicle Importers, and the Union of Metallurgy Companies, and the State of Bahia government.

Ferro received Ph.D. and master’s degrees in business administration, Getulio Vargas Foundation, and in production engineering from the University of São Paulo in São Carlos. Since 1992, he has been a professor in the Economics Department, School of Business Administration at São Paulo, Getulio Vargas Foundation. Ferro has also held positions as professor, University of Campinas, Statistics and Computer Science Institute Master’s Course in Quality Management (1992-1998); and Visiting Scholar at the Massachusetts Institute of Technology (1988-1990).

How Obeya Improved Our Product Development Efforts

As we embark on another year of our lean product and process development (LPPD) journey, our biggest success to date has been the application of obeya in our organization. As a follow up to John Drogosz’s article, Developing Your Obeya, Stage-by-Stage, we would like to share how we grew and evolved obeya into our organization over the past year.

We are a part of TechnipFMC, an oil and gas service and equipment provider. Our business unit, Schilling Robotics, where this journey is taking place, designs and manufactures the remotely operated vehicles (ROVs) that are used to assemble sub sea oil and gas infrastructure. At the Schilling Robotics business unit, we have a long history of highly complex engineered products and we are very familiar with conventional project management tools and techniques for running such projects. In March of 2016, we started an experiment using obeya on our latest development project to see if we could improve our product development performance.

At the start of the year, the development team created their obeya in a high-traffic area near the critical mass of the product development team. The visual schedule was the first element to be created on a blank wall, so everyone could understand the overall value stream and identify their key issues related to schedule. Shortly after the schedule went up, space was given for sub groups to post what they thought was most relevant to share with their team members.

Early in the project, the biggest benefit was the increase in organizational alignment. We define “alignment” as people knowing exactly what they must do to achieve their next goal. This was achieved via:

  • Cross-functional attendance – this fostered direct communication to all levels of the organization, all at the same time.
  • Visual schedule – this helped people keep cadence and adjust dynamically to changes.
  • Connecting people – the obeya meetings became a consistent place to find and discuss issues with people.
  • Catching issues early – identifying, communicating, and assigning them to the right person.

The team chose a weekly cadence to gather the entire product development team in the obeya to review the schedule and subgroup dates. The early meetings were crowded, messy and long. At times the meetings exceeded an hour and there were grumblings about having to stand for so long! The project leadership team immediately started weekly reflections to improve the obeya, and how it was used at the weekly meeting. Through a series of PDCA cycles, the team started defining their best practices and standards to keep the flow and focus of conversation on the elements most important to the project. At first this was a challenge, as the team had to learn to focus on the right level of detail in their discussions (i.e. what are their major technical challenges and timeline risks) and avoid long discussions on completed items. The weekly meeting quickly shrank to 45 minutes, with an increase of quality information conveyed.

Toward mid-year, the project progressed and PDCA on how we used the obeya continued. Unprompted, groups other than designers began to claim wall space. People continued to become more succinct when conveying information. The project leader, a diehard digital Gantt chart user, abandoned his secret schedule in favor of the paper wall calendar. Several other positive side effects occurred by having the obeya in place, including:

  • Post-obeya meetings – Small group huddles, around specific issues, started to spontaneously occur after the formal obeya stand-ups ended.
  • Quick recognition of success – While obeya is meant to highlight and focus on issues, feedback from the teams show that recognition of successes helps drive better morale and teamwork.
  • Posting a legend so stakeholders could understand the visual standards and the meeting rules.
  • Training new team members in obeya by having them vet their obeya speech with a peer prior to the meeting.
  • People started experimenting with videos and photos to share obeya with others offsite.

At the end of the year, the team had prototype hardware arriving that needed to be assembled and tested. As the hardware arrived, there were the usual minor hiccups associated with a prototype; missed tolerances, fit issues, software bugs, etc. All easy to address. What were conspicuously missing were the major issues; late parts, last minute scrambles, frayed nerves. Team members were verbally wondering when the “unforeseen emergency” was going to hit. There were a lot of moving parts at the end of the year, and to keep it all aligned the team leaders moved the obeya to the shop floor where the action was. The cadence changed to daily to ensure the program was on track. The focus also narrowed to the task at hand, completing the tests required to validate the design direction. This became affectionately known as the “test obeya” for the few months it was in use.

As the team met daily during the test phase, it became clear that the emergency was not going to materialize. Then, all of the sudden, it was over. The last set of tests were complete two weeks early. Upon reflection, the team credited the obeya, and the actions it drove, as the main factor for our smooth prototype delivery. The end of the year helped cement the benefits obeya can bring to all members of our product development community. It has become an integral part of how we run our projects, and will continue to evolve with future projects.

Developing Your Obeya, Stage-by-Stage

In my travels I have coached many teams through the obeya process and have seen that while each team’s journey is somewhat unique, most teams do go through several stages of evolution before obeya becomes an embedded ritual.

Rationalizing: Do we really need this?

For many, just getting started on the journey can be a challenge. With all the project management tools, meetings and professional project managers involved in product-development projects today, many teams question upfront whether they really need obeya. It seems like an overlap as many say:

  • “We already have all that information online that everyone can access.”
  • “That is the project manager’s job.”
  • “We already have too many meetings.”
  • “Our team is spread out all over the place so why have a space?”

Others have also balked about past times they used war rooms for key projects, only to have the obeya end up a dog-and-pony show for senior managers and a time-drain for the people.

So the first step is to work with the team to define what team challenges they are trying to solve and how the obeya fits the situation in question (sometimes it will not and that is okay).  However, despite all the tools, meetings and managers involved, most large teams still struggle with the fundamentals of projects – staying aligned, escalating issues, rapidly solving problems and making decisions in a timely manner.  So, the first step is for the team to identify how obeya can help them improve the execution of their projects.

Start up: Where are we going to find the space?

Getting the obeya started should not be a large undertaking; yet most teams will encounter some obstacles that need to be overcome. Some of these include:

  • Finding a space. At the beginning, many organizations face the fundamental challenge of finding a space for obeya. Many say, “We already have enough problems finding a conference room for given meetings, and now you want to dedicate room for just one project?” In some instances, it may take some creativity to create a space for the first obeya – look for open areas that can be enclosed with temporary walls, use a space in a corner of the prototype shop, double up on offices to free up a room. If there is a will, a solution will present itself.
  • Taking the time to stop and set up the space. The initial setup of the obeya is a team sport. It will take a half to a whole day but it is the first demonstration by team members that they are committed to trying to work in obeya. In fact, it is a great teambuilding exercise for a project kickoff.
  • Deciding what’s most relevant/useful. Creating meaningful visuals to manage the project is easier said than done. Initially, team members are uncertain about what to display. In the beginning, they will frequently overdo it and post way more information than they or their team needs. Not to worry – as the team continues to work in obeya the visuals that are most value added will show themselves and the others will gradually fade away. Similarly, obeya meetings in the beginning will take more time but as teams practice their rituals, the discussions will become more focused. Before this happens the team needs to go through a phase of experimentation.

Experimenting: Trial and Error

The first month of obeya is a challenging time for most teams. They are both learning new ways to interact with one another while still trying to get their project work done. In many cases, while teams are experimenting there will be lively debates on various visuals – which ones work, which ones don’t. People will also be editorializing how much detail to share during obeya stand-up meetings.

A best practice for the first few months of a new obeya is to build in a 10-minute debrief at the end of every other stand-up meeting to ask the team how the space and meeting rituals are working and what needs to be improved.

From Statusing to Collaborative Problem Solving

A common challenge in the early stages of implementing obeya is using the visuals and stand-ups to focus the conversation on the important subjects affecting the customer, the product and the project. All too often, teams start by plastering the walls with all the deliverables and metrics that are specified in their PD procedures and provide status on each one, as they have done in the past. Team members then struggle to see how obeya is any different from their old project status meetings done on the screen. In fact, if the team stops there with how they will use the obeya, there will be no difference!

The obeya needs to become the andon system for the project team where they can make issues (technical and business) visible and get help from the right team members and management to resolve them quickly so the project can keep moving forward. When people meet frequently in the obeya, it helps them all stay on the same page and see the bigger picture of how their work fits in and how they can help

Stalling and then evolving

A common speed-bump that teams encounter when working in obeya is that they eventually hit a plateau and the team feels like the obeya is not giving them the same level of information and collaboration as it did in the past. This is a sign that the obeya is actually working. The walls are telling us that we need to change as the product and project is evolving and consequently so does the visual management in the space. For example, in the early stages the team is typically speaking about feasibility of concepts so we would likely see many renderings on the walls that the team is evaluating. Later in the project, when they are making tools and preparing the plant for the new product, the conversation is much more execution-focused – thus we would expect to see tooling timelines and factory layouts on the walls. In other words, the obeya is a living canvas that needs to change as the product and project is evolving. Typically, at the end of each major phase of a project, the team should have a reflection to see how they need to adapt the room as they proceed into the next phase.

Standardizing and Continuously Improving

A common pitfall of many teams (and continuous improvement agents) is to try to define the visual standards and meeting protocols from the beginning. Unless you have already applied obeya on a few projects, it is best to wait until the team has learned enough about which methods and visuals work best in their environment. Similar to product development, we need to try a few prototypes and simulate them before we have the proof of concept. Once there is consensus, then the team can define the best practice and propose it as a standard for future projects.

In fact, I have seen in many cases that the standards start showing up organically in the obeya as team members provide feedback to each other and simply start adopting the visuals that work best for them. Other teams visiting the obeya then see what is working and will adopt and or adapt them to their own obeyas.

As you work through implementing obeya in your organization, recognize that it will take time and patience as teams go through the stages above. Each stage is a learning opportunity for the team and the organization so don’t rush it – as the people grow, the obeya will grow.

Editor’s Note: Next week we will feature a follow-up piece from a manager at TechnipFMC who learned about and created an obeya under John Drogosz. Tune in next week for a fascinating look at how the obeya room has improved their product development operations.

The Concept Paper for a New Product: The Kickstart of a LPPD Project

Lean product and process development is not an easy undertaking, neither to understand nor execute. The concepts, tools and practices are often found to be technical, complex and counterintuitive, making it a challenge to launch new initiatives.

Luckily, there is a tool that can help remedy this ever-common problem: the Concept Paper.

“As more companies engage in the transformation of their product development system and the whole enterprise using the Lean Product and Process Development (LPPD) approach, there is a need for better understanding of some of LPPD’s key practices,” writes Jose Ferro of Lean Institute Brazil in his new white paper on concept papers. “One important yet frequently overlooked tool is the concept paper, a fundamental mechanism to kickstart a new project. This article will present the concept paper, define its purpose, outline its main content elements, and explain its importance to a LPPD transformation.”

You’ll learn:

  • The purpose and importance of the concept paper in a LPPD transformation
  • What a concept paper must consist of in order to be most effective
  • Who should be given responsibility for writing and presenting the concept paper
  • The process for studying and researching all of the information and data necessary for writing
  • And more.

Read the whitepaper here.

Michael Ballé, Jim Morgan, Durward Sobek featured in MIT’s Sloan Review

Skilled people, not processes or new tools, create great products, according to an article on innovation by Lean Enterprise Institute researchers appearing in the Spring 2016 issue of MIT Sloan Management Review. “Why Learning is Central to Sustained Innovation,” by Michael Ballé, James Morgan, and Durward Sobek II, is part of a special report on product development.

For your convenience, we have licensed the article for download for a limited time.

According to the authors, evidence shows that people and people systems are the most important parts of a product development system, because people generate the knowledge necessary for innovation in new products, new manufacturing systems, and more robust supply chains. The authors recommend that companies ask three fundamental questions to improve developers’ skills and capabilities.

Forward-Looking Companies Attend LEI’s Lean Product and Process Development (LPPD) Open House at Summit Week 2017

Forward-Looking Companies Attend LEI’s Lean Product and Process Development (LPPD) Open House at Summit Week 2017

A wide range of industry participants came together on March 6th, 2017 in Carlsbad, CA the day before the annual Lean Enterprise Institute (LEI) Summit to learn about product and process development. Invited representatives came from a variety of industries, including medical devices, healthcare, mining technology, golf equipment, digital printing, and others. The audience actively engaged with key thought leaders and case study presenters as part of showcasing LEI’s Lean Product and Process Development (LPPD) initiative. Duplicate morning and afternoon half-day sessions were organized to provide flexibility for the attendees.

Introductions & Survey Themes with Eric Ethington

Eric Ethington, program manager for LPPD with LEI, kicked off the open house with introductions and an overview of the agenda. Eric reiterated that the purpose of the LPPD program was to focus on changing the way new value is created. Prior to the session, each participant was invited to complete a voice of the customer survey with two questions being discussed at the session:

  • What is your definition of LPPD?
  • What are key success factors for successfully applying LPPD thinking in your organization?

With the first question of LPPD definition, many of the responses were around two themes: process and customer-focus. Scott Schmidt from US Synthetic responded that a “declared process is tough for many organizations to follow in LPPD.” Dr. Jack Billi and Dr. Ted Lawrence from Michigan Medicine reiterated that the customer (patient)-first theme resonates in healthcare.

For key success factors, the trends were leadership priority, culture change, PDCA cycles, structuring the organization, and getting the knowledge. Dr. Billi commented that knowledge is not enough for success, as evidenced by the survey results. In addition, Eric Ethington stressed that there were many “people” elements for success, yet we do not strongly acknowledge this in our definition typically.

The Ford Story & Experiences with Jim Morgan

Jim Morgan, Senior Adviser for LPPD with LEI, next shared his experiences with LPPD and Ford’s product-driven revitalization that he helped lead. Over the course of 45 minutes, Jim summarized the key points of the eleven-year journey that Ford took in the LPPD space under his guidance.

Development typically drives 70-80 percent of committed costs and quality for a new product, which is why it is a competitive advantage to find success in LPPD. In addition, it engages the entire enterprise and creates your future. During the late 1990s / early 2000s, people were starting to notice Toyota’s success with LPPD because their development times were 50 percent lower with 33 percent fewer resources and the highest profits per vehicle in the industry.

When people studied the Toyota development system, they found it was foundational for Toyota’s Production System, plus it was a disruptive model for continuous product development versus the traditional automotive industry model of “batching” model releases. The basic principles of LPPD include people, process, and tools. People and learning are at the heart of LPPD. Every time you develop a new product, you are creating knowledge.

The Ford story that Jim shared began in 2005. At that moment in time, the company was on pace for a $17 billion annual loss and was in its twentieth year of a steady market-share decline. The company was losing money on every car that it produced. Customer satisfaction was the worst in the industry and the stock was hovering at a distressingly low $1.90. There was a culture described as “cage-fighting” with massive layoffs occurring to offset the shrinking volumes. In 2006, Ford brought in Alan Mulally to lead the company after being CEO at Boeing. Mulally summed up Ford with the statement, “I was right—Ford’s problems weren’t as bad as Boeing’s. They were much worse.”

Fast forward eleven years, the turnaround that was reached based on the product-led revolution was dramatic—industry-leading customer satisfaction, $9 billion in annual profits, $15 stock price, and hiring of new employees. A key decision was Ford leadership securing $23 billion in loans in late 2006 before the credit markets later seized up in 2008. The leadership invested in new product, not spreading the money to poor existing infrastructure or programs that were not core to the future. The goal was to “create products that people actually want”.

People: The Best People Create the Best Products

In order to develop products that customers actually desired, the new global development process at Ford focused on not just developing products, but simultaneously developing people. Ford evolved their development organizational structure to support this vision, eventually settling on the product-focused matrix. A chief engineer had full responsibility for a product from idea to post-launch in this new structure. Groomed to be super engineers and superb leaders, Ford found it difficult to find and develop chief engineer candidates, but worth the effort.

Chief Engineer & Supporting Organizational Structure for People Development

Within the product-focused matrix, each function had an integration leader that was dedicated to the program (F-150, Mustang, etc.). In addition, there was an assistant chief engineer (ACE) that was being developed for possible future chief engineer role. The ACE would support regional development work. “A Faster Horse” available on Netflix tells the story of the development of the 2015 Mustang and the chief engineer at Ford.

In this structure, the functional leader’s job is to make the chief engineer successful. The chief engineer owns the “what,” and each functional leader owns the “how.” As Jim noted, “organizational software trumps organizational hardware,” meaning the behaviors and interpersonal relationships drive the success. And one yardstick for measuring success is product award recognition.

As for individual people development, prior to 2005, Ford typically hired engineers from the best, top-ranked engineering schools. Once hired, there was not much personal development, but rather a tendency to move around to get promoted faster. This eventually led to limited technical depth at key levels. One countermeasure in order to build “towering technical competence” was crafting technical maturity models (TMMs) that were plans for individual development. As Jim noted, most technical skills are “tacit” not explicit, so there needed to be a deliberate, intentional plan to develop the expertise.

One participant asked Jim how an organization could develop a chief engineer. The first step could be acting as the integration leader for a function (functional “chief engineer”). The second step could be as project manager for the chief engineer (“keep the trains running on-time”). The third step could be as a regional assistant chief engineer (ACE), with the fourth step as a possible chief engineer. Some companies start out with a Commercial Leader and Technical Leader (matched pair) that share the chief engineer role since it is difficult to start with one person with the appropriate skills and experiences.

Design reviews are another key people-development aspect of LPPD. Design reviews can be cadenced or event-driven (product-level) and led by the Chief Engineer. The purpose is to make it safe to surface problems with the development program to help improve the product outcome while also developing people. In addition, it improves the leaders’ knowledge. Design reviews should focus mainly on the current issues or teams will run out of time each review session.

Another participant asked how a design review would look in an LPPD organization. Jim recommended limiting (“outlawing”) typical presentation materials, while focusing on data and direct evidence. Hold the reviews outside of conference rooms and in the “gemba” (Japanese for “actual workplace”), whether that is at dealers, tool rooms, model shops, etc. Surface real problems…and get them solved—this will increase the interest and attendance, while minimizing other unnecessary meetings. Allocate enough time to discuss conflict and risks so leaders can prioritize the right actions.

Extended Enterprise

The development of people does not just stop within the internal organization. Supplier content made up about 50-60 percent of Ford’s end products, making it critical to work more proactively with key suppliers. Within six years of engaging more closely with the supply base, Ford’s overall supplier quality levels went from worst to third-best in the industry. Some ways that Ford worked closer was by matching up key pairs of engineering and purchasing leaders (matched pairs) to support longer term relationships, to experiment with expanded commodity plans, and to visit supplier gemba locations on a planned cadence.

The Process Components for LPPD

Jim next introduced the three components of the LPPD process: Study (“kentou” in Japanese), Execution, and Reflection. The Study phase is the most important since the challenge is to find and create the right product. Voice of the customer, immersion, concept paper, set-based concurrent engineering, and other techniques of LPPD are found in this phase. Jim also cautioned the group and quoted former basketball coach Johnny Kerr in that “if you listen too much to the fans, you end up sitting with them.” The Concept Paper helps compile a vision for the product from the mind of the chief engineer after gathering wide input. After incorporating this input and communicating it out, the Concept Paper then serves to align the organization, and then ultimately becomes a contract for the product success.

A core element of the Execution phase includes process milestones. The milestones are not treated as traditional “gates,” but rather to provide functional integration points to determine normal from abnormal for progress. Milestone points need to have clear purpose statements and quality of event criteria in order to synchronize all the LPPD activities. Compatibility before Completion (CbC), Digital Pre-Assembly (DPA), Perfect Drawing Plans (PDPs), and other techniques of LPPD are critical in this phase. The Reflection phase is capturing the key learning to embed into the next cycle of development.

TechnipFMC Schilling Robotics: A Brief Introduction to their LPPD Experience

David Furmidge, product development manager, shared the learning and experiences that the Schilling Robotics division of TechnipFMC has had as an LEI LPPD Learning Group member with their Gemini development program. Jeff Fritts and Hannah Waldenberger also joined with David to share the learning. Gemini is a remote operated vehicle (ROV) for the subsea oil and gas industry. The innovative new design greatly enhances the productivity of the tool changes, leading to a competitive advantage for the product that traditionally costs up to $1 million per day for customers.

Hannah Walderberger – TechnipFMC Schilling Robotics

David discussed two areas where the Gemini team started experimenting with concepts with LEI’s LPPD coaches—Post-Launch Design Changes and Late Product Launch. For Post-Launch Design Changes, the concepts were A3 problem solving, obeya/visual management, and strategic planning. For Late Product Launch, the concepts were set-based design, trade-off curves, question mapping, high-tech anthropology (HTA from Menlo Innovations in Ann Arbor), storyboards, product roadmaps, and product development value stream mapping (PDVSM). David shared an assessment of each of the experiments with the concepts. In reflection of the activities, the 2016 goals were met two weeks early, which was a critical success for the new Gemini product.

LPPD at LEI with Eric Ethington

Eric Ethington provided an overview of LPPD at LEI for the last part of the session. LEI’s LPPD program is made up of four initiatives—Learning Group, Research, Education, and Community. The program began in early 2015 with Jim Morgan with a couple of partner organizations. His vision was to create a learning experience that could not be rivaled by any one conference or event. Since then, the LEI LPPD team has expanded with an additional four coaches supporting learning group partners Herman Miller, Bose, TechnipFMC (four sites), GE Appliances, Michigan Medicine, and Honda R&D.

Eric Ethington, LEI LPPD Program Manager

Eric focused in on the levels of engagement that an organization can have with LPPD at LEI, starting with monthly newsletters all the way up to co-teaching partner in the learning group. Eric also showed the unique learning model that the LPPD coaches and the learning -group partners use together.

The outreach event concluded with a question-and-answer session with Jim Morgan and John Shook, Chairman and CEO of LEI.

Enabling Fast and Innovative Product Development at Bose

Product and process development is how new value is created through delivering great products that meet customer needs with profitable value streams. The decisions made in product and process development have an outsized influence across the entire value stream. The faster an individual or organization can learn, the greater the knowledge available is to make better decisions, and/or the quicker decisions can be made. This enables products to get to market faster and start providing customer value.

Indeed, Toyota founder Kiichiro Toyoda said this about the importance of rapid learning: “We are going to build cars. Let’s all learn as much as we can, and work together to create something our customers will buy. My job is the same as yours: to learn as fast as I can.”

LEI Lean Product and Process Development Learning Partner Bose Corporation sees the value in enabling rapid learning and created a “Rapid Prototype Development Center” at its Framingham, Massachusetts headquarters. Its goal was to enable fast and innovative product and concept development. Now LPPD coach Katrina Appell tells the story of the RPDC and the benefits Bose is enjoying from it.

You’ll learn:

1. How the RPDC is providing Bose with a competitive advantage.

2. How the design of the RPDC enables higher levels of creativity, greater collaboration, and increases employee engagement.

3. Specific examples of the tangible benefits realized through the RPDC.

4. How Bose is learning through the LEI LPPD Learning Group while continuously improving rapid prototyping capabilities.

The case study may be found here.