Thursday 21 March 2013

Eight steps to building analytics that actually get used

Inspired by a couple of football related posts around the topic of "what is analytics?" I've penned a few thoughts on a slightly different subject. Once you've decided what analytics is, how do you build something that will actually get used? It's often easier said than done... Many big ideas ultimately fail to deliver and I'm convinced there are just as many brilliant insights out there, which nobody's paying any attention to.

I'm writing mostly from my experience in the marketing analytics world, but these would guide my approach pretty much anywhere. How do you build a piece of analytical work that ends up delivering something valuable, rather than sitting on a hard drive, gathering virtual dust?



Clearly identify your questions first


This is a useful process in itself. What, specifically, do you want to know?

Now make it even more specific; break your question into pieces. And then possibly more pieces.

What would the world look like if the answer to this individual piece was "Yes"?

Now you can start doing analysis.


Walk before you run

If you try to go from nowhere, to the answer to life the universe and everything in one step then you're almost certain to fail. If only because right now, what you think the ultimate answer should look like is very likely to be wrong and you need to let some groundwork shape your next steps.

Before you collect any new data, what could a good analyst achieve with the data that you have? By the way, if you ask and they say "nothing" then they're not a very good analyst. A good analyst isn't afraid to speculate based on limited data, but they should also be honest and tell you that's what they're doing.


Have an opinion

You've just done a month's statistical modelling work and you can't present it back as an academic might, by saying "the effect of X is probably Y and the effect of Y is probably Z." We analysts like to hedge our bets, but if you want your stuff to get used, you can't do that. You're going to have to put your neck on the line.

You have to have an opinion. As a result of your work, what should be done? State it and state why you believe it, then allow people to disagree based on the evidence.


You need management backup

You know why Moneyball worked? Apart from all the clever numbers, Billy Beane, the A's General Manager believed in analytics, put it front and centre of decision making and didn't seem to mind who he upset along the way.

An angry analyst stamping their foot and demanding to be listened to, won't cut it. If you're trying to change an organisation, you need very senior backup and they need to trust their analysts.

Be careful what you wish for. Getting this bit right means that as an analyst you're going to feel some real pressure.


That management backup needs to have an open mind

Building on the previous point, it's no good having an evangelist forcing analytics into a company's decision making, if they're just using numbers as a battering ram, to push the strategy that they had anyway. We're back to trust again, to be earned by analysts and then respected by senior management.


Plain English Answers

As Albert Einstein said, "If you can't explain it to a six year old, you don't understand it yourself."

Dump the jargon and the statistics and find a plain English way to explain your results. Stories are good.


Never talk to IT until you've got a working prototype

I can't stress this enough. The only way to brief an IT development team to build you an analytics product, is to say, "See this? It works. Please turn it into a robust product for me."

Any IT people reading, the comment section is below - feel free to let me have both barrels, but this is true for virtually every IT team I've ever come across. IT and analytics are often confused, because they share some skills, but at the beginning, you need to be sure you're talking to analysts, not programmers.


Analysis is a process

Treating pieces of analysis as individual questions that are paid for individually, answered and then put to rest is very rarely the best way to get results. Analyses answer some questions and raise some more. They guide decisions, but could always be built better the second time around. Sometimes, despite everyone's best efforts, a line of enquiry doesn't achieve all that much.

Treat starting a piece of analysis as starting a process of discovery, rather than paying for the answer to a specific question right now, and over a period of time you'll reap the benefits.


Have I missed anything? What's the key reason why a piece of analysis you've done is still in use, or what barrier killed a piece of work that should have been brilliant? I'd love to hear about it in the comments.

No comments: