laptop with a 404 error message on the screen
PHOTO: Erik Mclean

How can we convince companies to invest more in qualified user experience and customer experience staff — and give them the time to do quality work — when many companies believe how they’re doing it now is working? If they think the lack of UX teams or low utilization of CX experts is paying off, why would they change that?

We can start to create a shift if we calculate the financial pain a company experiences when it releases flawed or poor products that will then need fixing, undoing and/or redoing down the line.

Imagine any Software Development Organization

Let’s say the team is working on feature X, and then will work on feature Y once X is ready for release. Thanks to the project manager, the timing and the budget for each project is completely planned out. Let’s imagine the team finished X on time and on budget, and it is now headed out to customers. The team starts project Y, tapping into the budget planned for Y.

With agile, we proactively gather feedback about features after releasing them. Word comes back that feature X has problems. Customers are complaining. Some have canceled their subscriptions. A few ugly tweets have surfaced and customer support has more calls and emails than usual. Feature X is in trouble, and requires swift action.

The UX team knows X best, so perhaps they need to postpone their work on Y to stop and fix X. What might those steps be?

  • UX works with customer support to learn more about complaints.
  • UX runs additional tests and other research studies to see where customers have pain points. Whether they can accomplish this quickly or will need a longer study depends on the project and its problems.
  • The project manager reconfigures timing to shift the Y project to a later date, and puts the team temporarily back on X.
  • The product manager works on fresh stories and prioritizes how engineering will approach the improvements.
  • Engineering needs time to cycle through developing, testing, merging and other tasks.
  • A hopefully-fixed X is pushed out to the public.

Related Article: What Happens When Agile and Agile Meet?

What Did That Cost that Company?

The project manager can calculate or estimate:

  • The cost of the additional X work.
  • An estimate of wasted original X work, which was later scrapped or undone in the fix.
  • The cost of delaying feature Y.
  • The cost of all the workers who spent time dealing with X after the release. This includes support teams as well as UX, product, project, engineering and others involved in the fix.
  • The cost of customers who canceled or downgraded.
  • The cost of negative word-of-mouth or press about your company. Tech blogs typically cover public failures.
  • Did this failure affect stock price? How much market cap was lost?

Total this up, and you’ll have the company’s Cost of Poor Quality (COPQ), which is a concept from Six Sigma. The COPQ is the combined internal and external costs associated with delivering something that does not match customers’ needs.

Which budget was this added to? Was the budget for X reopened and now declared X wildly over time and over budget? Was it hidden in the Y budget because the team was working on Y when they had to stop and fix X? Or was the COPQ tucked into some other budget? Tracking down how the company categorizes these costs should help teams realize that cutting corners to save time and money now, almost always ends up exponentially costing more later.

Hopefully these calculations can help companies explain to leadership and executives the importance of product quality and getting it more right or completely right the first time around. It should prove the flaws and expense of “just ship it” and “release it anyway and we’ll fix it later.”

Related Article: Use Failure to Drive Product Growth

Could We Have Predicted This Failure?

Was it a surprise that X was flawed or perceived as broken? Or was X released despite knowing it was flawed or broken?

If the failure was a surprise, clearly there was a need for more UX process and testing before engineering burns time building something that customers might not like. Code gets tested before it gets released, UX must be allowed to test concepts and the execution before coding them. While this adds time during the UX process, it saves the company from unnecessary risks and from suffering the Cost of Poor Quality.

If the failure of feature X wasn't a surprise, keeping in mind the COPQ, was it still a smart business decision to “just ship it”? Is rushing something known to be flawed and delivered to the potentially-paying public an ethical business practice?

Related Article: Let's Retire These Common Product Sound Bites

Let’s Not Congr-agile-ate Ourselves Just Yet

Lean, Six Sigma and agile are all against defects, wasteful processes and anything that distracts our well-oiled cadences and planned releases.

Lean Six Sigma defines quality as matching what customers’ need. Quality is not how much a stakeholder liked the idea, how fast it went to market, or how little was done at each step. Companies desiring to be truly agile must make customer satisfaction the top priority.

So while you think what you’re doing now is “working,” maybe it's time to reevaluate and take a closer look at the costs of your projects, financially and from a customer satisfaction perspective.