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?

What Do I Tell My Leaders When Experiments Fail?

I’m dealing with the fallout of a failed experiment with set-based concurrent engineering (SBCE). As the product development operations specialist, I understand that LPPD experiments don’t always result in success – but my leadership team doesn’t. How do I help them understand that a failure in LPPD isn’t a total loss?

The first step we always talk about is, “What was the purpose of the experiment and were we very clear with the management team about what we were trying to prove or disprove?” A lot of times at the start of a project we communicate, “We’re going to do an experiment on set-based design to see its benefits,” and we leave it very open-ended. And like anything that you leave open-ended, that leads to different expectations from different people in the organization – those who are more familiar with LPPD obviously will have a more realistic expectation of what will come out of set-based design; senior managers will certainly be more interested in the end result, which may happen in the short term or, in accordance with product development, may happen years later.

So from their perspective, if they’re not seeing instant results, they may see the experiment as a failure when the jury may still be out. Or this may be a failure in that there was an experiment conducted with a specific target outcome, and we didn’t achieve that.

In the latter case, it’s important to remember that there is ALWAYS a silver lining that occurs. Very rarely do we have a complete and utter lack of learning in an experiment. If we do, we probably didn’t do something or just stuck with the status quo.

The first thing to usually do is do a good reflection with the experiment team to analyze what went well and what did not.

Then you can hold a report-out with the management team to share your findings. And I think this is where we start getting some clarity that the glass is either half-empty or half-full.

I remember a time where we had a failed experiment that was viewed as a failure. But when the group went through the reflection, it wasn’t quite as much of a failure as it was perceived. One team did their first set-based experiment on a given project and partway through, the regulatory requirements kind of changed up the project. And when the requirements changed, the parameters changed as well and the team was forced to change their design direction at that point.

Now the perception by the organization – the “talk around the water cooler,” if you will – was that the team was really struggling with set-based design since they’d obviously just had to change directions. They thought that was a failure in set-based design.

Interestingly, when we sat down with the team to discuss this failure, the team did not call it a failure – they called it a hiccup! They said, “Sure, it’s true we changed design direction but only with two out of the five sets we were working with.” But the real perception from the organization on why they thought the team had failed was because the project’s cost metrics went up. People interpreted the result not being achieved as a reflection on how poorly the team executed set-based design. But once the team had set the record straight with the leadership team, the response was “Oh. That makes sense. No problem – keep working on the project.” One of the directors even repeated the team’s explanation to the rest of the organization.

It’s my experience you need at least three or four experiments before organization starts to deeply understand the nuances of SBCE. And they learn enough from their successes as well as their failures to be able to really define their own way of what SBCE looks like in their own product development community.

Now, let’s talk about what you can do to manage your leadership’s expectations while the experiment is going on. You don’t want to wait until the end of the experiment to tell management about your progress. If you do, you may be disappointed, and frankly it may be several months or years – and as we all know, management likes to see results quickly.

You want to have a series of certain touch points when you’re going through the process. When we’re doing an experiment in product development – or in lean in general – we should be just as interested in the process as the metrics. We should be checking in with management more periodically when we’re going through the process in order to inform them when the process is in control or deviating. And that’s certainly where it can be helpful to have a steering committee or some sort of leadership champion that you can go to, because if the team has a problem, there needs to be a specific organization or group they can escalate it to when needed. It is a very effective way to avoid telling management about your “failure” in retrospect.

Put the ‘i’ Before the Apple

Apple, the company that once helped its customers soar past their common ways of thinking and imagine that which had yet to be created, is now trailing behind its customers. There has been previous debate about the leanness of Steve Jobs, but it’s quite clear to me that Apple has taken another step back.

“Get closer than ever to your customers. So close that you tell them what they need well before they realize it themselves.” (Steve Jobs)

Cooperation between Apple CEO Tim Cook and U2 soloist Bono led them to decide to provide everyone who purchased the new flagship product, the iPhone 6, with a copy of the band’s newest album. Apple’s customers, the two believed, would see it as yet another example of the value that the company provides them. After all, the supporters’ identification with the Apple brand – the attractive design, the fast and dependent operating system, and the friendly user experiences – is the justification for the price, which has remained high, and the increasing difference between the iPhone and the other smart phones, which have turned into commodities.

