Disclaimer: People often borrow the seven wastes from manufacturing and paste them onto product development. The result is usually shallow.
To understand the nature of waste in digital product development, one must move beyond the visible “scrap” of the factory floor and investigate the entropy of information and the dissipation of human potential. At its most fundamental level, digital waste is any activity that fails to do one of two things: reduce uncertainty through validated learning, or deliver real value to the right users and stakeholders. In knowledge work, where the product is often intangible code or user experience, waste is frequently invisible, residing in queues, misunderstood requirements, and unvalidated hypotheses.
Why Context is King
There is a lot of debate whereby people have learnt from manufacturing and applied same approaches of waste reduction in product development. Manufacturing is a repetitive process whereby the objective is not only to reduce variance but also to maximize the efficient reproduction of same physical object. Product development is a process of creating new information by reducing uncertainty. Manufacturing reduces variability in execution to protect quality, while product development benefits from variability in ideas and experiments, but still needs disciplined, low variability execution to keep feedback fast and learning reliable. Variability in ideas is good, variability in execution is costly. Also in manufacturing work in process (WIP) is physical inventory which is visible however in product development WIP is invisible leading to massive queues that remains unaccounted for.
The concept of waste reduction began with the Toyota Production System (TPS), architected by Taiichi Ohno. Ohno defined the primary objective of any production system as the relentless reduction of the “time line” from the moment a customer places an order to the moment cash is collected. In his seminal work, Toyota Production System: Beyond Large-Scale Production (1978), he identified seven categories of waste (muda). This manufacturing-centric view underwent a second-order shift with the advent of the Lean Startup movement (pioneered by Eric Ries) and the Lean Product Playbook (detailed by Dan Olsen). Here, the “unit of progress” shifted from physical parts to “validated learning” the scientific verification that a product creates value for a specific targeted customer.
Further refinement came from Donald Reinertsen in The Principles of Product Development Flow, which introduced the “Economic View,” arguing that the most dangerous waste in knowledge work is Queueing and Work in Process (WIP), which remains financially and physically invisible until they manifest as market failure.
To evaluate WIP from a second-order perspective, lets analyse the impact of this :
- Delayed Feedback and Stale Knowledge: High WIP levels inherently extend the time work spends in the system. When feedback loops are elongated, a small misunderstanding at the start of a process can propagate into massive rework by the time it is detected, turning a “step of value creation” into a factory for defects or rework.
- Accumulated Risk: WIP should be viewed as “accumulated risk”. Until a feature is completed and validated by a customer, the effort invested remains an unproven hypothesis. Large amounts of WIP mean the organisation is betting its runway on unvalidated assumptions. Assumptions are often not validated; the heart of MVP is mostly abused.
- Non-Linearity and Complexity: In complex systems like software development, high WIP increases the probability of task switching forcing delayed feedback. Hence it forces the system to undergo rework. The longer work sits, the more context decays, and the more rework you create when reality finally hits.
Drawing from the provided sources, the types of waste in the digital product development can be categorised as follows:
- Overproduction: Building the Wrong Thing
Ohno considered overproduction the “worst enemy” because it conceals all other wastes. In digital terms, this is the efficient production of features or products that nobody actually wants.
An example is :
- Building a “feature-rich” MVP before validating the core value proposition. This waste stems from an “inside-out” mindset where assumptions are treated as facts. A product can fail product market fit and still be valuable if it generated strong learning quickly. It becomes waste when teams build and scale without validation.
- Inventory: Work in Process (WIP)
In digital product work, inventory is unfinished work: half written requirements, code that has not been merged, or features that are built but not released. This work is risky because it has not met real feedback yet. The more WIP you carry, the longer it takes to spot errors and the more rework you create. And because it is information, it stays invisible in financial reporting, so it quietly grows until it slows everything down.
- Waiting: Delayed Feedback Loops
Waiting occurs when a process stops because it is expecting decision making. Developers waiting for stakeholder approval, code reviews, or environments. Delays in feedback induce “stale knowledge.” If an engineer makes a bad assumption in week one but isn’t reviewed until week ten, that error propagates through the system, exponentially increasing the cost of correction.
4. Transportation: Handoffs and Silos
In knowledge work, transportation becomes waste when information crosses boundaries without shared context, fast feedback, and clear ownership. This causes delays, misinterpretation, and loss of tacit knowledge.
- Over-processing: Gold-Plating and Complexity
This involves performing more work than is required to deliver the value the customer seeks. Creating high-fidelity mock-ups when a hand sketch would suffice, or adding “delighters” before “must-haves” are stable. This often arises from a “fascination with sophistication,” where teams seek complex solutions for problems that require “inherent simplicity”. Do not get me wrong “just enough” time spent doing the act of value creation process is still NOT a waste.
- Motion: Context Switching and Task Switching
Task switching is a symptom of overloaded resources. It imposes a real cognitive switching cost and noticeably reduces throughput. Do not get me wrong task switching is not the enemy unfinished work is. Switching can be valuable when it reduces work in process by finishing, unblocking, or validating a decision inside the same objective. In other words, switching that closes a learning loop is often a flow improvement, not waste.
- Defects: Rework and Technical Debt
Toyota’s principle of Andon Cord was designed to “stop the line” as soon as a defect was detected to prevent its recurrence. Fixing bugs found late in a release cycle or re-coding features because acceptance criteria were misunderstood. Rework is a failure of the learning process. High performing teams use TDD and Continuous Integration to catch many code defects early, but the biggest defect in product development work is often building the wrong thing, which requires fast feedback loop and explicit hypothesis testing, not only stronger engineering.
- The Eighth Waste: Unused Human Potential
While not in Ohno’s original list, it is heavily implied in his “respect for humanity” .Treating highly skilled engineers like “code monkeys” rather than “value creators”. When a system forces people to work at an “unsustainable pace” due to poor organisational structure, it kills the creativity required for innovation.
Waste is a system effect: Please note it requires a situation awareness of the system.
– Rework is caused by delayed feedback which in turned is caused by high work in process.
– Rework caused by requirements aiming certainty through documentation. “Just enough” requirements which allows validation to occur fast. Weak requirement gathering can still cause rework.
– Escaped errors causing rework which in turn increasing the transaction cost.
– Knowledge transfer is not bad. Lost knowledge because learning did not spread and stayed local to one team. Other teams end up relearning from the scratch which in turn making the same mistakes.
– High utilization creates queues which inflates lead time and delays learning.