4 Platform Bets I Got Wrong (And What They Cost)
Four enterprise platform bets I got wrong at Volkswagen, E.ON, Bundesdruckerei, and Nelly — and what each cost. Hard lessons for platform leaders in DACH.
Product leaders are happy to walk you through the calls that worked. The more useful stories are the ones that looked obviously right at the time, quietly cost a lot, and taught me more than any win on the CV. Here are four of mine.
1. I bet on greenfield when consolidation was the answer
Early on I inherited a platform that was, by any fair account, a mess: fragmented tools, documentation nobody trusted, engineers who couldn't agree on which system was the source of truth. The fix looked obvious. Tear it down and build something clean. The old tools really were bad and the people using them really did resent them, so a well-designed replacement would win on merit.
It didn't.
Technically the new platform was better. Adoption stalled anyway, almost from launch. People had years of scripts wrapped around the old tools, integrations bolted to their quirks, saved configurations they'd spent months tuning, muscle memory for workflows I had just deleted. I thought I was asking them to install new software. I was actually asking them to rebuild how they worked, and they had no reason to say yes.
By the time I reached E.ON and its six monitoring tools, I didn't reach for the seventh. We consolidated onto one OpenTelemetry observability platform and carried the existing workflows across rather than asking anyone to abandon them. The adoption that had been a fight the first time came almost for free.
The first bet cost me a good platform nobody used and the months it took to admit it. Building fresh is the satisfying move and usually the wrong one. The value tends to hide in what already works, however unglamorous it is to leave it standing.
2. I underestimated the politics of multi-stakeholder platforms
On an earlier multi-brand build I put my chips on the architecture. Several countries, languages, legal entities, payment systems: that was clearly where the hard problems lived, and if I got the backend right the rest would fall in line.
The backend got done. Then nothing moved. Three of the five stakeholder groups hadn't actually signed up for any of it, and they let that be known slowly, through objections and escalations to their own leadership, while the finished architecture sat idle. The timeline doubled before a line of it shipped.
What I'd misread was the motive. To each business unit's leadership the shared platform didn't read as efficiency. It read as losing control of their own house, and no diagram, however clean, talks anyone out of that.
Volkswagen was the same shape (five brands, five leadership teams, each sure its customers were the exception) and that time I started from the politics. The WhiteLabelFrontEnd-on-MonoRepo split existed so every brand could point at a storefront that was visibly its own while the backend stayed shared. We got 1M+ users onto one platform because that fear was handled before the engineering, not left to surface after it.
The first bet cost a doubled timeline and credibility I then had to rebuild. When a platform has many owners, the politics decide what ships. The stakeholder most able to block you has to see something they gain by not blocking you, or the cleanest architecture in the company just sits and waits.
3. I over-engineered compliance instead of designing around it
For most of my early career, compliance was a thing you did at the end. Build the product, see what you've got, then work out how to make it pass. The reasoning felt airtight: you can't know which rules bind you until you know what you've built.
What that reasoning kept producing was late, structural surprises. A review at the end of a cycle doesn't catch cosmetic issues, it catches foundational ones, because the architecture was settled months earlier with the regulation nowhere in the room. You can't patch your way out of that, so the launch slips, and it slips less because the rules were harsh than because the system was quietly built to fight them.
At Bundesdruckerei I built the PLAIN sovereign data platform under KRITIS, Germany's strictest infrastructure classification, and inverted the order. The regulation was the first input, ahead of the first architecture decision, not a gate at the end. Every choice answered to the same question, and because that question was the law, there was nothing left to negotiate. The architecture came out simpler than it would have otherwise, since the constraint had thrown out most of the options before we got to them.
It finished 2nd in the eGovernment Competition. The lesson cost me a run of earlier slipped launches to learn: a hard constraint is only expensive when you meet it late.
4. I optimized acquisition when retention was leaking
For years I treated growth as a top-of-funnel question. More users in at the top, more revenue out the bottom. That's where the legible levers are too (CAC, conversion rate, landing-page tests), so that's where I spent my attention.
On one engagement we poured months into the acquisition funnel. Conversion went up. Revenue didn't follow, and it took me embarrassingly long to see why: we were filling the top faster while the bottom drained just as fast. The leak never showed up because none of the dashboards I was watching pointed at it.
Nelly Solutions is where that flipped. We held 0.7% monthly MRR churn across more than 1,200 medical practices, which for healthcare SaaS is genuinely unusual, and not one point of it came from acquisition. It came from catching practices on the way out. A practice in trouble leaves a trail in the data well before it cancels (sessions thinning, tickets climbing, the features it used to lean on going quiet), and we built the detection to read that trail and step in while the account was still saveable.
The expensive part of this bet was a quarter we spent celebrating conversion gains the business never felt. The cancellation is the lagging signal. If your growth numbers are climbing and revenue isn't, the answer is almost never the next feature; it's looking harder at what your data already says about the customers you're about to lose.
Between them, these four cost me time, credibility, and in a couple of cases real money. They're also most of what I actually know now; the wins, by comparison, taught me very little.
Every platform leader places bets like these. The only question that matters is whether you catch the bad ones early. If you're standing in front of a call that feels familiar, odds are I've been on both sides of it. Book a 30-minute call and let me save you the tuition.
Related reading
7 Things I Learned Building Enterprise Platforms for Germany's Biggest Companies
Seven lessons from a decade at E.ON, Allianz, Volkswagen, Bundesdruckerei, and Gesund.de. What actually matters when building enterprise platforms in Germany.
5 Signs Your Enterprise Platform Needs a Product Leader, Not Another Architect
Enterprise platforms fail because nobody treats them as a product. Five signs I've seen across Allianz, Volkswagen, E.ON, Bundesdruckerei, and Gesund.de.
Why the DACH enterprise market builds better platforms than Silicon Valley
The constraints that make the DACH market 'harder' (regulation, data sovereignty, works councils) produce structurally better enterprise platforms.