But people who purchased an iPhone expected to get a platform that would allow them to choose their content individually and personally, and they were not willing to allow the company to define their musical taste for them. Even if all of the series 6 iPhones are identical in shape and color, each phone is personal and holds its owner’s particular, unique content. After all, that’s the whole idea of an iPhone.

The community of Apple supporters viewed the move as an affront to their loyalty and a digression from the basic assumptions that are at the very foundation of the trust between the company and its customers. Pushing the U2 album (even for free) was seen as an unwelcome intrusion into the customers’ personal space, and they viewed it as a form of virus. As a result of public pressure, Apple had to make it possible to clean out and wipe off the “infected” album, and Bono personally apologized.[1]

Steve Jobs, the founder and re-inventor of Apple, defined the purpose of the company to create a great product so that:

Our job is to figure out what they [the customers] are going to want before they do… People don’t know what they want until you show it to them… Our task is to read things that are not yet on the page.” [2]

The secret of Apple’s strength, and the source of its innovation, were to be found in the interaction with their customers – that’s where the key to success can be found, not in technological leadership. This last marketing move by Apple may reveal that it has diverted its focus from empathy for the customers’ needs to a focus on promotion of a product and an attempt to convince customers to make the buy.

Does the launch of the iPhone 6 point to the end of the era of Steve Jobs, pulling Apple back into the traditional mental models [3] that they disrupted at the beginning of the 21st century? Abdication of the first part of Jobs’ sentence (“get closer than ever to your customers”), leaving only the second part (“tell them what they need well before they realize it themselves”) could pull the company backwards.

According to the alternative thinking (as a disruptive business paradigm) that Steve Jobs developed in his second tenure, the purpose of the existence of a good company is to reliably express the customer’s identity and desires. Innovation, according to this view, stems from the manufacturer’s ability to design the customer’s story and the role that he wants to play in that story, by understanding his strengths, dreams, weaknesses and fears. Apple’s success rests on its ability to build a value-proposition for the customers that can serve as a platform for change in the customers’ way of life and make them into winners in their own ideas within their own communities.

The traditional, conservative mental model – push marketing – is composed of three stages:

1. Creation of awareness

2. Generation of attention

3. Customer’s action.

The business model that is at the foundation of pull marketing – as developed by Toyota, adopted by the lean community, and articulated by Peter Drucker[4] – redefines the purpose of marketing, based on updated mental models:

The aim of marketing is to know and understand the customers so well the product or service fits him and sells itself.” – Peter Drucker

Thus, the principles of pull marketing transform business policy from selling products and services to creating a relationship between supplier and customers. This process proceeds through three milestones:

  1. Creation of attraction
  2. Affinity
  3. Customer’s Action

The commercial success of market leaders such as Google, Facebook, Toyota, Starbucks, Amazon, Waze, Airbnb, and Uber (and this is only a very partial list) stemmed from the founders’ ability to free themselves from mental models, make their business model more flexible, and divert it from a focus on the product-platform in terms of service and technology to a focus on the customer.

Whoever is able to make his mental models more flexible and attend to his customers will view technology as valuable leverage and as a tool for organizational learning.  Leaders in retail manufacturing, banks, hosting, tourism, and logistics who are focused on their customers use digital technology as a means to listen, to come closer, to observe and to learn about existing and changing behavioral patterns in their target market. For them, collection of information about the lifestyles of their customers takes precedence over and is more important than pushing marketing messages, and no less important than the management of sales.

The distance between a business mistake and the response of the market can be measured by the pace of the byte. Cook and Bono took upon themselves the authority to define what is appropriate and proper for the customer, and so they strayed from Apple’s path. It didn’t take long before they had to pay the price.

In the 21st century, commercial companies that prefer to look at themselves rather than their customers and think empathically about how a product or a service will improve their lives will not fulfill their purpose and will not reach their goals.

In your own business spaces – have you been able to change the mental models and basic thinking that form the basis for your “value proposition” and your business model?

[1] Bono apologizes for U2 album in Apple iTunes libraries after iPhone 6 launch | Daily Mail Online

[2] Walter IsaacsonSteve Jobs.  Simon and Schuster, 2011.

