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.

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.

What are the key traits I should look for in a potential Chief Engineer? A Q&A with Katrina Appell

What are the key traits I should look for in a potential Chief Engineer?

The answer to that question depends on what your expectations are for a chief engineer:

  • Do you want someone with deep technical expertise in a domain, as the term is commonly used in many organizations?
  • Do you want a system integrator, which is more in line with the role as practiced within lean product and process development?
  • Do you want someone that deeply understands what the product must be, which is also in alignment with the role as practiced within lean product and process development?

Even more important to ask: Why do you want a chief engineer? What problem(s) will a chief engineer solve for your organization?

The chief engineer as practiced within lean product and process development (LPPD) is a countermeasure to problems that are both inherent to developing products and to the organizational design in which it is used.

For example, the fundamental purpose of product development is to develop a product that customers will value, which is likely solving a problem the customer has. And in most organizations this needs to be done profitably. The chief engineer system is a key part of understanding what the product needs to be for the customer and the business.

The chief engineer system is also a countermeasure to problems that occur in companies that are organized functionally. Functional organizations can be great at developing deep technical expertise. But they also run the risk of contributing to sub-optimized products if each function optimizes within their function. You could have the best technical design, but if it can’t be manufactured or sold profitably those are major problems for the product and organization.

To overcome the problems inherent in a functional organization, another common organizational approach is to organize around the product. This organizational structure can be effective for cross-functional collaboration and optimization at the product level, but often results in a lack of focus on developing deep technical expertise. The problems this causes become more evident as years go by.

Organizations sometimes flip back and forth between being organized by function and by product as each organizational structure solves the problems of the other one. The chief engineer system is one approach to get both the benefits of deep technical expertise within functions and optimizing the product to meet the customer and business needs. The chief engineer system might be the right approach for your organization, but have you considered others?

In the chief engineer system, as typically used in LPPD, the organization is organized functionally. The chief engineer, with support from a small team, has full responsibility for the success or failure of the product. This doesn’t just include development, but ultimately the profit and loss for the product and everything else that encompasses as well.

In this system the chief engineer has full responsibility without authority over most people working on the product. Each function’s role is to support the chief engineer to be successful and to develop people’s technical expertise within the function. In this system the fit between the chief engineer and the rest of the organization is what is important for success. If you have a mature functional organization experienced in working this way with a new, inexperienced chief engineer, the functional leaders can help develop and support the chief engineer to be successful.

And then there is the organizational-change aspect to consider. Organizations are a collection of people and both individuals and the organization are or should be constantly changing – hopefully growing. When you make a change in one part of the organization, the rest of the organization reacts to it. If you introduce a chief engineer into your current organization, how will the rest of the organization respond? How do you want the rest of the organization to respond?

Mutual trust and respect between the chief engineer and the rest of the organization are a good starting point to set the conditions for success. What other traits are needed to get engagement and support to make the product successful with no authority? And given your current organization and what you expect a chief engineer to do within it, what are the key traits that individual needs to be successful?

What’s a good “small step” to start off my LPPD transformation? A Q&A with Katrina Appell

What’s a good “small step” to start off my LPPD transformation?

Visual management (VM) is a great place to start your lean product and process development (LPPD) transformation, especially if you have prior experience using VM. A VM system works the same in LPPD as it would in manufacturing or any other environment. And if you don’t have experience with VM it is a great place to start any lean transformation.

There is tremendous value in making things visual – a picture is worth a thousand words. When things are visual, everyone is able to see the same information, which helps to ensure that everyone really is on the same page. This is especially important in knowledge-work environments, such as LPPD, in which the work is hard to see. Visuals become even more valuable in a management system, as you can create one for anything that has a plan or standard – schedule, budget, resources, quality, knowledge gaps, etc.

Visual management is a great first experiment with lean as the benefits can be seen relatively quickly – good news for results-hungry management. You can create a daily or weekly cadence to identify and solve problems. A short cadence also enables more PDCA cycles in your LPPD transformation, which helps build momentum. As with any lean method, your experiment with VM should be connected to a problem. The type of problem(s) you need to solve should influence what comprises your first VM experiment(s). If you are working with a constrained resource, such as lab testing, that might be a good place for an experiment. Or if you need to manage a product development project, obeyacould be a great experiment to start with.

When creating a VM system to address your problem(s) important components to include are:

  • Tracking actual versus plan
  • Identifying problems – when actual deviates from the plan
  • Effectively communicating problems
  • Effectively responding and solving problems


