The Not So Hidden Costs of Poor Product Quality

The software industry pays billions of dollars each year for delivering poor quality.  The average cost of fixing a bug or usability issue is around $100,000. The average cost of fixing a performance issue is around $1M.  

These big round numbers might get our attention, but they aren’t very actionable.  The process for managing quality varies dramatically from company to company and product to product with good reason.

An early stage startup will allow products to go to market with all kinds of issues in hopes of getting useful feedback.  The risk and resulting cost are relatively low.  They might be paying a premium for feedback with this approach, but it’s sometimes the easiest way to find out where the weak spots are and make adjustments.  Startups are (or should be) designed to pivot quickly.  

Large companies certainly have a much lower tolerance for risk.  Consequences are magnified and taken very seriously.  Data loss, security breaches, and lawsuits are expensive, real threats. The secondary impacts add more expenses like consulting services that lead to leadership changes, reorgs, and other costly system changes.  Billion dollar companies tend to avoid this by moving more slowly and spending real time and money on upfront risk analysis.  

SMBs, however, tend to have a lot more churn and a lot less self awareness.  Leaders may not be aligned on risk tolerance.  Business development vacillates between strategic and opportunistic.  There might be invisible gaps in skill sets around the organization.  Top down pressure to get value out to users drowns out the cries for help from the trenches.  

Tech leaders can feel when their organizations are struggling with quality and might jump to conclusions about how to fix things.  Before defining solutions, let’s look at some leading indicators that quality issues are going to show up on financial reports: 

  • Is there a steady increase in customer support issues?
  • Is the velocity of engineering teams decreasing?
  • Are there new and unexpected requests for infrastructure?
  • Is there a shift in product usage?
  • Is user acquisition declining?
  • Is the sales conversion rate declining?
  • Is marketing responding to more negative comments on social media?
  • Is there an increase in P0 issues?

If attention hasn’t been paid to these trends, then there are probably signs in the financial reports, too.  Look at all of it.

Examine the results holistically.  Any one line item in isolation might lead to short term solutions or increased spending that don’t address root causes.  More unresolved support issues?  More budget for support to manage the increase in tickets.  Not enough engineering capacity?  More headcount for engineering.  User acquisition declining?  More budget for marketing.  A showstopping P0 issue?  All hands on deck until the issue is fixed.  

Looking at the data as a whole will tell a story of what, when, and how the issues arose.  The “why” will be derived.  This might be what you hear:

  • We missed it in testing.
  • A change was deployed outside a release.
  • We didn’t expect this spike in usage.
  • The code for this feature is really complicated.
  • The original design didn’t scale.
  • We didn’t plan for this use case.
  • We had to get this feature out quickly.

Ask why again:

  • We don’t have the right test cases.
  • We thought it was a low risk change.
  • We didn’t think operations needed to plan for this.
  • A different person wrote this code originally.
  • We didn’t define all the performance requirements.
  • We didn’t ask for enough user feedback.
  • We were focused on this one customer.

Keep asking why, and themes will likely emerge:

  • Quality assurance does not have a strong voice or enough support within the product delivery teams.
  • Systems that support quality (CI/CD pipelines, automated testing, monitoring, etc.) are not well integrated or used in the software development process.
  • Quality has not been consistently integrated into the values and mindset of the organization.

All of this points to a need to create a consistent culture of quality throughout the organization.  Define what quality means for each team.  Measure the things that are important.  Be clear about expectations.

With consistent criteria and a clear message about quality, teams will feel empowered to speak up, push back, call out risks, and take the necessary steps to avoid costly mistakes.  Your teams know, collectively, what needs to be done.  Create the culture and the mechanisms that empower them to build the best solutions.


x

Comments

Popular posts from this blog

Costs of Deprioritizing Company Culture

Here's What Your Digital Transformation Strategy Is Missing

A Patagonia Story: Cultivating Accountability with Design Thinking