[3] Mental Model:  Fixed basic assumptions and patterns that affect an individual’s decision making.  These models: 1. Exist in thought; 2. Are resistant to change; 3. Affect actions and behavior, and form the basis for decision-making.

[4] Peter Drucker, Management Challenges for 21st Century (New York: Harper Business, 1999)

Take Your Product Testing to the Extreme

Many of the principles of lean product and process development (LPPD) can seem counterproductive at first glance. For example, what if someone told you that the best way to see if a product will truly work…is to break it? That’s exactly what Professor Larry Navarre of Kettering University told me when I first met him – and there was no way I could let him leave without him explaining more. That conversation turned into this interview, on his self-coined concept of Extreme Testing:

So let’s start from the ground up. What is Extreme Testing?

The principle is this: It’s not enough to know that it works. You must know when it breaks. I explain it to my students in that way because we have to test way beyond the planned operating conditions of the product or the service. What we’re trying to do is push it to its limits to find out when it breaks.

It doesn’t do us any good to test to the specification. Products will often just work to the specification. What customers really want is a very durable and reliable product. You don’t learn things just by testing to the specification.

How did you first come up with this concept of Extreme Testing? Was there a specific event?

Not exactly. Well, it was a specific product that we were developing when I was in industry before my academic career. We were developing a system. It was actually looking very, very good, both on paper and in the lab.

We thought we had a really good product on our hands. Everything looked good. When it operated it was performing well. We went ahead with the product launch, got a lot of attention and began shipping products.

One year later we began experiencing fatigue failures with critical components in some of our systems. It was really a very negative situation. We were falling all over ourselves trying to help our customers. We crashed the redesign program. And that’s when we really started doing things correctly. Instead of just throwing a fix together and putting it into the field, we actually took the time to do a lot of extreme testing until we figured out what our problem was and then confirmed the fixes by doing even more extreme testing.

How does it compare to the existing testing process on product development lines? What advantages does Extreme Testing hold?

Well, the thing that I try to pass on to my students is that you’re going to get value in extreme testing in three ways:

The first is that you’re going to get safety. You’ll know when a system fails and how to protect your users. The second is reliability. You’ll know the expected life of your product. You’ll know how it will fail. The third is knowledge. When your product fails you can learn what’s going on. You can discover improvements to your product that you would never get if you allowed it to run at the normal specification.

Sounds like a universally useful concept! But are there any industries you think would find Extreme Testing particularly valuable, maybe more so than others?

I think where you’ll find Extreme Testing most valuable is in critical environments where human injury or even death is at stake. Examples might be medical devices, aerospace, automotive safety, things like that. However every industry and every service could benefit from Extreme Testing.

Without Extreme Testing, you only discover the problems in your product when your customer puts them in front of you. Then you realize you should have done a little bit more to anticipate the negative situation. It can happen in any industry. Just because it’s not life-threatening doesn’t mean it’s any less important to your business.

I can’t help but feel that a product engineer to whom I recommend Extreme Testing would say, “That’s a waste of money. You’re just testing it to see that it breaks.” How might you respond to skepticism like that?

It’s all about set-based concurrent engineering (SBCE) – one of the unusual characteristics of LPPD, and also one of the four cornerstone principles. If you dig into SBCE what you’ll realize is, in my experience, we lack the underlying knowledge that you would get by going through doing extensive testing and developing the knowledge that we should have had.

In SBCE we would have tested the extremes of our sub-systems of the total product system. We would have created knowledge briefs that capture the design understanding and our test results from our experiments.

Importantly, we would have developed tradeoff curves to visualize our knowledge and track our progress. That would have led into knowledge that we can reuse in the future. I’d like to point out that you don’t lose anything.

You don’t waste anything in gaining this knowledge, as long as you reuse it going forward by capturing it in knowledge briefs, tradeoff curves and eventually your design standard checklist. Then, all future products will look back on the knowledge you’ve gained in the current projects.

That’s incredible value. Companies that do this have an insurmountable competitive advantage. They know their fundamental technology. That gives them incredible value in meeting their customers’ needs and exceeding them, delighting their customers with excellent products.

How do I keep visual management from becoming “wallpaper?” A Q&A with John Drogosz

