Better Software Quality using Customer-Driven Quality: Getting Ready

In previous posts, I described the how the Customer-Driven Quality framework can improve your software quality by making sure quality & testing efforts are focused in the right area: customer satisfaction. The framework contains two main sections, a life-cycle view (Define, Build, Test, Support) and the surrounding practices (Focus, Empathy, Engagement, Learning). The first, and most important of these surrounding practices is Focus.

In this context, Focus means to place customers and customer-driven quality at the center of your teams activities. Providing your team with the overall context for customer focus, and showing them how their activities fits in the bit picture, shows them how their jobs and activities really matter.


Values are the foundation upon which customer-driven quality is built.


Many organizations publish a statement of values, and these documents usually state a commitment to providing a value to your customers. Here are a few examples:

  • Google: “Focus on the user and all else will follow”. 
  • Apple: “Apple is committed to bringing the best personal computing experience to students, educators, creative professionals and consumers around the world…”
  • Intuit: “We put customers at the heart of everything we do. We work together to deliver end-to-end experiences so profound that customers love using our products and services, and actively recommend them.”

Of course, software is developed in many other organizations than commercial software development companies. Here are a few examples from government agencies.

  • Health and Human Services: “The Department of Health and Human Services (HHS) is the United States government’s principal agency for protecting the health of all Americans and providing essential human services, especially for those who are least able to help themselves.”
  • Internal Revenue Service: “The IRS role is to help the large majority of compliant taxpayers with the tax law, while ensuring that the minority who are unwilling to comply pay their fair share.”
  • National Security Agency: “Our customers range from U.S. decision makers to service personnel who are in harm’s way.” 


Once you have a connection to the organizational values, its time to define your operating principles. The principles are one click down from the values, and are designed to help your team make decisions.  Two principles we use for customer-driven quality are:

  • Customers Define Quality: We have a variety of definitions of software quality: bug-free, performant, meets requirements, etc.  These definitions are mostly inwardly focused, based on our processes.  Explicitly stating that customers define quality leads us to think about how to learn from our customers.
  • When in doubt, test with customers: Many decisions, like feature content or quality decisions, are made based on opinions. Too often, the decision is made by the person with the loudest voice, or the highest paid person in the room (we call them hippos)

Team/Group Goals

After identifying your organization’s values and defining your operating principles, its time to include customer-driven quality practices in your team’s goals. Team goals are vital, as these goals lie side-by-side with other priorities for your team, and can be seen as competing with your other goals. Its important that your stakeholders, like product owners, marketing, and your leadership, agree with allocating time and effort for customer-driven quality activities. In my experience, the stakeholders are usually interested in focusing the quality team on building better quality for customers. I’ve found it useful to declare these goals along-side of the other goals for the team.

If you manage via scrum or other Agile methodology, you’ll want to create a set of user stories associated with customer-driven quality activities.

Individual Goals

Organizations differ in the degree of formality of Performance Management systems. Some have very formal goals that are frequently updated, others are less formal. Regardless of the culture of goal setting or monitoring progress towards these goals, the activities associated with Customer-Driven Quality should play a large role.

Everyone in the organization can participate in the customer-driven activities. Many have customer interactions as an explicit part of their job, while others need to take the initiative to engage in customer interaction. I expect everyone on the team to participate, even the test automation framework developers.

One of the most powerful ways to influence any activity is to model that behavior yourself. If your team sees you investing your time talking to customers and gaining insights from that activity, they are very likely to participate as well.

Team Composition 

Everything starts with the team building your software. Without the team, the software wouldn’t exist to delight customers. So, efforts to prepare for Customer-Driven Quality should start with the team.

In addition to technical, process, and leadership skills, your team should also have some customer advocacy mindset built in. A very fertile area to recruit customer advocates is from the customer care organization. What they may lack in automation or coding skills they compensate with deep knowledge and empathy for your customers. In the customer care role, they were talking all day directly with customers, helping them through problems or training them in how to use your software. Who better to help build the next generation of your products than the people who supported the previous generation?

In my personal experience, the best software testers and quality engineers have started their career in the customer support role.

The venn diagram shows a team mix of domain experts, people with technical skills, and those with deep customer empathy. Think through your allocation along these dimensions, and pay special attention to those in the middle, where they have all three.

Venn Diagram showing skills and mindset for a customer-driven quality organization

You may be asking, where are testing skills in this diagram? Well, everyone is expected to be great at testing. Testing is a prerequisite to join this diagram.

This post showed how I focus on implementing a customer-driven quality program. I start with the organizational goals, define several principles, get buy-in from stakeholders through the goal setting process, and allocate those goals to individual people. I also use customer affinity/empathy as part of the skills needed to compose the team.

Future posts in this series will spell out more of the practices for customer-driven quality, organized by elements in the framework.