Getting Value From Your Data Team

Throughout my working career I've been lucky in that I've seen how multinational corporations handle their big data and now help challenger brands to leverage the same tools and tricks. As such I've seen businesses go from having no data stack at all to having a large team and the challenges and pitfalls along the way, which is what this 30min talk was all about...

You Have Nothing

The big challenge with having nothing is that its a big leap...to nothing. Setting up a data stack is very expensive, it's very time consuming, you need the right people, you need the right technology in place etc. And initially you're spending a lot of time and focus to replicate what is probably already there in Excel reports, in manual reporting or in reporting inside of your tools. So it's a big upfront cost with little ROI on the face of it, other than saving this manual time compiling reports. But that means that for a lot of companies the expense in doing it this, seems like it's not really worth it and they delay it until much further on.

One of the interesting things though we've noticed at 173tech is that, a lot of the startups that we have helped have second-time founders. These are people who have typically built up and sold their business and now, armed with that experience, understand the power of data and how it can be leveraged to gain a competitive edge.?The second is that while you might be familiar with the likes of Numan, Treatwell, MUBI, and Plend today, they were not big names when we first worked with them! By utilising data from the beginning, they were able to make informed decisions, optimise their operations, and scale effectively. Their growth stories exemplify the transformative power of data.

For me, this is a big indication of how powerful data can be and the competitive advantage it gives you. Data-driven decision-making is not just a buzzword; it’s a proven strategy that can propel startups to success.

So mistakes at this stage?

Focusing on unknown needs, things that are 'nice to have' or 'nice to know' rather than focusing on the key reporting you will use everyday. These requirements add a lot of cost and complexity upfront that is not needed necessarily.

Another would be businesses make is that they try to hire one amazing person to handle their entire pipeline. The problem with this is that building a data stack requires a team with diverse skills and knowledge. What I often see happening is that businesses will try and hire a unicorn, someone with a bit of all-round experience. They get the stack up and running, but often when data volumes start to scale, what they’ve built has not been optimised for this and so the cost increases significantly and the stack often has to be completely redesigned.

Last but not least, not thinking about tomorrow - while the most difficult thing in designing data infrastructure is scalability. It's really difficult for anybody to understand what tomorrow looks like, but we can all know one thing for certain which is that data volumes are going to grow exponentially. Your data needs as an organisation will definitely be more than they are today and so setting tools up in the right way is really really important.

Your First Data Project

How do you make sure that your first data projects are a big success, above and beyond setting up your core reporting? Focus on one business area to start with. It sounds like really obvious advice, but what happens is you go to your C-suite and you say "hey we want to implement data, where do you need your data?" and what you get is a really long laundry list of metrics and each of these metrics relies on different data sources, all of those data sources need to be extracted and modelled. now your pipeline is 474 months long.

My controversial opinion on this is that small data teams like this scenario, because it gives them a nice long pipeline of things to work on for the next couple of years and they know that they're going to be nice and busy, that their job is nice and secure and on some level they know that business priorities change, technology changes, data sources of course always change and so the business never really becomes data mature. You are unfocused and you just working down a list and so you never quite get to a place where everyone is using data in the way that makes a difference.

So where do I like to start when thinking about my first data projects? The first thing is customer Journey which affects a lot of different departments, it's an area of business that is closely tied into making money for your business ( From acquisition through to retention and then upselling um and lifetime value of customers) so if I can understand at a top level basis those different parts of the journey, what data sources are people looking at, what decision my team will make throughout that journey - this will start mapping out which data sources are the most important.

As for a specific area for a first project, 173tech have had a lot of good results in optimising online advertising. So if your company spending any kind of money on Google ads meta ads you'll know that the cost is going up and up in front of your eyes and then this is a project where you can create a lot of savings by optimising those ads with your first party data. Model your LTV of customers, send that back to your advertisers and in this way you are not relying on the same algorithm as all of your competitions, where your only differentiators will be landing page quality and budget.

Small Data Team

Over time you get a small data team. Anybody who has a small team but a lot of stakeholders naturally becomes a blocker in the process because people are coming to you with ad hoc requests, they want to know what the data is behind the decision before they make it etc, and actually what I see happening quite a lot is that the data team begins to slow down the process. Data doesn't help you to make a quicker process, actually it becomes a blocker. And a controversial opinion is that a lot of people like to be in this position because it means that in their mind they think they're invaluable to the process of decision making, it means they think that their job is integral to the running of the business, and so they quite like being in a position where everything has to go through them they're the only ones that understand data. But for the long-term influence of data in your business this is really bad because then you're not democratising data, people don't have the power internally, and so you can never really grow data adoption other than hoping that you'll get more data people, but data people are expensive! So this isn't a viable option. What you need to do is put data in the hands of your stakeholders and that means dashboarding all of your repeated requests as much as possible. So certainly dashboards are a great tool on a daily basis for anything that needs to be checked quite often, or any requests that you get semi-frequently. As a small data team anything that you get asked for repeatedly you should try and make a dashboard for that. part of your job at this stage is building and maintaining dashboards but half of your time should be spent deep diving into really business critical things so that you're providing value for the business.

