W. Edwards Deming taught manufacturers how to win by building quality into the system, not by patching defects at the end. His 14 points came out of heavy industry, yet they map cleanly to software, hardware, and blended products. If you develop products today, the question is not whether Deming’s ideas still apply, but how to use them end to end, from strategy and design to deployment and support. I have applied these principles in startups and in global companies with thousands of engineers. The texture is different in each setting, but the core moves are durable.
What follows is a practical walk through the deming 14 principles, adapted to modern product development. Expect concrete practices, a few scars, and the judgment calls that separate slogans from results.
Quality as an Economic Strategy
Deming’s first point asks leaders to create constancy of purpose. That sounds vague until you translate it into a budgeting and roadmap discipline. Quality is a capital allocation choice. If you push teams to ship features now and “stabilize later,” you pay compounding interest on defects, patch work, and rework that often costs 10 to 30 times more than prevention. The companies that last treat quality as an investment: consistent test automation, design reviews that actually reject weak work, and time set aside every quarter to reduce sources of variation in the process.
I sat on a planning review where a product VP defended a roadmap packed with features and no platform work. Support tickets had tripled in six months. It took one graph to change the conversation: monthly churn aligned almost perfectly with the slope of unresolved incidents older than 30 days. We funded a quarter of quality work. Feature velocity dipped 15 percent, and net retention rose 9 points in two quarters. Constancy of purpose is not a slogan. It shows up in the portfolio mix, in staffing, and in the stories leaders tell.
Adopt a New Philosophy, Then Teach It
Deming’s second point is about management culture. Organizations built on inspection and heroics cannot bolt on quality. They need to adopt a philosophy where the system, not the individual, is the primary lever. In practice, that means managers learn to read variation, to run experiments, and to surface weak signals without blame.
This shows up in language. When leaders ask “who broke the build,” people hide. When they ask “what in our process made this likely,” the team investigates. In a growth-stage startup I advised, we ran monthly sessions where directors reviewed one failure using a timeline and a cause map. No names, only roles and system factors. Within two cycles, engineers volunteered candidates for the next session. The tone shifted from defense to movement.
If you need a starting ritual, teach every manager basic statistical thinking. Control charts, run charts, and capability analysis take an afternoon to learn and a career to master. No need to turn product managers into statisticians. Just enough skill to distinguish signal from noise can prevent a lot of wheel-spinning.
Cease Dependence on Inspection to Achieve Quality
Deming’s third point attacks the reflex to test quality in at the end. Final inspection still matters for safety and compliance, but it cannot rescue a poor process. In software, the analog is late-stage QA and bug triage marathons. If your defect discovery concentrates at the end of a sprint or release, your process leaks upstream.
Build quality into each step. In code, that means small batch sizes, pre-merge checks, property-based tests for core invariants, and linters that reject known hazards. In hardware, it means mistake-proofing fixtures that enforce orientation and torque, parts that only fit one way, and supplier PPAP that validates the process, not just the part.
A team I worked with cut escaped defects 60 percent by adopting contract tests between services. They wrote thin consumer-driven tests that ran in CI against provider mocks. It took two weeks to write and an hour to maintain each week. The savings showed up in fewer hotfixes and better sleep.
Stop Awarding Business on Price Tag Alone
Lowest bidder purchasing is expensive theater. The fourth point asks you to minimize total cost by partnering for quality. For software vendors, that means assessing API stability, support responsiveness, and integration friction, not just license fees. For components, it means looking at process capability and change control, and asking how a supplier handles variance.
In one consumer hardware line, a fractional cent cheaper fastener caused a 4 percent field failure rate over a year because of material variability and galling under heat. The supplier’s process capability index for thread pitch drifted below 1.0, and no one monitored it. We paid a small premium to a supplier who shared control data weekly. Warranty claims dropped by millions. Procurement measured savings year over year, not purchase order to purchase order, which helped the habit stick.
Improve Constantly and Forever
Deming’s fifth point is the engine. Continuous improvement is not a workshop, it is an operating rhythm. The trap is to run one major retro each quarter, generate a wall of stickies, and ship none of the changes. The teams that move bake micro improvements into daily work and protect a small, consistent buffer for system upgrades.
A reasonable pattern:
- Keep a visible improvement backlog, sized like any other work, with clear owners and expected outcomes. Reserve 10 to 20 percent of capacity for improvement, forever, not when things calm down. Tie improvements to measurable effects: cycle time, defect density, MTTR, or customer-reported issues.
We once knocked average lead time from 11 days to 6 by stringing together small changes: pre-commit formatting, a 30-minute daily integration window for risky branches, and a “first build green” policy that blocked merges if unit test flakiness exceeded a 2 percent threshold. No silver bullet, just compounding gains.
Institute Training on the Job
Deming’s sixth point often gets lip service. Training is not a slide deck. It is deliberate practice on real work, with feedback. The fastest teams set up “golden paths” for common tasks and pair people on them: spin up a service, add a metrics counter, build a feature flag, add a database migration, publish a design artifact.
What helped most in my experience:
- A living developer handbook for critical flows, with one-page recipes and guardrails. Regular pairing and shadowing, especially for on-call handoffs. Post-incident drills where the team replays the fix in a sandbox and documents gotchas.
For product managers and designers, training includes exposure to real user sessions, sales calls, and support escalations. A PM who hears the tenth customer fail in the first two minutes of onboarding will write clearer requirements than any templated spec.
Institute Leadership, Not Supervision
Point seven flips the manager’s job from inspection to coaching. Supervision looks at outputs and nags. Leadership removes obstacles and aligns the system. The most effective engineering managers I have worked with spend the morning removing three blockers and the afternoon clarifying two decisions. They do not sit in status meetings asking for percent complete.
One practical habit: managers should own a rolling “waste list” that captures recurring friction. Slow code reviews, flaky tests, poor local environments, unclear severity definitions, handoffs between QA and dev, brittle deploy scripts. Review the list with the team weekly. Pick one, fix it, and measure the improvement. Visibility turns passive suffering into active repair.
Drive Out Fear
Point eight is the most human and the easiest to neglect. Fear kills information flow. People stop raising defects, stop admitting uncertainty, stop experimenting. The irony is that leaders often invoke “accountability” and get less of it.
Culture shifts through behavior, not posters. After a messy outage, hold a blameless review with a time-ordered narrative and explicit calls to system causes. When an engineer surfaces a risky assumption early, thank them in public and adjust the plan. If a team misses a target and shares three lessons, take the lessons and remove the public shaming. When layoffs or reorgs loom, share what you can quickly and directly. I have watched rumor mills produce more waste than any process flaw. The fix is not spin, it is candor.
Safety also lives in small rituals. A daily “what’s confusing” prompt can surface issues before they harden. A rotating meeting chair gives quieter people a turn to set the pace. Leadership’s tone in the hard week matters more than the easy weeks combined.
Break Down Barriers Between Departments
Point nine focuses on silos. Most defects are born at handoffs. Product throws specs over the wall to engineering. Engineering tosses artifacts to QA. Ops catches whatever flies through. Marketing ships messages that promise things the product cannot do. Finance adds quarter-end pressure that blows up quality.
Cross-functional work is the antidote. Durable teams that include product, design, engineering, QA, data, and a dotted line to support and sales eliminate a lot of translation loss. Where matrix structures remain, create shared goals that require collaboration: a monthly activation target that depends on onboarding experience, a reliability goal that includes SLOs and support sentiment.
On one B2B product, we reduced time-to-first-value from 22 days to 7 by moving a designer, a PM, and two engineers into a pod with a sales engineer and a support lead. The sales engineer brought call notes daily. The support lead flagged a recurrent misstep in initial configuration. The team built a guided setup with guardrails and a live config validator. Everyone owned the number.
Eliminate Slogans, Exhortations, and Targets for the Workforce
Point ten seems counterintuitive in a world of OKRs and dashboards. Deming’s beef is not with goals, but with slogans and numeric targets that ignore process capability. “Zero defects” posters do nothing if the system produces defects. “Crush the quarter” banners push people to cut corners.
Use goals to focus, not to blame. If your test flakiness averages 3 percent and spikes to 8 percent during heavy merges, no slogan will force flakiness to zero. Invest in test determinism: isolate time dependencies, stub network calls, calibrate random seeds, and quarantine unstable tests. Track the metric, not to punish, but to guide.
One marketing team set a target of 50 percent self-serve conversion for a complex workflow without looking at baseline friction. The product team took the heat for missing the number while legal and compliance required eight consent screens. The fix was not harder work. It was a process change and a different policy interaction, negotiated with legal and documented with risk mitigations. The target remained, but the plan changed to match reality.
Eliminate Work Standards and Quotas, Substitute Leadership
Point eleven pairs with the previous. Quotas and arbitrary velocity targets distort behavior. In software, story points become currency and teams game the numbers. In support, tickets closed per hour drives shallow answers and unresolved issues. In sales, monthly quotas create end-of-period discounting that trains customers to wait.
Replace quotas with systems that make good work likely. For engineering, measure flow metrics: lead time, change failure rate, mean time to recover, and deployment frequency. These correlate with both speed and stability when used as guides. For support, tie quality to customer outcomes and first contact resolution with calibration sessions. For sales, track pipeline health and win rates by segment, not just closed revenue, and align incentives with healthy deals that renew.
I once watched a team “hit” a burn-down chart by re-estimating stories mid-sprint. Everyone knew it, morale dipped, and trust eroded. We dropped the chart and adopted flow metrics. The conversation shifted to limits on work in progress, faster code review turnaround, and smoothing handoffs. Output rose without the games.
Remove Barriers That Rob People of Pride in Workmanship
Point twelve shows up in the small annoyances that drain joy. Broken tools, noisy alerts, flaky tests, unresolved design debt, and performance review systems that grade on a curve all rob pride. Pride matters because it sustains craftsmanship when no one is looking.
Engineer pride grows when they can see their impact. Ship telemetry to a team dashboard that shows usage of their features, customer satisfaction trends, and error rates. Designer pride grows when their components are used consistently across products. Product pride grows when a launch improves a metric the team cares about and customers write in unprompted.
The quickest way I have found to restore pride is to run a “sharp tools” sprint. For two weeks, freeze new features and fix the paper cuts that slow daily work: editor configs, build times, flaky suites, slow local startup. In one case, we cut local build time from 19 minutes to 5, which returned roughly one engineer-week per sprint to the team. People smiled again.
Institute a Vigorous Program of Education and Self-Improvement
Point thirteen is bigger than job training. It is about creating an environment where people grow their range. Funding courses and conferences is good. Better is to create internal guilds and reading groups and rotate people through adjacent roles. A backend engineer who spends a month on support will design more resilient APIs. A PM who shadows sales six sigma for a quarter will write clearer positioning and roadmaps that fit the market’s rhythm.
When budgets tighten, this line item is often first to go. Resist that impulse. The companies that kept learning alive during lean years came out with stronger teams and better retention. A modest approach can work: a monthly talk, a quarterly internal workshop, a book club with lunch, and a policy that encourages engineers to spend a few hours each month exploring a new tool with a short share-out.
Take Action to Accomplish the Transformation
Point fourteen asks leadership to own the change, not delegate it to a committee. Transformation touches incentives, roles, measures, and stories. It takes patience measured in quarters and years, not sprints. You cannot outsource it to a consultant and call it done.
When we rolled out a reliability program across a product line with eight teams, we started small: one team, one service, three SLOs. We published the playbook as we learned. Executives joined the first three reviews and six sigma certification online asked questions that signaled priorities: What trade-offs did you make? Where is toil highest? What will make this stick? After two quarters, other teams asked to join. We kept the bar consistent and refused to water it down for speed. Within a year, customer-reported incidents fell 40 percent and deployment frequency doubled. The transformation held because leaders changed how they spent their time.
Mapping Deming to the Product Lifecycle
Deming’s points are philosophical, but they become concrete only when tied to the lifecycle: discovery, design, development, release, and operation. The levers vary by phase.
During discovery, “constancy of purpose” means choosing customer problems with a bias for lifetime value and retention, not just near-term sales requests. “Drive out fear” means running experiments where failure is cheap and expected. If researchers feel pressure to validate pre-decided directions, you will ship lipstick on a pig.
During design, “build quality in” translates to design systems with tokens and components that encode accessibility, layout, and motion rules. Designers run “error tours” through flows to find how the product behaves when things go wrong: timeouts, partial data, offline states. This reduces the load on engineering and support later.
During development, “improve constantly” looks like small batch sizes, trunk-based development, and fast, stable tests. “Remove barriers to pride” means crisp code review norms: comments that teach, not nitpick, and a service level for review turnaround. Pairing and rotation across modules avoid specialists becoming locks.
During release, “inspection is not enough” shows up through canary deploys, feature flags, progressive rollouts, and tight observability. Use service level objectives to decide when to stop the line. Marketing and sales partner early to avoid promises the system cannot keep, which honors the “eliminate slogans” point.
During operation, “leadership, not supervision” means managers watch SLO burn rates and support trends, not dashboards of vanity metrics. “Break down barriers” connects support to engineering through a clear escalation path with joint retrospectives. “Education and self-improvement” emerges through post-incident learning sessions and reliability weeks that tune runbooks and automation.
Measuring What Matters Without Distorting Behavior
Metrics are powerful and dangerous. Deming warned against management by numbers that ignore context. Still, teams need measures to learn. A balanced set of signals, tracked for trends and paired with narrative, keeps you honest.
I have found four engineering metrics useful when held lightly: deployment frequency, lead time for changes, change failure rate, and mean time to recover. They create a shared language without dictating methods. Add customer-facing indicators like activation, task success, adoption depth, and sentiment. Tie operational health to business outcomes: it is easier to protect error budgets when you can show downstream cost in churn and support burden.
Just be careful with targets. If you must set them, use ranges and review capability. If lead time is 9 to 12 days today, ask what systemic change is needed to get to 6 to 8, not who needs to work weekends. Praise teams that surface bad news early and often. That is how you get real signals.
Practical Starting Plays for Different Contexts
A greenfield startup will not adopt the full Deming program on day one. A 5,000-person company cannot flip the switch in a quarter. Context matters.
For a seed-stage startup shipping its first product, pick three moves: invest early in basic automated tests, adopt feature flags for safe change, and run blameless reviews from the first incident. Keep procurement flexible but vet critical dependencies for reliability, not just price. Train everyone to read basic flow and error graphs.
For a growth-stage company with multiple teams, establish durable, cross-functional pods and a common definition of done that includes tests, docs, and telemetry. Build a playbook for incident management and SLOs, then onboard teams in waves. Create an improvement backlog for each team with a reserved capacity slice. Start a lightweight guild structure for disciplines that cut across teams.
For an established enterprise, begin by mapping variation and bottlenecks. Pilot in one product line with executive sponsorship. Replace quota-like engineering goals with flow metrics. Clean up your vendor base by adding process capability checks. Fund internal education programs and career pathways that reward system improvements, not just feature counts. Communicate patiently and repeat yourself. The old reflexes will surface.
Edge Cases, Trade-offs, and When to Bend
Deming’s ideas are robust, but they do not absolve you from trade-offs. Physical products with long lead times face different constraints than cloud software. Regulated sectors must keep auditable inspection while still building quality in. Startups racing for product-market fit will accept more variance early, but they still need the spine of a quality system to avoid death by paper cuts.
Sometimes you ship with known defects because the learning value exceeds the risk. Document the debt, communicate the plan, and place a short fuse on the follow-up. Sometimes you accept a cheaper vendor for a non-critical component where process capability is easy to monitor and failures are safe to absorb. Be explicit about risk appetite and detection mechanisms.
Beware cargo cults. “Blameless” does not mean “consequence-free.” If the same unsafe choice recurs after coaching and system fixes, address it directly. “No quotas” does not mean “no expectations.” Teams need clarity on outcomes and the tools to reach them. “Eliminate slogans” does not mean “no rallying cries.” People respond to meaning, as long as it aligns with the hard work of building a capable system.
The Human Arc of Quality
The thread running through Deming’s 14 points is respect for people. Not sentimentality, but the kind of respect that treats professionals as agents who want to do good work, and that holds leadership accountable for the conditions that make good work possible. When teams see problems as signals, not indictments, they improve the product faster. When leaders remove fear, the truth shows up earlier. When organizations pick partners for quality, not just price, they cut rework and waste across the chain.
I still keep a scrap of paper in my notebook from a factory floor visit. A line lead scribbled three issues that ruined her week: a jam at station four when humidity rose, a workaround for a misaligned sensor, and an inspection step that caught a defect we already knew how to prevent. None of it lived on the project plan. All of it lived in her day. We fixed the sensor mount, added dehumidification alerts, and moved the prevention upstream. Throughput rose 8 percent. Absenteeism fell. Pride returned.
Quality, start to finish, is not a department. It is a philosophy you can see in the roadmap, the code, the fixtures, the contracts, the reviews, and the way people speak to each other when things go wrong. Deming handed us the principles. The craft is in the translation.