Background
Developing a software product is not a one time event. It starts a relationship between the builders of the product and the operators of the product. Understanding and prioritizing this relationship is the key to continuously improving the product and the success and satisfaction of all involved. In Agile Methodologies, this relationship building between the Development and the Operation of the product is referred to as DevOps.
What is DevOps?
DevOps is breaking the Development-Operations barrier. The focus and common understanding of DevOps, however, tends to be fairly narrow with the focus leaning more towards the “Dev” side. DevOps is most commonly thought of as frequent, rapid release cycles with automated deployment and automated rollback, with the cornerstone on the development team being continuous integration with automated testing. Automating everything where possible is a core strategy in DevOps. Feedback mechanisms tend to be mostly through monitoring to catch problems quickly so that they can be fixed, affecting the least number of customers as possible.
The automation is what makes deployments less painful, so that they can be done more frequently, in smaller batches with less risk as less is changed per deployment. This leads to the customer getting fixes sooner and more frequently, thereby theoretically increasing satisfaction.
With all of the advances in DevOps, it is easy to focus on delivering more, faster, as our important measures of success. However, DevOps is as much about listening as it is about delivering. Going beyond monitoring for code or server failures, we can monitor for operator-driven feedback. For example, how do we know we are delivering the right things? How well are we informing our operators of this work and getting their feedback effectively? Are we doing everything we can to help our customers understand the product and is the guidance effective?
Developing a software product is complex, yet flexible. This means the closer the operators are to the developers, the shorter our feedback loops can be, and the better the product will become. A full DevOps implementation has developers, testers, and operations engineers working together and having common, business-oriented goals that cover the whole value chain. Feedback mechanisms covering the whole value chain must be in place to ensure a complete and continuous assessment to maximize the awareness fueling continuous improvement.
Choosing this wider understanding of DevOps presents us with a vast number of additional strategies and objectives for improving the relationships surrounding our product, enhancing the feedback loop which fuels its continuous improvement and overall success.
Measures of Success
Under a narrow understanding of DevOps, we can fairly easily measure our success by delivering more faster. We would improve at this measure by optimizing for flow and improving the time to market. Continuous improvement, and thereby success, would be better and better numbers over time.
Adopting a wider understanding of DevOps opens the door to additionally measuring success by whether or not we are delivering the right things, as well as Customer Satisfaction in general. We improve at these measures by effectively requesting feedback and responding through deployments of our product. Customer Satisfaction improves as we deliver more of the right things more frequently. Additionally trust builds every time we make good on this commitment to listen and respond, and close relationship can develop, allowing the increased likelihood of more innovative ideas being shared from operators of the product.
Customer Satisfaction Goals
Our long-term goal for our customers is that they are satisfied, successful users of our product because they have (and use) efficient, reliable support mechanisms. This satisfaction depends on reliable support, our listening to feedback, exchanging ideas and knowledge, and then responding with improved experiences. This makes for a continuous loop of feedback and delivery. Understanding and improving this loop will improve the relationship and the product, and thereby customer’s success with the product, as well as their satisfaction.
Customer Satisfaction Feedback Loop
Our customer’s satisfaction starts with a confidence in their use of our product. This depends largely on their understanding of how to use the product. In the spirit of DevOps, we can automate training and onboarding to our product by building in a contextual self-help system. This automates better product understanding and usage, as well as the general improvement of operator feedback. This then become the first operator feedback point, where we will want to know if our help is actually helpful, and how we might improve it. As this contextual help is improved so are our customer’s chances of success. This also improves the feedback received, as pure “user error” is reduced, shifting the ratio toward ideas and feature requests rather than bug reports.
Where self-help is still lacking, options to seek direct assistance should present themselves. From here, a good customer experience depends on an intuitive ticketing system where the request for help is clearly acknowledged and tracked through to completion, as well as clear and consistent standards of care being managed and communicated clearly from customer service representatives.
While some customer’s help requests can be confirmed satisfactorily resolved at the ticketing system, other’s feedback will need to be classified and processed as a feature request. This is the feedback needed to fuel customer driven continuous improvement. The greater visibility the reporter has into how theirs’ and others’ ideas affect the product roadmap, the more likely they are to feel heard and that their time in this relationship is not wasted.
Whether bug fixes or new features are being deployed, informing operators of the product about what is changed, fixed and new increases trust in the relationship, confirms that feedback is listened to, and, along with updating the self-help experience, completes the loop.
Read a blog about this thinking applied to Drupal.