Jumpstarting the data engine for startups

^{Written by the Samaipata Editorial Team}

This is the fifth episode of "No-Filter Talks," an interview-based video series that invites our Operating Partners to speak openly about their experiences, offering valuable lessons and sometimes hard-to-swallow truths for our founders' success.

In the fast-paced world of startups, navigating the complexities of data management is critical, yet often misunderstood. Emmanuel Martin-Chave, VP of Data at BlaBlaCar and Operating Partner at Samaipata, brings a wealth of experience in scaling data strategies for high-growth companies. With a background that includes leading data teams at BlaBlaCar and contributing to the development of data-driven cultures across various organisations, Emmanuel is well-versed in the challenges and opportunities that data presents to startups.

In this episode, Emmanuel shares his insights on when and how startups should prioritise building a data team, the importance of aligning data initiatives with business objectives, and practical strategies for keeping data management simple yet effective. For any founder or startup professional grappling with data-related decisions, Emmanuel's expertise offers a roadmap to making data a powerful tool for growth.

‍

‍

Samaipata: Does an early-stage startup need a data department?

Emmanuel: An early stage startup, I think, doesn't need,  or I'd rather say it cannot afford a data team from the start.  If you have money, spend it on engineering, product sales,  because at the end of the day, you're finding your product market fit  and that at the beginning, you anyway don't have a lot of data to analyze.  Now, I think what's a great question is like,  when do you need to start looking for a data team?  When do you need to start making that a priority?  Who will you give that priority to?  Is this going to be engineering, finance, another department?  And you need to have that in mind because it takes time, it's expensive.  So if you don't know that, you risk building it too late.  That's when troubles start.  Another thing is people should be relaxed about not having a data team at first  because you can do tons of things with a couple of spreadsheets,  just like common sense,  and just asking the engineering team to export some data for you  and that you can go to great things with that.  

‍

Samaipata: What strategies do you use to build this data driven culture?

Emmanuel: The two things that come to mind,  one is,  the engineering department who eventually is going to produce the data  through the product, directly through the databases and so on,  they need to be aware this is coming  so that they can anticipate a bit and make decisions.  For instance, are we going to be event-driven?  Are we going to be database-driven?  What's our architecture?  And start thinking ahead,  okay, how will we build the platform, the data platform on top of that?  The second part is more in the business,  the operations side.  People need to start thinking about,  okay, what kind of data would help me solve that problem?  And that shifts the mindset.  Very often, give me everything you have and I'll use what comes up.  I don't think it's the right mindset.  You should start with a more minimalist approach of,  okay, here is my problem.  Here are the two, three KPIs I'll be looking at.  And that creates a better culture because you avoid asking  15,000 questions.  Okay.  You don't want to ask a question to your data team,  which will always be swamped, never give you answers. 

‍

Samaipata: How do you measure the success or effectiveness of your data initiatives?

Emmanuel: It starts with who's asking the question and what problem they're trying to solve.  One thing I've found interesting is that it's very often super hard to compute  the ROI of a data team as it is for any support function.  What's the ROI of your finance department?  You mostly see them as a cost.  And that's it.  So what I recommend doing is more, okay, what problem am I trying to solve with data?  Is this going to be, I know I'll make a better product decision because I can roll out the right feature.  I know I can contact the good leads in my pipeline so that my sales will spend less time on the ones that won't convert.  I'm optimising operations, so I'm saving time, money, et cetera.  But focus on that problem.  Maybe you'll find a way  to put a Euro, dollar, like a monetary amount on it.  If you can focus on that specific thing, you'll find a metric to track it.  It could be the time people are spending.  It could be how many wrong decisions you made.  It could be how fast are you making the, are you evolving your product?  And that is usually fairly simple to measure.  The area where it's easiest to measure the efficiency of data projects is usually when you automate the data.  So you can do that.  And then you can do that.  And then you can do that.  And then you can do that.  And then you can do that.  And then you can do that.  So for instance, you use AI to automate moderation or you build a chat bot so you receive less tickets.  Most of the things that data teams do, it's fairly hard to put a good ROI on it.  So my recommendation would be don't go too much on the details.  Focus on what impact you have in your operations and stop there.  

‍

Samaipata: What's your approach to data literacy within the organisation and how do you ensure everyone understands the database and data systems they're working with?

Emmanuel: My approach is people need to understand the high level blocks in the system, not necessarily all the specifics.  Have everyone clear on what the company KPIs are.  Is it revenue?  Is it cash?  Is it the number of clients?  Is it the number of contracts?  Everyone should know them.  Leadership should use them all the time so that education is repetition, so that they stick into everyone's mind.  Where is it produced?  Internal, external sources, third parties.  Manual operations.  And I'm not talking about listing everything, but at least that they know, okay, all of our data is internally produced.  We got nothing from the outside.  Or 50% of our data comes from a third party.  Or we buy 90% of what's very useful to them, to us.  The second one is consumption.  So who's using data in the company?  And that's fascinating because very often you have a siloed approach about the company.  So you know what you are doing.  You don't necessarily know well what others are doing.  You don't necessarily know well what others are doing.  So you don't know how they use data.  And the last part is people need to be aware when there are systems in the middle between the production and the consumption.  And that would be, okay, who's processing the data?  Who's responsible for what?  It's super important because one of the common difficulties of data teams is that they are usually the middle system.  And they get squeezed between the consumer that tells them, hey, your data is broken.  It's wrong.  Why didn't I not have my data this morning?  And the producers that sometimes just like to break things without knowing that they dump stuff into a hole and they don't really know how it's used.  Usually they don't consume their own data.  So that creates a bit of a problem.  How do you manage your data?  

‍

Samaipata: What are your top three pieces of advice for a startup founder looking to get their data operations up and running?

Emmanuel: Keep it simple.  It's important because today in the market you have like 15 different tools to do any single operations in data.  And very soon you can end up with a lot of data.  And if you end up with a super complex stack to maintain, then you need people to administer them and to connect them and to debug them and so on and so on.  So a good example is that you can go pretty far by having a daily or a monthly extract of your databases put into at the very beginning, put into a few spreadsheets and build some reporting on top of that, like fairly simple graphs and so on.  

The second one is about: okay, what are your objectives?  You'll have a lot of data. You'll have limited resources, both in terms of money, people, time.  You'll have a lot of constraints because data is integrated in the whole system.  And so it's super important to be clear on, okay, in this phase for the next nine months, what we're going to do is focus on the foundations.  And so we are going to take relatively little tickets, requests on, hey, can you compute that number?  Can you compute this analysis?  And maybe then it's going to be okay.  We need to do something new that we didn't before.  It could be streaming real-time data.  It could be machine learning.  But you need to be clear on, okay, we're going to focus on a single problem that's going to eat up 60, 70% of our time.  The rest is going to be run, like operations.  But we're going to do one problem at a time.  The risk otherwise is that you just like to go all over the place and you don't have enough time to complete your projects.  

And probably the last is to allow yourself to fail because that's going to happen.

‍