Back

Lean Six Sigma Made Me a Better PM (Even Though I Don't Use the Charts)

4 MINS

Lean Six Sigma Made Me a Better PM (Even Though I Don't Use the Charts)

I got my Lean Six Sigma certification before I had ever shipped a product feature. For a while, I assumed that meant the certification was a "previous life" thing — something to take off the resume now that I worked in B2B SaaS. Years later, I think it's one of the most useful things on it. Not because I draw control charts in PRDs. I don't. But because it gave me a way of looking at processes that B2B PMs desperately need.

This is a short blog about what I actually use from Six Sigma — and what I leave behind.

The mental model I kept

The single most useful idea I took from Lean Six Sigma is shockingly simple: every process is a series of handoffs, and every handoff has a chance to fail. That sentence, internalised properly, will make you a better B2B SaaS PM in three weeks.

In product, the handoffs that matter aren't on a factory floor. They are:

Sales discovery → product scope
Product spec → engineering build
QA pass → customer onboarding
Customer ticket → engineering fix
Engineering fix → release notes that the customer actually reads Each handoff loses signal. Six Sigma trains you to see those losses, not just feel them.

Three Six Sigma instincts I use weekly

I don't run DMAIC cycles on features. I do, however, use the underlying instincts constantly:

Define before you measure. Most B2B teams jump to dashboards before they have a crisp problem statement. A bad problem statement guarantees a useless dashboard.
Measure variation, not just averages. "Average onboarding time" hides ten enterprise customers stuck at week six. Variation is where the real story lives.
Improve one thing. B2B SaaS roadmaps love multi-pronged "themes". Six Sigma teaches you to fix one variable, watch it move, and then move to the next. Boring. Effective.

What I leave behind

I'll be honest: there is a version of Lean Six Sigma that is wrong for product. It is the version that wants to standardise everything, eliminate variation, and write a SOP for the act of being creative. That version will quietly kill a discovery culture if you let it.

Things I deliberately don't do as a PM, even though my certification says I should:

I don't try to remove every workaround. Some workarounds are how customers tell you what to build.
I don't optimise the process before I've pressure-tested the outcome. A perfectly tuned pipeline that ships the wrong feature is still the wrong feature.
I don't run "DMAIC" projects on early-stage products. DMAIC assumes a stable system. Early product is the opposite of a stable system. The certification is a tool. Like any tool, it cuts the wrong things if you hold it wrong.

A small closing note

If you are a PM with an ops or analytics background, don't downplay it. The instinct to look at a product as a system of handoffs is rare in B2B SaaS, and it pays off compounded. The trick is to keep the instincts and drop the rituals. The rituals belong on the factory floor. The instincts belong in your roadmap.

I am, on balance, very glad I took the course. I am also glad I never tried to use it the way the manual told me to.

Background

Lakshmi skipped presentations and built real AI products.

Lakshmi Prasanna was part of the March 2026 cohort at Curious PM, alongside 17 other talented participants.