What is lean product development?

To understand lean product development, it’s helpful to know why it exists. Lean development was pioneered by Toyota Motor Company in the early 20th century. Toyota, as a new entrant into the automotive industry, couldn’t compete against the scale of American car manufacturers, so it compensated with more efficient systems that were later described as “lean.”   Whereas American manufacturers such as Ford relied on inflexible, top-down scientific management procedures which featured long development cycles and relied on predictable supply chains, Toyota pioneered lean management to achieve a similar output with fewer resources, less waste, a less educated workforce, and in less time. Toyota’s system was more effective because it was more agile and less wasteful. Whereas the R&D departments at American companies would develop a vehicle and then toss schematics over the proverbial fence to engineering to manufacture, Toyota’s R&D, manufacturing, and marketing teams worked in tandem to test, iterate, and improve its cars continuously. In the American method, errors that arose in development occasionally make it into production and led to expensive recalls. In Toyota’s method, errors were quickly identified and corrected, and the product continually improved. In the 1990’s, lean manufacturing processes were adopted by software manufacturers and partly inspired the agile software manifesto which, among other things, values responding to change over having a plan. Whether manufacturing cars, computers, or smartphone apps, companies can use the lean method to reduce waste and increase the efficiency of their product development process.

Lean product developers are fixated on building products that customers find useful because knowing what their customers want helps teams eliminate waste. Waste is defined as any part of the development process or material input, including man hours, that don’t add value for the customer. In the software industry, for example, UX designers often conduct extensive customer research and use volunteers, focus groups, advisory boards, and user tests to understand customers’ likes and dislikes. This research helps the team decide to eliminate features that customers don’t utilize, or didn’t ask for. Once customer needs are clear, product teams evaluate the spectrum of possible solutions, also known as product discovery. As Toyota learned, it’s far cheaper to vet an array of different ideas early in the development process than to learn that customers don’t like the product until after it’s already been built. A lean company hoping to build a product to help big enterprises engage their employees, for instance, could consider using surveys, seminars, and personality assessments to achieve its goal before discovering what users enjoy most, such as an inter-office messaging app.

“Value stream,” also known as the lean product development flow, is simply a term for the steps in the product development process. Think of it as an assembly line. For a car manufacturer, it could begin with conducting market research and end at a car dealership. For a software, it’s the phases the team must go through to get a working software into users’ hands. In traditional development, each department owned a piece of the assembly line and didn’t fully understand the roles other departments played. In lean development, each team knows its role in the value stream, as well as others’ roles. This awareness goes against the traditional principle of specialization, where workers are taught to master just one task, but it makes teams more creative. Lean teams that understand the larger picture are better at identifying waste, eliminating bureaucracy, and creating a repeatable, standardized process.

Traditional development cycles usually involve unidirectional handoffs, where one team delivers work to another and considers its job complete. For example, a product management team that hands a set of designs to engineering and then begins work on different project. This leads to communication errors and an erosion of responsibility. If the engineers discover flaws in the designs, they can’t backtrack to fix the errors themselves, if they discover them at all. With lean development, all stakeholders are involved in product development from day one. That means at a software company, everyone in the value chain gets to play at least some role in the ideation and design. This provides the design team with an infusion of diverse perspectives and helps them anticipate and plan for downstream issues, such as a feature that isn’t technically infeasible. Throughout development, lean teams are concerned with what’s known as pipeline management, or controlling the flow of work that goes to the design and engineering teams. This reduces buildup and allows individuals to focus their energy. Teams using the SCRUM method of agile development allocate a SCRUM Master to execute this role. It’s important that lean teams learn to begin working before they have complete information. This was an early lesson for Toyota — if factory managers waited until a car was fully designed to begin tooling machines to produce the vehicle, they’d increase the overall development timeline. If managers began anticipating the design team’s needs, they could work in parallel and be ready faster.

In lean development, work units are given general plans and reasonable goals and trusted to self-organize. That’s because customer-facing employees often have a more complete understanding of customer needs than central managers, and are often are more effective at staffing and resourcing their own projects. Lean teams are often cross-functional. For instance, a financial services software team could include designers, engineers, and product marketers so the team can operate as an independent unit. These units often conduct what are known as sprints, or 2-4 week projects that produce a shippable product.

Learning is key to the lean product development process. Lean organizations strive to capture organizational knowledge and make it available to others to avoid wasteful duplication of effort. Knowledge isn’t always easy to capture or share, and an entire field of theories and systems exist to make it more practical. Knowledge-centered service (KCS), for instance, advocates thinking about information as a byproduct of lean product design, and building knowledge bases or internal wikis where anyone can capture and share lessons learned. Companies with digital products can deploy user analytics to track events so they can see what actions users take within their product. The team behind a fitness app, for example, could see the screenflow, or path that users typically take through the app, and identify areas that users run into trouble and log out. Teams can compile this learning into lessons about where to place buttons or text for a more efficient and more enjoyable user experience.

Lean product development is generally understood to: Shorten development cycles Lean teams begin work before they have sufficient information and work in parallel with other teams to build products faster. Instead of a relay race, where one team only begins work when the other finishes, every team in the lean method overlaps and races together. Lower development costs Because lean teams share knowledge between departments and understand the entire value chain, they can identify and eliminate wasteful practices and produce more functional products. This includes reducing inventory like unpublished software, eliminating extra features, and creating a modular product that can be easily altered. Generate innovative solutions Lean workers with complete information come up with ideas for how to improve their own performance as well as that of others. A lean software engineering team, for instance, can warn the design team about technological limitations of, say, Android push notifications, and offer alternatives.    Lower production costs When lean design works properly, products are cheaper to produce. For technology products, that typically means fewer work hours, tools, and maintenance costs. For manufacturers, that could also mean fewer physical materials. Reduce redevelopment cycles Lean teams are more efficient at catching errors before they reach production. They can refine the product as it’s developed and refactor often so that there are fewer bugs and it needs to be redeveloped less often.