Ministry of Technology
Show Menu

Using Retrospective feedback to inform product decisions

Using Retrospective feedback to inform product decisions

I was invited to give a presentation at South West Product last week about using data to help drive product decisions. With my current investigation into using agile processes in an agency environment I started thinking about how you could use traditional agile process elements to help drive the product in ways I hadn't previously considered. The following article is a write-up of the talk that I gave at the event.

If you don't have exposure to an agile environment or want to know more about what a retrospective is, refer to my earlier article from my Optimising Project Delivery series.

What does the retrospective provide as standard?

The Retrospective is generally viewed as being for the delivery team rather than for product owners or product managers. In many organisations where adoption of agile methodologies and tools is fairly immature then product or client facing people will be excluded from the retrospective entirely. This may sound harsh but it has an important value in that a good retrospective must be an open and free non-judgemental environment. Only a mature organisation without any history or culture of blame can openly engage everyone in a retrospective. As people become more comfortable about openness and honesty about themselves and the working practices around them integration of product people becomes beneficial.

Regardless of the maturity of the organisation it is worthwhile for product focussed people to request an edited version of the retrospective report from the facilitator / Scrum master, who will ensure the report is anonymised to provide useful information to the business, to highlight any issues that relate to the product. This benefits the product growth as follows...

  • Creative teams in retrospectives are users
  • Creatives, Testers and Developers, particularly early in development, use key and new elements of the system repetitively day in day out.
  • Repetitive use identifies strain points in the product.
  • New product features can emerge from actions defined in the retrospective.

The Product retrospective

You can take a desire for product benefit further than the information that you may get from a traditional retrospective which, for the most part, tends to focus on interactions and process improvement as a way of improving quality and efficiency. You can do this by holding a product retrospective. The nature of the content of this should be similar to a team retrospective but with a product focus so the key questions would become...

  • What is the product's best feature?
  • What is the product's worst feature?
  • What is the most obviously missing feature?

You could add various other questions, perhaps one per meeting, to cover key new stories that you would like to develop. These could be anything but some examples could be...

  • What would the product need for you to start using it over a competitor?
  • Where is the product too complicated?

I was asked how regularly I would hold one of these and I don't really have an answer. It depends how much useful information you can glean as to the value and regularity of the retrospective. Every 2 or 3 iterations seems like a good starting point and then you can increase or decrease regularity according to the volume and value of information obtained.