Lean Product Development
Eliminate waste, maximise value in product creation
Lean Product Development applies Toyota Production System thinking to product creation: eliminate waste (anything that doesn't add customer value), maximise value flow, decide as late as possible, deliver as fast as possible, and empower the team. It differs from Lean Startup by focusing on the development process itself — reducing batch sizes, managing queues, and optimising flow — rather than hypothesis validation.
Derived from Toyota Production System principles (Taiichi Ohno, 1950s), adapted for product development by Don Reinertsen ("Principles of Product Development Flow", 2009) and Mary and Tom Poppendieck ("Lean Software Development", 2003).
Use Lean Product Development when
- ✓Teams experiencing long lead times between idea and delivery
- ✓Organisations with large WIP inventory and slow throughput
- ✓Products where reducing time-to-market is a competitive advantage
- ✓Engineering-led teams seeking to apply system-level thinking to their delivery pipeline
Avoid it when
- ✗Very early-stage products where problem-solution fit is unproven — Lean Startup applies first
- ✗Teams without engineering and process change authority to redesign their workflow
- ✗Organisations where the bottleneck is strategy, not execution
Key Concepts
Partially done work, extra processes, extra features, task switching, waiting, motion, and defects — adapted from Toyota's 7 manufacturing wastes.
The amount of work processed together before moving to the next stage. Smaller batches reduce WIP, improve flow, and surface defects faster.
Queues are the primary cause of long lead times. Managing queue lengths is more impactful than increasing team capacity.
All development decisions should be made using an economic model that trades off: cost of delay, development cost, and risk.
Regular, predictable rhythms for integration, review, and planning reduce transaction costs and make flow visible.
Explore multiple design options in parallel and narrow down late — avoids committing to a single solution too early.
How it works
Map the full flow from concept to customer. Identify where work waits (queues) and where waste is created.
Break work into smaller increments. Ship more frequently. Each smaller batch provides faster feedback and reduces risk.
Apply WIP limits, pull systems, and cadence to maximise throughput. Address the constraint first (Theory of Constraints).
Regular kaizen events and retrospectives to surface waste and improve the system, not just the team.
Tools that support Lean Product Development
Industry standard for software development teams — most PMs will encounter Jira in their career
Exceptionally intuitive and visually clean interface — one of the lowest onboarding friction tools for non-technical teams
Highly visual and intuitive interface with color-coded boards — one of the easiest PM tools for non-technical teams to adopt
All-in-one platform replacing multiple tools — docs, whiteboards, goals, time tracking, chat, and project management in a single workspace
Unmatched flexibility as an all-in-one workspace — combines docs, wikis, databases, and project management in a single tool
Spreadsheet-familiar interface makes adoption easy for teams transitioning from Excel — minimal training needed for basic use
Extremely intuitive drag-and-drop Kanban interface — virtually zero learning curve, new users productive within minutes
Browser-based with no installation required — runs on any OS and enables instant sharing via URL, removing friction for cross-functional collaboration with PMs, engineers, and stakeholders
Frequently Asked Questions
Lean Startup focuses on validating business hypotheses under uncertainty using MVPs and experiments. Lean Product Development focuses on optimising the product development system itself — reducing waste, managing queues, and improving flow. They complement each other: Lean Startup informs what to build; Lean Product Development improves how you build it.
Cost of delay is the economic impact of not delivering a feature sooner. It's the most important input to development prioritisation. If a feature generates $50k/month in value, delaying it by 3 months costs $150k. Prioritisation should maximise CD3 (cost of delay divided by duration).
Instead of committing to one solution early, keep 2–3 design options open until you have enough information to choose. Run them in parallel for the ambiguous parts, then converge. This is most valuable for high-uncertainty architectural decisions where premature commitment is costly.