5 Signs Your Enterprise Platform Needs a Product Leader, Not Another Architect

I've spent ten years inside enterprise platform teams at some of Germany's biggest companies, and the failure I see most often has nothing to do with technology. The platform has an architect, a roster of engineers, and a steering committee. What it doesn't have is anyone whose actual job is the product: adoption, time-to-value, and the unglamorous decisions about what the team should refuse to build. Here are the five signs that gap has opened up.

A senior engineer needs a test environment to validate a change before the Friday release. She files the ticket already knowing the answer: six to eight weeks. The queue to get started is longer than the sprint the environment is meant to serve.

That was Allianz, where cloud provisioning had stretched past a year at its worst. The engineers were fine. Every environment dragged a tail of manual approvals and bespoke networking behind it, through a queue no one ran as a product. When the wait to start building is longer than the work itself, people stop waiting honestly: shadow IT spreads, one-off workarounds harden into the real system, and the platform team becomes the thing everyone routes around.

The fix was to make provisioning self-service and move compliance into the pipeline instead of the final review. The wait fell from months to days. That's a product decision, not an infrastructure upgrade. Somebody had to decide the engineers' time was the number that mattered.

Volkswagen Group wanted five brands (VW, Audi, Skoda, Seat, Porsche) on a single commerce backbone, serving over a million users across several countries and legal entities, each with its own P&L.

The diagnostic wasn't in the architecture diagram. It was that every brand had spun up its own "strategic digital initiative," each one quietly built on the belief that its customers were a special case and its leadership shouldn't have to cede control to a shared system. An architect can hand you a clean shared backend. Getting five sceptical brands to actually stand on it is a different job: deciding, brand by brand, where each keeps independence and where it gives some up.

We landed on a WhiteLabelFrontEnd over a MonoRepo, so every brand kept a storefront it controlled on top of one shared layer. The million-plus users came less from the engineering than from a negotiation that ran longer than the build and finally closed.

I joined E.ON Digital Technology to find six monitoring tools in use: one for IT, one for OT, one per business unit, and a couple nobody could account for. The standard enterprise answer is another replatform: "if we just build the right one this time, everyone will switch." They don't, and the sub-30% adoption on the last two attempts is the proof.

Adoption isn't something you can architect into existence. It comes from meeting people inside the workflows they already have, taking the friction out of migrating, and earning trust before you ask anyone to change how they work. We consolidated onto one OpenTelemetry-based observability platform spanning IT, OT, and grid. The tool count dropping was the headline. The real win was shared alerting, quicker detection, and the end of the standing argument over which dashboard to trust mid-incident.

Bundesdruckerei runs identity infrastructure for eleven federal ministries under KRITIS, the top tier of German infrastructure law. Most teams read that as a licence to go slow.

You can spot the dysfunction by where compliance sits in the calendar. If the review only happens at the end of the cycle, turns up structural problems every time, and pushes the launch, that isn't the regulator being difficult. It's a process that decided to learn the rules last. On the PLAIN sovereign data platform we ran it the other way: KRITIS was a design input from the first decision, and every choice carried one question, does this clear the bar? You don't get to argue a federal requirement down in a meeting, so the debates that usually eat weeks never started.

That project took 2nd place in the eGovernment Competition, and it got there because of the constraint, not despite it. A regulation that's central to the design cuts your options down early, which is what keeps the remaining decisions quick. Treated as a final-sprint checklist, the same regulation does the opposite.

At Gesund.de I helped build the PaaS under a digital-health marketplace: €417M of Rx revenue moving through it, ML-driven product recommendations, prescription flows that held up legally across several markets.

Ask a customer what Gesund.de runs on and you'll get a blank look. They tap a button, a recommendation appears, the prescription clears. The ML pipeline, the regulatory workflow, the PVS integrations, the per-market compliance, none of it surfaces into what they experience, and that's the mark of it working.

The warning sign is the inverse. When the people using your platform start narrating it back to you, naming "the new system" or "the migration" or whatever broke last week, the machinery has pushed through to the surface. They should feel the result and never the wiring.

---

Recognize a few of these? I've sat in the product seat for every one of them. Book a 30-minute call and tell me what you're seeing.