Image above:

  • Cool mint green: On schedule, no work in process
  • Dark green: In process
  • Dark green with check mark: Complete
  • Yellow: Risk identified, team working on a resolution
  • Red: Risk identified, resolution requires outside/management support

This actually might not be easy, but it is easier to learn on a small scale with rapid PDCA cycles connected to real problems than to learn lean thinking through larger scale experiments. Lean is fractal and your visual management system should address the questions in the lean transformation framework:

  1. What is the purpose of the change–what true north and value are we providing, or simply: what problem are we trying to solve?
  2. How are we improving the actual work?
  3. How are we building capability?
  4. What leadership behaviors and management systems are required to support this new way of working?
  5. What basic thinking, mindset, or assumptions comprise the existing culture, and are we driving this transformation?

As you address these questions in your VM experiments you are building a foundation of lean thinking in product and process development, which can be expanded upon as you start experimenting with other LPPD methods.

How Does Shop-Floor Lean Compare to Lean Product and Process Development (LPPD)? A Q&A with Matt Zayko

I have 15 years of lean experience on the shop floor. Recently my organization’s product development leader was let go and the very next day they told me I would be taking over for him. I’ve never experienced the work that goes on in that department, so all I have to go on is my lean experience. Is my knowledge of shop-floor lean enough for me to get by in product development?

Absolutely. The approaches are different, but the concepts are the same.

The first step in grasping the situation for a customer is to define the purpose for a product that you provide for them. This will also help determine the actual “unit” that you’re going to use later to track your value stream effectiveness. In both approaches, that usually comes from identifying the value from the customer’s perspective. In traditional lean we will look at all the steps involved in creating and delivering a specific product, from raw materials to shipping. In LPPD it’s a little trickier at first, because there are steps that we as engineers know will create useful knowledge for value, but the customer (or other internal functions/areas) may not understand. For example, consider doing multiple learning cycles early on to determine the best parameters and process for developing the specific product; the learning cycles could be viewed as waste or re-work if we are not careful to understand the output value of the process. But what it all boils down to for both approaches is identifying the value from the customer’s perspective, whatever it may be, and designing a value stream that best delivers that value.

The next concept is, “What is the actual work to provide that value?” That’s where you look at the value stream. The value stream in product development is very different, but follows a similar pattern as for manufacturing. The difference for LPPD is that you may have to account for numerous functions spread across multiple locations and time zones, a timeframe of a year or more, knowledge flow, experiments, etc. In LPPD, there are typically two high level phases within the value stream: learning and execution. The learning phase is about generating useful knowledge as you converge to an optimal design concept, and may have multiple learning cycles. The execution phase is about configuring and detailed engineering. An LPPD value stream map will be much more detailed than a manufacturing map, since the timeframe for the latter might have a range in days or weeks instead of years. The framework for value stream mapping in LPPD that Jim Morgan pioneered in early 2000s, is very close to what we use for mapping in manufacturing, and that is what Jim based his method on for LPPD mapping from the 1998 LEI workbook, Learning to See.

Once you actually understand the work, the next question is how do you make that work flow? That’s rather straightforward in shop-floor lean. We shrink batch sizes. We get rid of inventory. We reduce process times. We get rid of any distractions or interruptions to the value-add flow. We add standard work for stability. In LPPD, we do similar activities, but to the flow of knowledge and information. We do staggered release of information. We focus on moving the information faster between process steps with minimal delay. We avoid handoffs, where possible. We aim for repeatable routines at process steps at a standard cadence.

Once you’ve identified how to get the work flowing, you need to figure out how the work should be done for maximum quality and efficiency. An important concept in this step is standard work, which again is very straightforward in factory lean. In LPPD it’s another story, because experiments and tasks are traditionally done at the engineer’s discretion. It’s tough to hand an engineer standard work and say, “This is the known best way to make this prototype” when the given prototype has never been conceived. But the underlying questions in establishing standard work are the same for both factory lean and LPPD: What’s the sequence of work? What are the critical quality points? What are the important safety points?

The last question is really, what’s the best management system to improve and manage the work? Between factory lean and LPPD the available tools and techniques are similar, but the timelines will be different. You might have a visual tracking board to record data on a cycle-to-cycle or hour-by-hour basis in the factory; in LPPD that same visual management board might record data on a daily, weekly, or monthly basis to reflect longer cycle times of work tasks. A dedicated obeya or “big-room” space is recommended for a LPPD team as a critical enabler for a cross-functional team to visually manage their process in order to highlight normal from abnormal.