The second thing is looking at department maturity, so I spoke before about the problem is if you don't have a plan how you're going to mature the business in terms of different data departments then you just end up where nobody's really using it to a good degree. Some departments have it, some departments don't, it's not really a good state of affairs and there will be people who aren't quite happy with their data, who will blame the data team or they blame the data tools for that and it's not really accurate. It's because data have bene rolled out in an unstructured way.

It's better to have uh every department at a certain stage of maturity with data and then when everybody is at that stage you then go to the next stage. So it might be for example that stage one is that every department has a dashboard that they use for their daily tasks for their daily reporting, and then the next stage you can think about predictive analytics, and so on and so forth. it's better to have each department be at a similar level of data and data maturity than it is to have some departments really be advanced and some not because if you get stakeholders excited about data ,they're going to be disappointed that they two or three months away from being dealt with, and you won't have the impact in terms of your internal support.

A small data team really needs to create best practices in terms of documentation, part of that is for your stakeholders and part of this is for the future data team. In terms of stakeholders, help them understand why something takes a long time. If you don't know data and you say "oh Oliver I'd really like to know who are my high LTV customers in this segment" and that model doesn't exist, it's really difficult to then go to that stakeholder and say "yeah sure that's going to take me a month to do" because the stakeholder doesn't have any context on why is it taking so long, and what are the considerations on that. They just want an answer today. And when they can't get it, it creates a friction there.

You should also install best practice in your code, making sure that somebody new can come into your code and understand it because you would assume that your data team is going to grow new people are going to be in there, you're not going to be around forever and so if you've got those processes in place as a small data team it will help you scale. If you don't, it can end up costing your company an absolute fortune as someone has to unpick this.

Large Data Team

Large data teams have a different set of problems from our small data teams and a lot of the time it's a consequence of building and things getting out of control. Ao here having an approval process becomes really important because what happens in a lot of cases is that people will build and because they don't have processes in place they end up with a thousand dashboards ,they end up with loads of code that is maybe duplicated and their data becomes messier and messier over time because people come in they don't want to build on what is already there and working, they build new tables they build new infrastructure and the whole thing becomes a mess where you can't quite get away from the old infrastructure but you're not quite ready to use 100% of the new processes and the new structure.

It's such a simple thing to say is just have an approval process, this is something that IT teams have done really well for a long period of time, maybe you need a ticketing system before you start work on something, maybe you need some sort of business case before you build anything. Because everything you build has an ongoing time and cost commitment in needing to be maintained. It's an unsexy task, but making sure that everything runs, that everything works perfectly is key because data trust is fragile. But another controversial opinion here, keeping things running is not exciting to people, and at a certain stage of maturity in business they will have 95% of all the things that they need to run the business, they've gone through that stage where they built out all of their infrastructure for different departments, everybody's got the core analytics that they need, but where do you go from there? It's not really exciting if you're head of a large data team to focus on that keeping things running. So what you see at larger companies is that they start saying "I don't have all the data I need to really make a difference: they start going out and finding third party data that they can work on, they start working on LLMs and large data models and they kind of loose focus on is that useful for the business, what's the business use case around that -because it's an exciting and sexy thing for them to work on. But often what they do is they actually introduce a load of complexity to the data stack, they stop getting value from their team for the business, and so it becomes unfocused and messy in the long term.

One area that is new and exciting and needs to be paid attention is simply keeping in touch with best practices. The data field is probably one of the fastest moving fields, it's not fast in terms of the principles changing, it's not fast in terms of the core ideas changing ,but it's fast in terms of technologies and new requirements coming in place. There's always something new to learn and maybe as a large data team you really need to ring fence 10% or 20% of your time to learning new things to making sure that everybody knows what best practice is and is evaluating whether that's the case for your business.

Large data teams are an expensive commodity, and not except from ensuring that they are working on things which create value for their organisation, working closely with subject matter experts or stakeholders to ensure that data initiatives aren't just following the latest trends (cough, AI) but adding to the bottom line.

Thought Of The Week: No matter the size of your data department, it's always crucial to tie back data initiates and cost to business impact. Outsource what's out of your wheelhouse. Spend time in stalling best practices and documentation. Never stop learning.