How do I keep visual management from becoming “wallpaper?”

Yes, this is an excellent question! Too often, people believe that if you post information, people will automatically engage with it. If it were only that easy. Many managers try to convince everyone (including themselves) that they are visually managing their projects or departments, but during the gemba walk we see static, outdated displays. Are we just communicating information or really working with what is in front of us?

Whether you are running a project using an Obeya or managing a department using a board, here are a few ways to avoid “wall paper” syndrome.

  • Have a clear mission and scope: This seems so obvious, but far too often teams do not explicitly declare the mission of their project or area, nor what aspects of it they need to manage visually (and why). When this is not discussed, we find walls covered with a hodge-podge of everything that is going on in the area and is it difficult to see where the team is now and where they need to be going forward.
  • Team ownership: Visual management is a team sport. The project lead and the manager should not be the only ones posting information and managing the walls. Each team member is a contributor to the success of the team and thus should have some real estate on the walls to manage.
  • Less is more: Team members sometimes get overzealous and want to show everything they are doing. Suggest this to them: “I only want to post what my colleagues need to know that affects them and those items where I need their help.”
  • Dashboard, not cockpit: In today’s data rich world, it’s tempting to post all types of metrics. Unfortunately teams end up with walls that look like the cockpit of a jumbo jet (which is fine if you are an experienced pilot flying a complex machine). In PD, our team members only need key indicators everyone can understand and use to make informed decisions. It’s about making sure the team can see that they are on the right track. Keep it simple like a dashboard on a car.
  • Project and product view: In product development, we are typically managing projects, but more importantly we are creating products. Good visual management provides BOTH the view of the project and the product. Most of the time, teams fixate on the tasks and metrics associated with the project and assume the project measures adequately show that the progress of the product. This is not always the case. By having a view of the product (e.g. rendering, print, SLA part, prototype, etc.) in the area, team members can see for themselves how the product is maturing (or not). Discussions tend to be richer and more issues are surfaced when there is some visualization of the product close by.
  • Tactile: Visual management is not meant to be a spectator sport. Printing some slides, pinning them to a wall and then presenting them is not much different than a passive slide presentation. People should be able to adjust the visuals on the fly to quickly communicate status, changes, and most importantly, flag issues. Good things to use therefore are sticky notes, colored dots, magnets, whiteboards or even better white walls!
  • Actionable: Most items that are visualized should prompt team members to some sort of action, be it to confirm, question, or contest what is on the wall.
  • Quick resolution to issues: Visual management, either Obeya or department level boards, should be the andon system for the PD teams. Issues should be easy to surface, visually seen by all and most importantly need to be followed up with a robust yet rapid PDCA cycle. Many PD teams make their problems visible, but do not rapidly resolve them. If a team member has a hot pink sticky note on their board that has not been resolved in weeks, how long do you think that team member will actively participate in the visual management process? This is typically the most common cause of visual management fizzling out.
  • Flexibility: Product development is an ever changing environment, so the visual management you use needs to easily adapt. Periodically step back and ask yourself and your team members if the visuals and the process are still helping to achieve your mission. Static visual management typically results in team members questioning its real value as it will no longer suit their needs.
  • Regular rituals: Management is clearly an ongoing process. Teams need to set a cadence on what and how often they will cover the elements they are visually managing their activities. People need to make it a regular habit to attend the sessions. (This can be the double edged sword of visualization – it helps bring people together, but it can also allow people to detach from the process as they can get “caught up” by walking the walls whenever it’s convenient for them) If someone is not attending or actively participating, ask why. Likely there is a gap in the visual management process that needs to be addressed.
  • See progress: This is a pitfall many managers fall into. A good practice to keep meetings short and focused is to discuss the gaps (red items), not what is going well or has been completed. And while the focus of visual management is to surface and resolve problems so that teams may achieve their mission, it’s also important that the team see the progress they are making along the way. It is wise for leaders to periodically show through that the team is winning the game and recognize team members’ contributions.

As you can see, the visuals are the relatively easy part; the management involved is an ongoing activity that requires everyone’s participation. Keep it simple, continuously ask team members if they are getting what they need from the process to be successful, and adapt as team members’ needs and conditions change.