So in conclusion, it is a logical progression for a person who has deep experience in lean transformation on the factory floor to move upstream in the LPPD space using concepts and thinking that were honed on the production floor. This person will have a higher chance of success if he or she is able to have a flexible approach for applying the concepts, as well as an appetite for learning in a very challenging (yet highly rewarding) LPPD environment.

How Do You REALLY Put Yourself in Your Customers’ Shoes? A Q&A with Eric Ethington

I’ve read about auto engineers driving their companies’ newest vehicles for months seeing how many heads turn, what passersby think of its features, etc. My company doesn’t make cars, so what are some non-product-specific ways of REALLY putting yourself in your customers’ shoes?

Good question. This isn’t so much about what you make or the service you provide; it is more about either:

  1. Experiencing your product in the same manner your customer does, or
  2. Observing your customer experiencing your product in its intended environment

and then recording the experience in terms of useful data. You should pay particular attention to the motion of the customer’s eyes and hands as they interact with the product. Is this interaction simple and elegant, or frustrating and clunky? Write down what you observe, both good and bad. Then later on you can look over your notes and try to understand WHY things did or did not go well (Hint: if your answer involves a perceived deficiency in your customer’s skills you are on the wrong path!)

Let’s look at an example. Most all of us have used those point-of-sale credit-card scanners. They should be easy to use, right? Just swipe, sign and hit “OK” – or something like that. But if someone were to observe the customer using them they might notice:

  1. Repeated swipes (the card was in the wrong orientation)
  2. Swiping when the “chip” should be used – or visa versa (not clear which is functional)
  3. Having to sign twice because the signature was accidently cleared (some devices have the OK button to the right of the signature and the CLEAR button to the left; others have these reversed; the first scenario is more intuitive as the pen is on the right side of the display at the end of signing

pos system

If YOU are experiencing your CURRENT product versus observing the customer, be sure to avoid any “perks” or “favoritism” that you usually enjoy.  If you work for a bank, you’d want to go to a branch where people do not know you so that Joe doesn’t compensate for that form you filled out incorrectly. If you make computers, obtain yours through the sales channels your customers use, not through the employee benefits program that comes with special pre-installed software. Or if you work at a medical center, rather than going to your colleague to schedule an appointment, call the general phone number someone in the public would and experience what happens.

One final point of observation that applies to physical products, but even more so to services: Are there a lot of labels and signs? Question the need for every sign – or better yet, perform a 5-Why on the sign and use what you learn to improve your service or product.

At my gym, for example, there are labels on the bottles of hairspray and deodorant that say, “Do not throw away, we refill.”  Unfortunately, the management at my gym is not asking the question you just posed about the need for signage. There is a simple solution to their problem – and it is not a sign. If only the management actually worked out at the gym…

Green from the Start

Kelly Singer: How do lean and green companies approach sustainability differently?

James Morgan: Lean and Green companies think about their impact on the environment from the start.  Instead of just thinking about an end “green” goal – like a recyclable or biodegradable product, they think about how the entire value stream can become green.   They realize that not thinking green from the start will result in unnecessary rework, additional expenses, delay going to market and worst of all – missing an opportunity to minimize their environmental impact by waiting until it’s too late in the process.  But I think most importantly, lean and green companies are acutely aware of their impact on the environment – and know how much more effective they can be with better cross-functional planning.
KS: What is cross-functional planning and how does it relate to lean and green?

JM: An important lean principle that helps improve cross-functional planning in the development process is “compatibility before completion,” and it is a critical part of lean product and process development (LPPD). In fact, it is fundamental to creating lean and green value streams.  This is the practice of building compatibility checks into your development process to ensure that designs are compatible with all system requirements right from the start.  These requirements often include interdependent parts, manufacturing requirements, quality, serviceability, and of course, environmental impact.  And these requirements must be met before moving forward in the process to production.

It’s about moving beyond just a focus on “how do we complete this project on time and on budget” to “how do we align our individual processes and systems to create the best product – in fact total value stream possible”.  And it’s about collaboration not siloed work.  It results in minimizing the rework of late changes, reducing workload, and shortening overall lead-time.  This creates less waste and optimizes your value stream – and that means less impact on the environment. When you consider the impact that the waste of many current products and processes have on the environment … it’s kind of scary … and it should make us all eager to change because that waste is preventable.
KS: During your tenure as Ford’s Global Director of Body Exterior, Safety, and Stamping Engineering, you were a leader in Ford’s historic turnaround. One of the key accomplishments was the new, aluminum F-150 with eco-boost engine. How was Ford able to create the world’s most successful eco-truck?

JM: I was indeed privileged to be a part of the historic turnaround at Ford during which CEO Alan Mulally rallied the company around a simple goal: create new products that our customers want and will buy. During this time the company delivered both the products and the system that fueled a transformation that not only made Ford profitable again, but an innovation leader in the automotive industry. I was at Ford for more than 10 years and it had a big impact on my thinking and development as a leader – largely due to the outstanding leaders I worked for.

When you think of environmentally friendly vehicles, trucks probably aren’t the first thing that comes to mind. And we wanted to change that. Bill Ford’s commitment to the environment is well known. Trucks are an integral part of life in North America and a critical part of Ford’s product portfolio. So this was a very big idea – and even bigger challenge. In order to replace the huge eight cylinder behemoths that usually powered competitor’s conventional pickup trucks with the super efficient, award winning, six cylinder eco-boost engine and deliver the same or better performance for our customers, we had to take massive amount of weight out of the vehicle. This required innovation and collaboration on a massive scale – and a very big dose of Compatibility Before Completion … and we were successful. Not only does the new F150 have significantly improved mileage (the F150 EcoBoost still has the highest EPA-estimated fuel economy ratings of any gas-powered light-duty pickup), it is also best in class for many critical truck performance attributes – and consequently is the best-selling vehicle of any kind in North America.

What’s more, it is the only truck on the planet to achieve the highest possible safety rating. But there is another important part of the story.  Our team thought about more than the product – we thought about the entire product value stream collaborating between design and manufacturing to make our material utilization some of the best in industry – and also worked with our aluminum suppliers from the very beginning of the development process to create an efficient recycling strategy so the aluminum can be melted down and re-used.

Our vision of success was bigger than just creating vehicles that people would buy. It was about progress and innovating a product in ways never before thought possible to create an ever better total value stream.
KS: You recently toured Toyota headquarters in Japan to learn more about how the company is adapting and improving their LPPD Systems.  How are they applying LPPD to meet their big environmental goals?

JM: Jeff Liker, with whom I co-authored “The Toyota Product Development System,” and I spent about a week at Toyota HQ, their test facilities, engineering center and manufacturing plants. Toyota’s commitment to the environment is just incredible – and it shows up throughout the organization. Waste of any kind is abhorrent to them – it is part of their DNA so to speak. Whether it’s in smaller projects like reusing old Prius batteries for power storage in their facilities or massive, long term projects like the Mirai fuel cell vehicle and working with various governments to create a “hydrogen powered society,” Toyota is constantly thinking green from the start and taking a total value stream approach to protecting and improving the environment.

A more typical example I saw during our visit to Toyota was how they went about their effort to reduce vehicle weight to increase fuel efficiency. This is called light-weighting, and it’s a growing trend in the industry. The interesting thing at Toyota is not just that they’re making lighter vehicles but their standard process for doing it.

One of the typical ways to reduce weight is to utilize thinner, high strength steels. By doing this, companies are able to not only reduce the individual part’s weight, but often reduce the number of parts required. The problem with this strategy is that these materials often have to be formed in a superheated state that requires enormous gas fired ovens that work in very large batches and require loads of time to heat the material. This process also produces an oxide residue on the parts which must be shot blasted off after forming.

None of this was acceptable to Toyota – so design engineers, manufacturing engineers and Toyota suppliers collaborated in order to deliver both a lighter, more fuel-efficient vehicle and a much better value stream. The result was not only a better product, but a remarkable joule heating process that requires only two meters of space instead of more than 30, can heat material one blank at a time in five to 10 seconds instead of huge batches, delivers a two-thirds reduction in CO2, and does not produce any residue and needs no extra operations.

I think this is an excellent example of what LPPD is all about: cross-functional collaboration, learning, and innovating product and process development to deliver solutions that maximize value to the customer and the environment.
KS: What makes an effective lean and green leader?

JM: I believe that leaders get the culture they exhibit and tolerate. I saw this with Alan and other great leaders I had the good fortune of working with. And often their priorities become clear to the team not so much by what they say – but what they do. How they spend their time. I can tell you that one of an executive’s greatest challenges is to find time. You are under tremendous time pressure. The only way sustainability will work is if it’s an inseparable part of their company’s processes and products – and a leadership priority. I always try to remember that time will make the decision if I don’t. Sustainability is not something we can be passive about anymore. It is not a “sometime thing” – it has to be part of the way we do our work every day.

It’s like Compatibility Before Completion – it has to be embedded in the way work is done. Leaders must live their values and align their team and business practices. Effective lean and green leaders never lose sight of the big picture because anytime you create a product, you are literally creating the future. Certainly for your company, if not for millions other people. A leader has to ask themselves – what kind of a future do I want it to be?