The big three: build-measure-learn

In his book from 2011, Eric Ries detailed the now famous Lean Startup principles and the underlying "Build-Measure-Learn" methodology. A virtuous cycle that should help teams improve over time. The faster you iterate through this circle, the more you learn and the easier it will be to achieve your goals.

The Measuring part is about Analytics. What are the unbiased data that will validate or invalidate our initial assumptions from the building phase? Add brain juice to learn something out of it and start again.
This methodology can actually be applied to your own Analytics team: you build a data stack(/platform/any keyword) whose impact on the company should be measured so you can learn for your next project.

But like the shoemaker's children who sometimes go barefoot, Analytics teams might find it pretty complex to define their own KPIs. While sharing tips to improve the Build-Measure-Learn cycle, I'll try to share some KPIs that can be used for each phase.

Document as you build

What matters the most to Business Users is very often how fast you can answer a question with the right recommendation. They don't care about your documentation process. It can then often be seen as time consuming.

However, in order to be able to later learn from a specific piece of work / analysis, you need to write things down as you build:

• Detail the expectations from your stakeholders, so that you always have the business context in sight
• Keep track of the steps you go through, the intermediate conclusions you draw, the choices you make. The destination is critical right now, but the journey is what matters most in the future!
• Clearly state your conclusions and recommendations

Shared learning is more efficient than solo learning

Once you finish building your actual piece of work/analysis then you share it with stakeholders. It is expected, it is your deliverable after all.

It is now the time for the postmortem. What was the actual effort? What was the actual impact on your teammates, on your customers, on revenue ...? Postmortems are not limited to failed projects. They should happen no matter the output. They don't always need to be long, it can only be a couple of lines about what you learned, what you should have done differently, what you should try first next time.
And make them available publicly, ideally alongside the work done when it's something like an analysis so people can comment and react to add what THEY learned. The future you or the newcomer will benefit from it.
Your feedback loop and your learning should help you improve at picking the topics with the biggest impact.

Our conviction at Husprey is strong on the feedback loop you need to set up to collectively improve over time. Documenting is also key and I might be biased here but notebooks offer a great way to drastically reduce the time spent to documenting. Documentation becomes an actual part of your process for many analytical tasks. Previous work and associated learnings seamlessly becomes searchable.

Our notebooks will make you gain time, see for yourself!