Three steps to reduce risk in product delivery

When did you last get feedback? Maybe you asked for it, or it was given to you unsolicited. Irrespective, it is pretty natural to think back to when your manager or colleague last shared an observation with you about yourself in response to this question. If feedback can be useful to you for your career and professional development, then why wouldn’t we want the same during product or service delivery?

Using feedback, and specifically the concept of feedback loops, you will gain a framework for designing, when, where and how quickly you get feedback to reduce risk for your product development. When referring to risks, we can categorise them into two groups:

• Technical Risk: Can I create it, and can I create it defect-free?
• Market Risk: Am I creating the right thing, and in the right time frame?

Feedback loops by their very nature imply that when feedback is obtained, it is fed back into the system and acted upon. Not using this invaluable data is a pure waste in lean thinking and plain dumb with respect to common sense. Feedback loops can be either ‘single loop learning’, where the goal stays the same and the data used to reach said goal, or ‘double loop learning’, where, based on the feedback, the goal might be adjusted.

As an example, your satnav uses single-loop feedback. The destination never changes but, based on traffic conditions and maybe the occasional wrong turn, it still keeps heading towards the same place. However, a human navigator can benefit from double-loop feedback. If the traffic becomes too bad, or a major road is closed, you can decide that the extra time now required might not justify your trip and turn around and go home.

Technical Risk

How do you know how well you are doing in your ability to deliver and deliver defect-free? It would be surprising if you didn’t already have some feedback loops to address your technical risk in place already. You might call them, ‘status reports’, ‘peer review’, ‘testing’, or ‘sign off’. The essence of these is to capture issues before you give the output to your customer. Collectively these and similar try to address, ‘can I create it?’, and ‘can I create it defect free?’.

From a customer experience point of view, being able to deliver a product with the right level of quality (mindful that this can vary), and knowing you are capable of delivering it are useful operational measures. You also want to try to limit the amount of failure demand that is being generated, leaving as much capacity available to deliver what you want, rather than having to go back and fix what you didn’t do well to start with. Failure demand can originate internally or externally. One is annoying the other could lose future business.

Just as it is important to validate your output, it is important to make sure your process, or your ability to deliver, is also addressed. Both the agile frameworks Scrum and Kanban introduce the concept of regularly reflecting and making improvements through activities like the retrospective and use of models. Non-IT organisations might use ‘lesson learned’ or ‘after action reviews’ to gain similar insights, albeit, not typically as often in the agile space, which we might describe as having feedback loops with longer cycles.

Market Risk

What part of your current process validates that what you are building is what the customer wants? The worst case is finding the thing you have lovingly created over the last few months does not sell. At the speed that business moves today, running your business with a ‘create it and they will come’ attitude will not get you very far.

What channels do you use to get feedback from your customers today? Are you proactive and ask or does it only come unsolicited through your support teams?

Assuming you do talk to your customers on a regular basis the questions you pose to your customers can either gain lots of insight or simply be a waste of time. Consider the following examples, ‘Do you like feature X that makes the widget faster?’, or, ‘What is it about using the widget you believe could be improved?’ The first is likely to generate a response which has little value, whereas the second will allow for a considerably wider and more informative response.

It’s not just the questions you ask either, it is the data you collect. The Standish Chaos Report regularly shows around 45% of features delivered in product development are not used. Knowing what is being used or not allows you to remove items of no value, and therefore save operational costs. It also allows you the insight to prioritise improvements for functionality that has the greatest use by your customers.  Companies you look up to such as Spotify, Netflix and Linkedin, all capture usage data and run experiments. They know very clearly which functionality doesn’t get used. This is yet another example of a feedback loop.

But it is not just a case of knowing this. Having introduced feedback loops to listen to customers and monitor how they interact with your products and services, you then have to do something with the data. Does the feedback help you reach your destination or does your destination need to change?

In the article about using Outcomes, we explored how these were a powerful tool over requirements. As part of your conversations with customers, you will create hypotheses about what you think you can solve to create demand for your product. Using the tools from the Lean Startup movement you can now try to validate these hypotheses before you have spent any time even creating the product.

Improving your feedback loops

1. Identify what loops you have today

Your first step is to review the loops currently in place throughout your product delivery pipeline. Having done so, categorise them in two ways:

• Risk Mitigation: What is the purpose of the feedback loop? Does it reduce technical or market risk?
• Type of learning: Is it validating single loop or corrective double loop learning?

If you struggle to categorise a loop, consider if this means you are not getting value because it’s the wrong thing to get feedback on or if it’s just not being used. Loops that don’t add value are a waste.

You may find it useful to create a similar diagram to the one featured above during this process.

2. Review what loops are missing

Having now identified what loops you already have and how you use them, the next step is to look for opportunities to gain feedback where you are not. If you’ve mapped your loops diagrammatically, you may find it obvious where you have gaps.

Use these questions to inspire your thinking:

• Is there potential to add nested loops to provide more levels of protection?
• Where have you found problems with quality before?
• What could your customers tell you earlier?
• Are you using experimental techniques to validate hypotheses?
• Are your loops imbalanced with too much emphasis on just the technical or market risk? (this might be appropriate or that you don’t have enough loops in place)

3. Make your loops shorter

Your mantra should be that you want fast feedback. Faster feedback allows you to make quicker decisions and change your direction accordingly. For existing and your proposed new loops, explore how could they be made shorter.

In some situations where your feedback can only occur after an event (e.g. Customer Satisfaction), consider how you can use leading to lagging metrics.

Next Steps

Being more consciously aware and improving use of feedback loops will increase your competitive advantage. They are a prime method of risk reduction on your projects as long as you address both the technical and market risks.

Work through the improvement techniques mentioned above with your team or organisation and implement your changes. Consider what metrics you might use to demonstrate how the improvements have worked. If you are using Kanban you will be already familiar with the use of models and data to monitor your flow.

Finally, consider how you can bake into your process, reviewing and improving in the future.

Want to know more?

Sign up to hear about the latest articles and videos so you never miss a thing, or get in contact to start a conversation.