Lean is everywhere: industry, product, startups, management, continuous improvement. It is often presented as obvious, almost as a universal truth. Yet the more seriously we look at Toyota, the more one question emerges: do we really understand what we are applying?
Lean is often reduced to tools.
In many organizations, Lean is summarized by a few simple ideas: reduce waste, optimize flows, deliver faster, standardize practices and continuously improve.
This interpretation is not wrong. It is incomplete. It mainly refers to a logic of operational efficiency, strongly inspired by the Toyota Production System, Toyota’s production system.
The problem appears when this production logic is applied to topics that do not yet belong to stabilized production.
Using Lean as an optimization toolbox while the problem to solve is not yet sufficiently understood.
Toyota does not only do TPS.
The Toyota Production System aims to optimize, standardize, reduce variation and improve what already exists. This logic is powerful when the system is stable, known and repeatable.
But Toyota was not built only on its ability to produce efficiently. A major part of its strength also comes from the way it designs products, explores options and learns before locking in decisions.
This is found in the Toyota Product Development System, a logic discussed far less often but essential for understanding the difference between production and design.
TPS and TPDS: two different logics.
TPS is suited to optimizing a known system. It seeks to stabilize, make reliable and improve an existing operation.
TPDS responds to another situation: when the solution is not yet known. The point is then to explore, learn, test several options and gradually converge toward a robust solution.
In other words, TPS optimizes what is known. TPDS helps learn what is not yet known.
The real problem: applying production logic to design problems.
Many organizations today make a simple mistake. They plan and steer complex topics as if the answer were already known.
We see this when a roadmap is frozen too early, when a transformation is broken down before real dependencies have been understood, or when a product is optimized before its relevance has been validated.
The result is predictable: rigidity, rework, fragile decisions, repeated arbitration and team overload.
In a complex system, not everything can be predicted. Needs evolve, constraints interact and solutions narrow progressively. The organization must therefore learn as it moves forward, without confusing learning with improvisation.
Before optimizing, you need to know whether you are working in a stable system or in a system still under construction.
The contribution of value analysis.
What is often forgotten is that Toyota integrated functional analysis, value analysis and value engineering logics very early.
These approaches connect the real need, value created, technical constraints, costs and design decisions.
The goal is not only to produce better. It is to design more intelligently, avoiding unnecessary additions or locking in insufficiently informed choices too early.
The heart of the system: learn before locking in.
One of the most powerful principles associated with product development at Toyota is Set-Based Concurrent Engineering.
Instead of immediately choosing one solution, several options are explored in parallel. Teams test, learn, gradually eliminate options that do not hold up, then converge toward a more robust solution.
This logic may seem slow at first. But it often avoids late errors, costly rework and decisions made with too partial an understanding of the problem.
You iterate where you are learning. When learning becomes sufficient, you can lock in. Only then can you produce and optimize.
Teams do not converge by themselves.
Another common confusion is to imagine that several teams can explore in parallel and then converge naturally.
In reality, teams constrain each other. A decision on one subsystem can eliminate options elsewhere. A production constraint can change a design decision. A cost requirement can reduce the space of possible solutions.
Convergence is therefore not simple alignment. It is a structured elimination of options, fed by learning, constraints and arbitration.
What this changes for SMEs and mid-sized companies.
In a business transformation, the same trap exists. Many leadership teams seek to optimize an operation before understanding what actually needs to be transformed.
Yet a reorganization, industrial transformation, project portfolio evolution or HR ramp-up does not always belong to a stable system. These are often systems under construction.
In that case, the right question is not: which Lean method should we apply?
The real question is: are we optimizing something we already understand, or are we still learning what we need to build?
Operational conclusion.
The problem is not Lean. The problem is the context in which it is applied.
In a stable system, Lean can help optimize, standardize and improve. In a complex system, it must first help learn, structure decisions and progressively reduce uncertainty.
Toyota does not try to be right too early. Toyota seeks to learn enough to decide at the right time.
This is exactly the opposite of what many organizations do when they lock in a solution before truly understanding the system they are transforming.