Methods of Communicating Customer Problem Impact for Development Prioritization

I often hear talk about how bad software production issues are, and how they impact a great number of customers internal or external. However, there is a gap where the people making the decisions about whether or not these issues will be fixed don't have this data. These decision makers also don't know the true extent of the problem.

Accurately defining impact of a customer facing issue will allow for effective data driven decision making by product for inclusion into future development.

Which Data Points Matter?

---

The quick answer to this question can be: all supporting info you can provide it as problems take on so many facets and need to be looked at in different ways. You will likely need to communicate from different aspects with each issue to accurately define the impact. Here are some data points I have used in the past as a guide. Refine into what works for your organization and business model.

• Is a top tier customer impacted?

• What are the number of units impacted?

• Is a customer threatening to leave?

• What is the frequency of the issue?

• Is the customer unable to use the product?

• Does the product have a major defect which impacts the customers trust?

• Is this low impact but high volume of customer contacts?

• How much money does this cost the company?

• Is the issue in the past or will there continue to be growth of the problem?

Correlate the Data Points

---

Here are the models I have used in the past for presenting these various data points in a rigorous manner.

Score each ticket by weighting the various data factors. Create a scale, say 0-100 and then for each of the questions above assign it a weight. Capture each of these data points in the tickets. Some of it can be gathered on entry, other points you will need to populate once you have completed triage. When handing off a completed ticket have the score assembled based on the weighted factors. When you are asked by development decision makers: "tell me your top 5" there is no longer guesswork. The main disadvantage I ran across with this system was lack of trust in the scoring, so you might need documentation out there showing how you arrived at these calculations.

Combine the factors together into an impact statement. This approach builds more trust with the people who need to verify and asses your impact analysis as you are communicating with words instead of a number. How you choose to build this impact statement can be based on humans assembling the above factors into a simple statement. I have also had success with building the statement programmatically: by assembling the pieces of information into a sentence. Granted all of the data has to tell the right story or the dynamically generated sentence just looks like bad grammar.

Create a live report showing the impact of the issue. This is perhaps one of the most powerful ways of communicating is to visualize the impact by querying production data and presenting to those who make decisions on prioritization. When people can see the number of customers or units having a given issue today, yesterday, over the last quarter this helps them to put a current face on the issue. Provide a link in the ticket to the report which shows up to the minute data on the impact so at any point in the future it can be re-run and current impact assessed when the decision to include in development is made.