January 23, 2023

Conduct retrospectives or debriefs even when things go right

When Ross Brawn was at Brawn GP, he visited a Accident and Emergency (A&E) mock training at a hospital in the UK. He noticed tha the staff conducted debriefs only when someone died in the trainings. They didn't have time to conduct debriefs after every training regardless of the results.

According to Ross, when you discuss to see what worked well, what didn't and sort out the problems only after someone has died, then it's too late. At that time, everyone would be emotionally charged because everyone would be worried about the consequences.

He added that conducting debriefs helps improve the process when people have time, i.e. before any crisis.

The same lesson can be applied to Product Design and Product Management. After every project, there should be a Retrospective, similar to the debriefs after every F1 race. In such retrospectives, the teams should discuss things like

  • What worked well?
  • What didn't work well?
  • What problems occurred?
  • What needs to be done to resolve the issues?

Retrospectives also help identify recurring problems that can be taken up on priority. These can be solved with a process of frameworks that would improve the process for the next project. Such retrospectives ensure that the Product Design/Management processes continue to improve incrementally.

For an additional example, I write 'Contact Reports' after each job interview. This has helped me analyse how I did during the interviews, improve my answers over time with self-correction. This also helps me keep a record of the interview process, in order to analyse and compare in case of multiple offers.


  • Total Competition (Ross Brawn, Adam Parr)