Where do the analytics fit.
The question was around when you should allocate time to sorting out the analytics around a feature.
You’ve decided to build a certain feature as a team, it’s almost finished and then someone goes “Oh, what about the analytics?”
This usually happens with teams that are not used to working with data. They’ve heard data can do wonderful things, so they want to be data-led, and then find themselves in the situation above pretty much every time a feature is ready to ship.
Data isn’t something that you tack on at the end of a sprint or figure out after the feature has been shipped. You should be using your data much earlier in the development process, way before you begin writing any code.
Your analytics should be the basis on which you decide to build the feature in the first place. We’re building X because there is a massive drop-off at this point in this funnel. Or we’re making this change because we think this is one of the reasons this metric isn’t performing as well as it could.
The idea is that you have a set of measurable outcomes that you are working towards and all product work and feature released are how you are moving those metrics.
The success of the feature is therefore based on its impact on a given metric.
When it comes to the end of a sprint and you have to “figure out” analytics, it’s really easy because you know exactly how the success of the feature is going to be measured. It’s why you’re building the feature in the first place.
Now you just have to work out what active usage of the feature means. Hopefully, this isn’t something you work out at the very end once everything is said and done. Ideally, measuring usage is part of the design process and you’re designing the feature in a way that there is a measurable contrast between casual exploration and active usage.
The point is that the work around analytics is not something that happens after the fact, but informs the decisions and design of a feature.