It’s been about nine months since I left a job in Toyota’s Strategic Finance Group for an opportunity to return to China to work for Originate China. At Originate, we create innovative web and mobile apps for clients and also based on our own internally generated ideas, and we also work with entrepreneurs to support their growth by providing strategy and engineering expertise. We are an agile development shop and focus on being nimble, which makes the Lean Startup methodology a great fit for our work.
While working in various business functions at Toyota for over 5 years,[1] I was able to see first-hand how Lean Manufacturing and the Toyota Production System has been applied to non-manufacturing functions. I learned how this methodology can be very effective within Toyota, but also how the Toyota approach to Lean Thinking in a business context with a focus on consensus-building can sometimes slow decision-making to a crawl, making the business anything but nimble. I am therefore in the unique position to apply the Lean Startup methodology to our business in China while avoiding some of the features of Toyota’s approach that aren’t ideal for startups.
Plan-Do-Check-Act and A3s
A key element of Toyota’s Lean Thinking approach is Plan-Do-Check-Act, or PDCA. The whole process is captured on an A3 (11×17 piece of paper), which, in Toyota’s context, is a structured document that walks you through the PDCA process, from understanding the problem through capturing the final outcome. The main focus of creating the A3 is not really capturing the analysis and outcome, rather it’s really about forcing you to think through and document everything as you go so so you are forced to write clearly state your assumptions along the way and can also share your findings with management along the way. A3 development is very focused on discussion and consensus-building and is therefore a an extension of Toyota’s culture, which prizes consensus over agility.
In the planning phase, the individual or team tries to make sure they fully understand the problem through a variety of methods, including “Genchi Genbutsu”[2] and “The 5 Whys”.[3] Only after the problem is fully understood does the team start devising potential “countermeasures”, or solutions to each of the contributing factors identified during the problem identification phase of the planning process. It’s only after this thorough analysis and planning — which includes significant discussion with management so that consensus is built throughout the course of the project — that the team is then ready to embark on implementing the changes. While this planning phase should theoretically be fairly short, I have learned from experience that it can take weeks or months until consensus is built and the team is ready to move on to “Do”.
The doing phase is fairly straightforward. This is when the individual or team implements the plan that was developed during the first phase. Because so much time was spent planning, it’s rare to see significant deviations from the plan during this phase. In software development this is the equivalent of the waterfall method, where you plan for everything up-front and then don’t deviate from the plan during the implementation, or “Do”, phase. It’s only during the “Check-Act” phases that results are measured, compared to the expectations documented during the planning phase, and then corrective action is taken to improve the results. Any improvement goes through the Plan-Do-Check-Act cycle again, though these later iterations are often much quicker than the first one since a general consensus was reached during the first phase.
In general, this is a great tool for the automotive industry, or other similar industries, because the vehicle lifecycle is so long that there is time for lengthy analysis and only minor changes can generally be made to products already in production. And while the overall philosophy behind the approach — iteratively understanding the current state and associated problems, planning an approach so changes can be measured to determine if they had a positive or negative affect, and then making further modifications based on those results — is of great value, as Eric Ries points out in The Lean Startup this approach needs to be supercharged for startups who are facing more unknowns than knowns.
Enter Lean Startup’s Build-Measure-Learn
At first glance, Eric Ries’ “Build-Measure-Learn” framework[4] seems like it’s a copy of “Plan-Do-Check-Act”. As someone who worked at Toyota for many years this was my immediate reaction when I first saw the term in his book. Indeed, in his book he makes it very clear that he’s applying the Lean Manufacturing approach to the unique challenges facing startups. However, having seen PDCA in action, I think it’s important that Ries has drawn a lexical distinction because how this plays out in startups is very different from what you would see at a company like Toyota.
With PDCA the initial planning phase takes up the most time, especially when Toyota’s full approach of using A3 creation for learning and consensus building is used. By contrast, with Build-Measure-Learn the cycle is not only much shorter but “Plan” is coupled with “Do” in the “Build” phase. For startups this is very sensible because the startup doesn’t know what the customers want until they build something and see how customers react to it. As Ries points out, when an idea or approach is new enough, customers often don’t themselves know what they want until they see something new and try using it. Therefore, the “Genchi Genbutsu” and “The 5 Whys” must occur right after the team has created a Minimum Viable Product (MVP). They can then put this MVP into customers’ hands, measure how they react to it, then go make changes, and measure customers’ reactions again. This short, iterative cycle allows the team to discover what customers actually want along the way, rather than going through a long planning and build cycle that may be predicated on false, but critical, assumptions.
Therefore, while it’s clear that the framework Ries presents has been drawn from Lean Manufacturing, the differences in implementation are vital to a startup’s success. Ries notes that, in talking about startups, he’s not limiting the Lean Startup approach just to entrepreneurial ventures, but the ideas he presents are also very relevant to agents of change within large, established organizations. While one approach could be to use PDCA instead of “Build-Measure-Learn” in these instances, I believe that PDCA, at least in the way it’s often implemented at Toyota, is inferior to the “Build-Measure-Learn” approach in those situations where there are more unknowns than knowns. Indeed, Ries’ approach, of which I am a big proponent, prizes agility and understanding while testing and implementing a change. It’s this agility, coupled with experimentation, measurement, and creative thinking, that gives startups a fighting chance.
Notes
[1] I was a Toyota Associate for 4.5 years, and consulted for Toyota for over a year prior to being hired.
[2] This means “digging around the roots” or “go and see”, meaning you need to get out of the office and go see the problem first-hand. This is easy to imagine in the context of a manufacturing operation, where a manager may need to go down to the floor to witness where a quality issue may be occurring. In the Lean Startup methodology, this can easily be implemented as talking with your customers directly to see what they think about your product so you can fully understand their needs and solve their problems in a unique way.
[3] This is a problem-analysis approach for root cause analysis that involves asking “why” until you get to the root cause of the problem. Its simplicity is part of why it’s so effective.
[4] See Eric Ries, The Lean Startup
