All development and changes to a product comes associated with risk. The risk of building the wrong thing, the risk of building features that does not speak to the users, the risk of introducing bugs. The list goes on and on!
Even worse is that the risk increases over time. The longer the work, the bigger the risks becomes - Unless you have good and effective routines for continuous feedback. Without feedback-loops you will continuously build your product on assumptions that leads to new assumptions. This leads to an ever-increasing risk of failure.
By working strategically with feedback-loops you can decrease the risk of failure dramatically while at the same time increase product quality and user-satisfaction. This is why feedback-loops has become such a crucial part of product development in today’s popular agile methodologies and principles such as Scrum, Kanban and Lean.
If you have an iterative process around receiving and reviewing valuable, insightful feedback you will directly decrease the risk by validating or invalidating your assumptions.
First, we need to understand which feedback-loops that comes to play during our work. A simple example could be the feedback you get when writing code in an editor. As soon as you stop typing, the editor will let you know if you misspelled a variable or function name. Another feedback-loop could also start from the point you have built a new version of your product until the time when users are able to try the new features out and give you opinions on how well its suites their needs.
Depending on what type of feedback you are searching for you can expect differences in its quality. Some feedback may be definite, other might be harder to analyze and understand. If we have good quality, we can expect a greater risk reduction than if the feedback is more uncertain. E.g. Have you successfully identified a representative segment of users to provide feedback? Are the tools you are using reliable and accurate? This is why you see an increased risk over time even though you get feedback in the illustrated chart. If the quality of the feedback is very good you don’t necessarily need to see that increase over time.
When you have a clear understanding of which feedback-loops that comes into play you can start to roughly list how long each feedback-loop cycle is. For example; misspelled variable names in code will give you feedback in a second. End-user feedback will have a longer feedback-loop cycle. Hopefully no less than every sprint. With feedback-loops and their cycle time clearly listed and visualized you will bring awareness of the loops and possibly their weaknesses.
Imagine what it would be like if you did not get immediate corrections of misspelled variable and function names! Most probably you would continue until compilation and by then it could possibly be a little bit harder and more cumbersome to understand and correct the issue which consumes valuable time. You will be surprised how often this holds true for other types of less trivial productive feedback-loops!
The longer the feedback-loop the bigger the risk. A good practice is to always strive to shorten the feedback-loop cycle to become as short as possible or as short as convenient for minimizing the risks associated with the change.
To spot weaknesses in an area of your product development it could be an eye-opener to also categorize your identified feedback-loops. Some of them might relate closer to engineering practices that will help you increase the quality of the product while other relates more to processes, progress, team building and well-being, insights in market demand etc.
Here are a few examples of some of the feedback loops that comes into play when developing a software product, and you can probably see room for improvement when looking at this chart.
What feedback-loops could you improve and shorten in your work? Would shorten those loops lead to a better product delivered by your organization? Hope you found this interesting and inspiring!