It's time to re-frame how we think about software problems that surface “in the wild” – that is, after the software is available and in “production” use. What if we stopped describing signals from our customers with reference to the development process, as bugs vs enhancements? What if instead we thought of all issues raised about released software from the customer perspective? Maybe it's time to shift to an insufficiency frame.

The “bug” frame centers figuring out what's wrong. The insufficiency frame directs our attention toward a better future for our customers, our products, our companies, and ourselves. If we can take something that's insufficient and make it adequate we've stepped onto a path that leads to ongoing improvement in products that will inspire customer trust, have a durable and sustainable market life, and enable users to work with confidence, efficiency, and effortless enjoyment.

Bugs, Blame, and Bureaucracy: The Unsustainable Status Quo

Support agents, product managers, and developers sometimes struggle to categorize user feedback as bugs or feature requests. This categorization process can lead to inefficiencies:

• Support escalations and unnecessary consultations with product teams
• Splitting issues into separate queues (bug fixes vs. feature requests) with different prioritization criteria
• Delays in addressing issues due to queue management

The root cause analysis often devolves into determining fault:

• Was the software implemented incorrectly?
• Did the design overlook certain scenarios?
• Were requirements incomplete or intentionally ignored?
• Has a recent change introduced new issues?

This approach can create a negative culture where:

• Customer contact is seen as a failure
• There's pressure to prevent future issues at all costs
• Blame is assigned, potentially leading to personnel changes

Embracing Insufficiency: A New Framework for Software Problem-Solving

What if we just didn't do this anymore? We could instead consider these contacts as a signal of insufficiency, no different from signal we gather by our outreach or research.

There are all kinds of ways that an application in production use can be completely sufficient in some, maybe most, situations or purposes yet insufficient in others. These departures from adequacy could cause a wide range of actual, perceived, trust, or reputation harms, regardless of when, how, or why these situations came to exist.

Let's look at some of the several types of insufficiency, some examples, and how treating all requests as a single stream makes sense no matter the nature of the insufficiency. In the varieties and examples below some would are more severe and need a solution more urgently. On the other hand, some might not be part of our strategic vision or just won't rise to the top of the stack as we prioritize work.

When we handle these in a single stream we give ourselves the best chance to improve both the software and the product. We can offer our top priorities to development, describing their significance and urgency. And we can leave it to the development organization to provide technical services that can address prioritized requests at the needed level of urgency.

Varieties of Insufficiency
1. Functionality
2. Usability
3. Performance
4. Compatibility
5. Support
6. Security
7. Customization
8. Reliability
9. Integration
10. Cognitive Load
11. Feedback
12. Aesthetics

Insufficiency Examples
* crashing frequently
* failing to perform core tasks correctly or adequately
* missing expected capabilities
* hard to use
* unpleasant or displeasing sensory characteristics
* perception that it's too slow
* unintuitive interface
* limited cross-platform support
* documentation and help resources are incomplete, obsolete, or available in a dated format
* desired flexibility or customization options aren't available
* desired APIs or extensibility options aren't available
* poor error messages

Process implications of adopting the “Insufficiency” frame

Once we make this shift we'll never again have—at the tech-business or company-customer boundary—a discussion of whether development will identify the issue as a bug, defect, change, enhancement request, new feature, or anything else.

Instead, we'll have a single queue to prioritize by its customer impact, and the impact on our business—but not by the way a developer might categorize it.

But won't this mean developers will spend all their time on fixing problems and never be able to accept new work that improves our product? No! Here's why:

• Some problems, no matter when, how or why they were introduced, are more important to our customers and our organization than others.
• Development leaders can choose from a variety of team topologies in order to balance handling interruptions from critical requests while continuing to deliver planned issues.
• Modern development practices such as continuous delivery create workflows that release updated software frequently, sometimes hidden behind feature-level controls so they can be revealed when ready. This process implies that some software changes can be released with immediate availability rather than masked—and in that way satisfying the need to resolve critical requests quickly.

Benefits of the Insufficiency Mindset

I believe there are several benefits to be gained by the organization that can make the shift away from “bugs” to “insufficiency.” I don't have empirical data—I don't know of a company that has adopted the “insufficiency” frame—but based on my experience I believe it's possible to realize benefits like these:

• shorter time to resolution for serious issues
• increased capacity (bandwidth) among customer-facing personnel
• more customer touchpoints, better onboarding and training, opportunity to build customer relationship skills (owing to that increased bandwidth) leading to stronger customer satisfaction and improved renewal performance
• better visibility in product and development about the state of the system
• better decision-making in product and development (because they can learn from all the inbound signal)
• potentially improved product quality (because seemingly disparate issues might be recognized in development and product as related in a way that influences the issue response)
• improved team effectiveness—when everyone is free of the blame game team members can express their natural capability for creativity and excellence
• enhanced employee satisfaction

Conclusion

Can we shift from a deficiency to an insufficiency mindset? If every request is a signal of insufficiency, and we no longer try to assess whether the request represents a bug, enhancement, or feature request, we can streamline internal processes and improve software development efficiency.