Newsletter
At a macro level, speed is named velocity. And sometimes going fast means going backwards.
As a kid, I started to take piano lessons. Back then, I was kind of competitive (some "friends" tell me I still am but I don't like to believe them) and I thought that being the best and learning fast meant finishing the music score as fast as possible. Can you be more wrong?
As a young adult, in my early months as a Product Manager, I went to see a developer: "Can we change this setting? It is a quick fix". LMAO. He agreed to make the change and a few days later, tens of thousands of users faced an important issue. We had to work even more to rollback the change and push a fix. I've since then banned quick fix from my own vocabulary.
I learnt the hard way that for a team or an individual at work, speed should always be comprehended at the macro level. It's called velocity. What does that mean for an Analytics team? What are things you think help you but actually impact negatively your velocity?
I will list 3 counterintuitive examples to help you grasp what velocity is and is not.
Supposedly, you're being asked a question about churn. The Product person asking is used to your dashboarding tool so you figure out a dashboard with a couple of metrics will be fast to build and readings will be easier. The user is happy you were "fast" to deliver.
A few weeks later, the dashboard breaks after you changed the metric definition and the user comes back with the famous "my dashboard is broken". You discover that the quick dashboard you made is used for high-impact decisions whereas the data inside was for an easy-to-make low-impact decision. Your user is now frustrated, his trust in data was impacted and you now have to fix a dashboard. Someone else is waiting for your answer.
We're in September and the Sales team starts to work on the Holiday season (Black Friday + Xmas). Back in January, you wrote a detailed slide deck with the campaigns and actions that worked best for the previous period, backed with data! Sales team was very thankful. They now ask you additional questions based on the ideas they have for next season.
Although your initial presentation was great, it was made by copy-pasting charts from your usual BI tool. You can't find back the sql queries you used... Not only, you cannot prove the results were properly computed but you have to start from scratch. While you might have been slightly quicker to deliver in January, you spent twice the time you should have if you have saved properly conclusions next to your queries.
It's been 2 years, you're the only person in the data "team". You are recognized as excellent in particular because you answered the various data requests pretty quickly. After a long period of discussions with your boss, you're finally allowed to recruit in your team!
This is the first week of your new teammate and she has to answer a conversion rate question after a big change in the product. She is excited. "Can you show me an example of something similar you did so I can pick up the work?" "Hhhhmmm... Actually, I think I did A and B but you should try B+C. It's easy." You'll finally have to both work on the same question and your brand new team's velocity is actually way slower to ramp up than you imagined.
Velocity is actually a trade-off. A trade-off between:
And actually, this is why we build analytics notebooks. We are convinced this is the best way to empower analytics team and help them answer questions while transparently building an history gathering both the context and the data. We consider "reuse" of prior work to be the strongest lever for your team's velocity.
It starts with a single notebook and ends up with a collection of them — soon organized in folders.
Interested to know more about Husprey? Drop your email below and someone from our team will reach out to you shortly.
