Do you do postmortems on your indie hacking projects?
I was listening to the IH Podcast with Hiten Shah and he mentioned how postmortems have proven to be invaluable for him and his team.
I found How to do effective postmortems podcast from Hiten's The Startup Chat podcast, but I wondered whether anyone else here could either share their experiences, practices or resources on the topic. 🙏
I do them on everything... Personal projects, team projects, vacations, new hobbies, etc. My girlfriend and I do them on the previous X months of our relationship every now and then, just to dig out and make explicit any behaviors which are stressing us both out. I can't really imagine doing anything you care about doing without taking ten minutes afterwards to have an honest think through what worked and didn't and how to do it better.
What's your process? Is there any structure to it, or is it just a focused brain dump?
With cards/stickies on the table, everyone takes 3 minutes to write stickies for everything they think went well, then 3 minutes to write what what went badly (under any definition of "bad" -- some folks find it easier if framed blamelessly as "things which caused stress/delays/costs").
As a group, cluster sort the cards, and then agree on which clusters are worth discussion. Divide the remaining time (minus 5 minutes) to get an amount of discussion time per cluster, and dig in.
Final 5 minutes is to agree on concrete actions/changes moving forward ("keep doing this", "stop doing this", "start doing this", "do X whenever Y happens", etc). E.g. after a recent project went hugely out of scope, we decided that before beginning any new project (book, software, event, whatever), we'd first write and talk through a one-pager of expected duration/costs/upside, and then start doing crisis control on the project if it's approaching the end of that timeline. As a positive example, the (remote) team had been forced into doing weekly calls (as opposed to our normal, fully async process) and ended up really enjoying the checkins, so decided to keep doing them even after the crisis was finished.
(It's tempting to "fix" everything by adding more process, but that obviously gets out of hand quickly, so it's equally valuable to notice and cull low-value processes and bureaucracy.)
*Edit: It's basically just a root cause analysis on both the good & bad of a project. So you can also just use whatever root cause approach you prefer (so long as you investigate the wins in addition to the setbacks)