Seven data product managers, and a company that turned EBITDA positive

This was an in-house role. I was an employee with a permanent mandate, a budget, and about three years. That changes what was possible and how long it took, and it is worth saying before any of the numbers.

The situation

Babbel had a data team, a warehouse, and no shortage of dashboards. What it did not have was anyone whose job was to decide what data work was worth doing.

The pattern was familiar. Requests arrived from marketing, from product, from finance, and the data team worked through them in roughly the order they arrived. Good analysts spent their weeks building things that were used twice. Nobody could tell you what the data organisation had shipped in the last quarter, because it had shipped forty things and none of them were products.

At the same time the company was under real commercial pressure. The path to profitability was what leadership talked about. Marketing was spending against acquisition targets, and the two numbers that would tell you whether that spend was working, customer lifetime value and customer acquisition cost, existed in three different definitions in three different places.

The constraint

Three things bounded what I could do.

I could not hire my way out of it. The company was managing costs on the way to profitability, so a large data team was not on offer, and it would have been the wrong answer anyway.

The cloud bill was going the wrong direction. Storage costs were growing faster than usage, which meant any proposal starting with “and we will need more infrastructure” was going to be a short conversation.

The third one was the real constraint: the data team did not believe they had a problem. They were busy, they were responsive, and they were well liked. From the inside, a data team that answers every request quickly feels like a data team that is winning.

What I did

I started with the third constraint, because the other two are solvable and that one is not if you get it wrong.

I spent the first two months in other people’s meetings. Not data meetings. Marketing performance reviews, the finance forecast cycle, product planning. I wanted to see the moment a decision got made, and find out whether anything we produced was in the room when it happened. Mostly it was not. Somebody would have a number, and the number came from a spreadsheet a person maintained by hand, because that spreadsheet was trusted and our tables were not.

That gave me something to show leadership that was evidence rather than opinion.

Then I made one structural argument: the data organisation needed product managers. Not analysts with a new title, and not project managers. People whose job was to own a data product, know who used it, know what decision it changed, and retire it when it stopped changing anything.

This was harder to sell internally than it sounds. A data product manager looks, on an org chart, like overhead. The argument that worked was a cost argument. I showed what we were spending on data work nobody consumed, in engineering time and in storage, and proposed that the product management layer would pay for itself by killing things.

We went from zero data product managers to seven over about eighteen months. I hired the first two myself and was deliberate about the profile: people who had worked close enough to a P&L to be comfortable saying no to a director. The interview loop had one specific exercise in it, which was to take a real request from our backlog and argue for not building it.

Alongside the hiring we did four things.

We standardised the revenue data models. One definition of revenue, one of lifetime value, one of acquisition cost, owned by named people, documented, and wired into the systems the marketing and retention teams actually worked in. This had the most political cost and the most value.

We built quality in rather than checking it afterwards. Automated controls in the pipelines, contracts on the interfaces that mattered, alerting that went to an owner rather than to a channel.

We cut storage. Mostly by deleting things nobody read and by changing retention on things we were keeping out of habit. I asked for the savings to be reinvested into infrastructure rather than returned, and got it, which mattered more for the team’s belief than the money did.

We taught people. Self-paced and live training aimed at new joiners first, because new joiners have no habits to unlearn.

The result

The first data products were live within six months.

Time to answer went from two to four weeks down to five to ten minutes. That is the number I would lead with if I were only allowed one, because it is the one that changes behaviour rather than reporting on it. Two to four weeks is longer than the decision it was meant to inform, so people stopped asking. Five to ten minutes is inside the meeting, which means the question gets asked at all.

In plain terms: the answer now arrives while you still care about it.

Maintenance cost on the data architecture came down by 40% over the same period, for the same underlying reason: the old systems were switched off rather than kept running alongside the new ones.

95% availability on the standardised revenue models. Measured against data contracts written per consuming use case, and enforced by computational governance rather than by review.

In plain terms: the teams that depend on those numbers agreed in writing what would arrive, in what shape, and how often. The system enforces that agreement automatically instead of a person checking. Nineteen times out of twenty, the number was there when they needed it.

93% satisfaction among the consumers of the data products and data assets. Marketing, retention, product and finance, meaning the people who actually used the things, rather than a company-wide survey where most respondents have no opinion.

In plain terms: we asked the people who would notice.

60% out of cloud storage cost. Achieved by sunsetting the monolith and the legacy systems around it rather than running them alongside the replacement, and by moving onto a stack that bills storage separately from compute.

In plain terms: most companies migrate onto new systems and keep the old ones running “just in case”, so they pay twice. We switched the old ones off. The new setup also stops charging you to store data nobody reads.

The number I care about is the one furthest from my team. Babbel reached EBITDA positivity, and the lifetime value and acquisition cost work was part of how leadership steered to it. Marketing could see what a cohort was worth before deciding what to pay for it. That is what a data organisation is for.

A note on the figures above. They are internal measures and I have not had them independently audited, which is stated here rather than left for you to discover. Every one of them carries its measurement basis on this page, and where a basis is genuinely unknown the number does not appear at all.

What I would do differently

I hired the seventh person before I fixed the intake. For the first year the data product managers spent too much of their time being a more expensive version of the ticket queue, because I had given them ownership without giving them a real prioritisation forum. Two of them nearly left over it. If I did it again, the intake process and the forum where prioritisation actually happens would exist in week one with two people, rather than in month nine with six.

I underestimated how much of this was a finance relationship. The work that mattered most was the lifetime value and acquisition cost work, which is finance’s language on finance’s calendar. I spent my first six months building credibility with product and engineering because that is where I am comfortable. The finance relationship unlocked everything, and I got to it late.

I would kill things louder. We retired plenty of unused reporting, quietly, to avoid arguments. Quiet deletion means nobody learns the lesson. A monthly note saying what we switched off and why would have done more for the culture than any of the training did.