Is there any process you do to retrospect the decision making? Let's say you estimate a feature will have high impact, and it doesn't. I've 3 ways it plays out:
1. Most common - trying to improve it with iterative adjustments
2. Leaving it as it is and moving on to the next one
3. Trying to understand why we chose to do it, and how to avoid such a choice again
I've yet to see a good implementation of 3, and wonder if you have ideas on that
We have a few different processes for doing retrospectives, but nothing super formal. A lot of the time it is just continuing to improve it by following the path of talking to users, adding features they want, fixing issues, etc. Engineers continue to be responsible for the support of products and features after they ship.
Sometimes, we do work on features and they aren't working or going as fast as we thought and goals pivot. This change is decided on by small teams and talk about in sprint planning. Teams do retros every sprint (you can see them here: https://github.com/PostHog/posthog/issues/19116). Teams also reflect on what goes well/not well at offsites and decide on what need to change.
Sometimes we touch on #3, but it depends on the team, person, and situations so we don't have anything formal to make it happen.
This article made me decide try it out instead of MixPanel for my new app :)
Keep up the great writing and work!
Appreciate it Anton! Let me know if you have any questions or feedback when you get started.
Actually I have a question about the article :)
Is there any process you do to retrospect the decision making? Let's say you estimate a feature will have high impact, and it doesn't. I've 3 ways it plays out:
1. Most common - trying to improve it with iterative adjustments
2. Leaving it as it is and moving on to the next one
3. Trying to understand why we chose to do it, and how to avoid such a choice again
I've yet to see a good implementation of 3, and wonder if you have ideas on that
We have a few different processes for doing retrospectives, but nothing super formal. A lot of the time it is just continuing to improve it by following the path of talking to users, adding features they want, fixing issues, etc. Engineers continue to be responsible for the support of products and features after they ship.
Sometimes, we do work on features and they aren't working or going as fast as we thought and goals pivot. This change is decided on by small teams and talk about in sprint planning. Teams do retros every sprint (you can see them here: https://github.com/PostHog/posthog/issues/19116). Teams also reflect on what goes well/not well at offsites and decide on what need to change.
Sometimes we touch on #3, but it depends on the team, person, and situations so we don't have anything formal to make it happen.