There is the highly quotable phrase: “Own your process, or your process will own you!”, well at least highly quoted by me… I have used it as a segue into pragmatic and value based discussions to avoid the worst consequences of dogma driven transformation. The premise being that the process should be adopted, not imposed; chosen by the people for the people (insert other inspiring taglines accompanied by images of eagles soaring over glaciers here). Jokes aside, there are some important principles at stake here, mostly around the benefits of empowerment and the importance of context to complex systems.
I believe that the underlying point of empowerment and context should be applied to other areas of our product delivery. If we want to consider our approach to be Agile, to enable the organisation to achieve business agility, then we have to focus on feedback. Feedback is at the heart of all things Agile.
I would advocate that we, “Own your feedback, or your feedback will own you.”
What do I mean by this? Well that if a product delivery system is proactive in its approach to feedback then it can use this data stream in an incredibly powerful manner. It will learn through iterative delivery to build a better product or service than could ever be initially conceived. Delivery that takes the strategic direction of the company and leverages real world feedback to adapt that vision to maximise value return. However, if we are reactive rather than proactive, then we either continue blindly on, or are led by the nose by a vocal minority to a destination, potentially far, from our original purpose.
To elaborate step by step: below is product delivery in a waterfall world. Assuming implementation into a simple environment where the consequence of our delivery is absolutely known from the outset, where the output leads unequivocally to outcome.
Here there is no feedback, there is no need for feedback, we know everything already. Delivery like this, is one of: rare, lucky or foolish, depending on your industry. Large scale technology delivery has been proven repeatedly to sit in the complex space where output ≠ outcome.
To be able to manage delivery in a complex adaptive system we have introduced iterative feedback led techniques, within technology we invented the term Agile although the concept of empirical adaptive processes was born long before. W. Edwards Deming (1900 – 1993 to give you an idea of when this dates from) advocated the use of what he referred to as the Shewhart cycle from Walter Shewhart (1891 – 1967, so even earlier) for which we now use the term “The PDCA cycle”, or Plan Do Check Act.
If you apply the PDCA approach to product delivery then you get something a little like this, where each iteration delivers output and you repeatedly revise that output based on contextual feedback until you confirm you have achieve a desired outcome.
A slight tangent but it is worth noting that delivery continues until “A” desired outcome is achieved, rather than “THE” desired outcome, as good product delivery is cognisant that we drive to a direction rather than a destination.
Now consider the types of feedback that are available: I choose to split them into two groups:
- Feedback we solicit
- Feedback directed to us.
Feedback we solicit
When the product delivery was initiated, it would have been to address a problem, a need, which needs to be able to be continually understood / measured so as to ensure that the changes are alleviating the problem / meeting the need. So this understanding or measure is a type of feedback that we proactively solicit. The feedback will ideally be a lot more sophisticated and built into the product, giving a lot of information about user engagement to the product. Product owners are typically all over the following information:
- When is our product used?
- How long is the product used for?
- Are some workflows used more/less than expected?
- Are there points with significant dropout?
- What are the workflow completion rates (conversion for a payment)?
- Proactive discussions with representative users on their opinions
Then on top of this, close user research would be maintained to observe first-hand the use of the product.
All of these pieces of information can be aggregated to paint a rich picture of the outcome of the delivery – as distinct to the output.
Feedback directed to us
This is feedback from users that are so affected by the introduction of the latest output that they expend the effort to inform the organisation about how they feel. They might be going out of their way, interrupting their day job, to let you know how awesome the delivery is, or, more realistically, that the latest changes stink, how much they stink and why they stink. They may be cordial enough to limit their frustrations though agreed formal channels – or they may just choose to vent their fury on social media. Critically however, the feedback is only from a proportion of the user base – a self-selecting proportion. It is fair to say that if some people contact the delivery organisation to say they are unhappy, then there are others that haven’t reached some critical “annoyed enough to complain” threshold; but it doesn’t mean that some don’t actually quite like it – and that “some” could be the majority.
Both these types of feedback are important, the former gives a full picture, the latter shows areas that are likely to be disproportionately impacting the users. These two feeds need to be balanced against each other. If 90% of the users are getting on really well, deriving value, and 10% have issues, then the delivery should focus on that 10% to either adapt a custom offering or provide training and support. whilst progressing on with the 90%. Consider what would be a likely scenario if only one of these streams were available?
Realistically one of these streams is always available, if users are unhappy they will make themselves heard, eventually, and the longer you leave it to listen to that feedback stream the more serious the consequences, until their final piece of feedback: “Goodbye”.
A product delivery not investing in their own proactive feedback is much more common. This is represented below and can easily trigger the reactive feedback stream to grow in importance – the delivery starts to believe it has a solid feedback approach in place because of the strength of the user comments.
In this scenario, response to user comments becomes a delivery measure, addressing vocal problems becomes more high profile than delivery that doesn’t cause any. The initial strategic direction starts to be clouded by the “angry mob” to whom there is no data driven counter, and slowly but surely, the delivery descends into firefighting. It is like navigating through a hay barn with only a burning brand for light.
There are many reasons why the product delivery could end up here. It could be due to a naïve belief that they have the right solution up front – a refusal to accept the complexity of their environment. It could be due to a lack of skills or lack of capacity in product ownership, or more troubling or a lack of genuine ownership. I believe that the cost of not having a solid proactive feedback stream exceeds any involved in addressing skill or capacity issues. A lack of acceptance on complexity or a lack of ownership are more fundamental challenges to address however.
When initiating or looking to improve product delivery, shortly after owning your process, make sure you have established how to own your feedback, ideally before having to call the metaphorical fire brigade.
Comments are welcomed – even criticism. It is only through feedback that we learn.
Tweet me at @philagiledesign