Week 1: Our Business Data Could Do With A Good Trevoring!
Today is my first day as Founder of Trevor.
“To Trevor” (verb): meaning to extract and derive knowledge and insights from a given dataset.
- “Our business data could do with a good Trevoring!”
- “I’m going to Trevor our database this morning, and will get back to you with an answer asap”.
Again and again I have seen the same problem presenting itself in teams and companies everywhere that I work. Members of the team are asking themselves questions, about the business, that if they knew the answer to would instantly make them more effective in their job.
These are questions like:
- the CEO asking “what’s our best selling product today?”;
- Customer Support asking “what’s the current status of this customer’s account?”;
- and Marketing asking “at what point in the user journey are the majority of users dropping off?”.
Now, there are plenty of great platforms out there that enable these teams to solve these particular problems, e.g.:
- get your Software Development team to set up a Geckoboard dashboard, so the CEO always knows the best selling product of the day;
- get the Customer Support team set up with a shiny Salesforce CRM, giving them access to customer account data;
- and hook up every action in the website to trigger events in Mixpanel, so marketing can build their funnels.
These are excellent tools; fit for purpose, and I strongly recommend them (or their competitors) for your business.
So, now your software development (or operations) team have spent a couple of weeks (or months) setting these up for you. Hallelujah! You can now answer those original questions, instantly, any day of the week. You jump for joy — high five — as you should, as you now have a much deeper understanding of your business than you did before.
However, now that you’re empowered with this additional knowledge, you do what any top employee/team member/founder does (and should): you get curious.
You start asking follow-up questions:
- why is the blue one better selling than the red one? What else are those people buying?
- when did that user log in? What were the series of actions they performed to get them in this state?
- what’s the difference in the demographics between those users that go on to become power users vs those that don’t?
And it is at this point that one of two things start to happen.
a) team members begin to approach the software development team, more and more regularly, asking for ad-hoc queries/reports/investigations to be performed in order to satisfy their constantly-growing curiosity; or
b) the software development team pushes back (because their workload is already overwhelming), and team members inevitably begin to suppress more and more of their questions, because getting answers is just a little bit too much effort (or takes too long).
The worst case here is b), as suddenly your motivated, curious team are not as effective as they could be. They’re missing opportunities to understand the business and your customers better; to identify efficiencies; and to wow the end-users with personalised support.
In the best case, you’ve got a), which is a data-driven, empowered workforce; but you still have the bottleneck of all questions having to go through the software development team.
At RefME (where I was CTO) we had our data scientist dedicating a minimum of 50% of his time to handling ad-hoc queries for the marketing team; while a 2-month engineering project was dedicated to an ETL pipeline (transform and clean-up of the data) for empowering the product team to compare user behaviours across different platforms.
These projects were vitally important, and empowered the marketing and product teams to make data-driven decisions on how to improve our conversion funnels. But the fact that these questions/investigations required constant software development resource to answer them, has always bothered me.
Not because I didn’t think it was a worthwhile use of resource. Quite to the contrary: I think it’s crucially important to actively encourage every member of your team to be asking questions.
No, it bothered me because I’m a technologist, a programmer and an engineer. I solve problems; I automate things; and I optimise processes. It’s what I do; it’s in my blood; and it’s what I do best. And it has always bothered me that these ad-hoc queries had to be answered in such a manual way, by talented software developers, who are experts at automating things.
The problem, basically, was why couldn’t we empower non-technical staff in the team to be able to answer their own questions?
Sure, we could have trained a few of the product and marketing team in SQL/Python/R (and regularly kept them up-to-date with how our data schemas were evolving), but unfortunately that would only defer the problem. The goal is that every member of the team has the power to answer their own questions — and to do so quickly and confidently.
This is the goal of Trevor.
Trevor is a playground for data exploration. A place where each member of your team can freely ask questions of your business data; collaborate on the answers; and dig deeper to learn more.