Maximizing Value and Minimizing Waste - Applying Lean Principles to Technical Product Management

Lean principles come from manufacturing. Toyota figured out how to build cars with less waste, and now every startup wants to be "lean."

But software isn't a factory. You can't just copy-paste Toyota's playbook. Here's what actually translates — and what doesn't.

The Core Idea: Eliminate Waste

In manufacturing, waste is obvious: defective parts, excess inventory, waiting time.

In software, waste is sneakier:

• Features nobody uses — You built it, but did anyone want it?
• Rework — Fixing bugs, refactoring bad code, changing requirements
• Waiting — Blocked on reviews, approvals, dependencies
• Handoffs — Every time work moves between people, information gets lost
• Context switching — Engineers juggling 5 projects ship none of them

Most teams waste 40-60% of their capacity on these things. Lean is about finding and eliminating them.

What Actually Works in Software

1. Value Stream Mapping

This is the most useful lean tool for software. Map the journey from "idea" to "user has it":

Idea → Spec → Design → Dev → Review → QA → Deploy → User
       ↑        ↑       ↑      ↑       ↑      ↑
      3 days   5 days  10 days 2 days  3 days 1 day

Now look at the waiting time between steps. In most organizations, features spend more time waiting than being worked on.

On one project, we found that code sat in review queues for an average of 4 days. The actual review took 30 minutes. We cut the queue to 24 hours and shipped twice as fast.

2. Small Batches

Big releases are risky. If you ship 50 features at once and something breaks, good luck finding the problem.

Small batches — ideally shipping daily — mean:

• Faster feedback
• Easier debugging
• Lower risk per deploy
• More opportunities to course-correct

I push teams toward "what's the smallest thing we can ship that teaches us something?"

3. Pull-Based Work

In a push system, work gets assigned and queued up. In a pull system, people take work when they have capacity.

Push: "Here are your 8 tickets for the sprint." Pull: "Here's the prioritized backlog. Take the top item when you're ready."

Pull systems naturally limit work-in-progress, which reduces context switching and speeds up cycle time.

4. Continuous Improvement (Kaizen)

The best teams I've worked with have a habit: every week, identify one small process improvement and implement it.

Not big transformation projects. Small tweaks:

• "Reviews are slow. Let's try pairing instead."
• "Deployments are scary. Let's add a smoke test."
• "Standups are boring. Let's make them async."

Over a year, 52 small improvements compound into massive gains.

What Doesn't Work in Software

1. Eliminating All Variability

In manufacturing, variability is the enemy. You want identical products every time.

In software, variability is the job. Every feature is different. Every bug is unique. Trying to standardize everything kills creativity and slows down problem-solving.

2. Measuring Lines of Code

Lean loves metrics. But measuring the wrong things is worse than measuring nothing.

Lines of code, story points, velocity — these are proxy metrics that get gamed. I've seen teams inflate estimates to hit velocity targets. Useless.

Measure outcomes: Did users get value? Did we ship on time? Did it break?

3. Over-Optimizing Individual Steps

You can make reviews 50% faster. But if the bottleneck is deployment, you've gained nothing.

Always find the constraint first. Optimize there. Then find the new constraint.

My Lean Checklist

When a project feels stuck, I run through this:

1. Map the value stream — Where does work wait?
2. Reduce batch size — Can we ship something smaller?
3. Limit WIP — Are people juggling too many things?
4. Remove handoffs — Can one person/team own it end-to-end?
5. Automate the boring stuff — Testing, deployment, notifications

Usually, one of these reveals the problem.

The Waste I See Most Often

After working on many projects, the biggest wastes are:

1. Building the wrong thing — No amount of efficiency helps if you're solving the wrong problem
2. Rework from unclear requirements — Spec it properly or pay for it later
3. Manual processes that should be automated — If you do it more than twice, script it
4. Meetings without decisions — Status meetings are almost always waste

---

Bottom line: Lean is a useful mental model, not a religion. Take what works (value stream mapping, small batches, continuous improvement) and ignore what doesn't (rigid standardization, vanity metrics). The goal is shipping value faster, not following a methodology.