I've spent ten years inside enterprise platform teams at some of Germany's biggest companies. The pattern I see most often isn't a technology problem. It's an ownership problem.
The platform has an architect. It has engineers. It has a steering committee. What it doesn't have is someone who treats it as a product — someone who obsesses over adoption, measures time-to-value, and makes the hard calls about what not to build.
Here are the five signs I've learned to recognize.
1. Your provisioning queue is longer than your sprint cycle
At Allianz, cloud infrastructure provisioning took over a year. Not because the engineers were slow — because every environment required manual approvals, custom networking, and a ticket queue that nobody owned as a product.
When provisioning is slower than your development cycle, your engineers spend more time waiting than building. Shadow IT proliferates. Workarounds become permanent. The platform team becomes a bottleneck instead of an enabler.
We fixed it by treating provisioning as a product: self-service templates, Infrastructure-as-Code in a Hub-Spoke architecture, automated compliance checks baked into the pipeline. Provisioning went from months to days. The engineers stopped waiting.
If your internal users are filing tickets and waiting weeks for an environment, that's not an ops problem. It's a product problem. Fix it like one.
2. Every stakeholder group has its own "strategic initiative"
Volkswagen Group wanted five brands — VW, Audi, Skoda, Seat, Porsche — on a single commerce backbone. One million-plus users. One platform. Multiple countries, languages, and legal entities with their own P&Ls.
The tell was this: each brand had its own "strategic digital initiative." Each one believed its customer journey was unique. Each one's leadership needed to feel like they hadn't surrendered control.
This is a product problem, not an architecture problem. An architect can design a shared backend. A product leader negotiates the shared frontend — figuring out where each brand gets independence and where they share. We used a WhiteLabelFrontEnd + MonoRepo approach that gave each brand visual control while sharing the underlying layer. The 1M+ users on a unified platform wasn't a technical achievement. It was a negotiation achievement.
When multiple stakeholder groups each have their own roadmap for the same platform, you don't need better architecture. You need someone who can make the shared roadmap work politically.
3. You've replatformed twice and adoption is still under 30%
At E.ON Digital Technology, I inherited six monitoring tools: one for IT, one for OT, one per business unit, two that nobody remembered installing. The obvious move is to build something new. The right move is to consolidate what exists.
The replatforming instinct is strong in enterprise teams. "If we just build it right this time, everyone will adopt it." They won't. Adoption is a product problem — it requires understanding user workflows, removing migration friction, and proving value before demanding change.
We built one unified observability platform on OpenTelemetry — covering IT, OT, and grid infrastructure. The result wasn't just fewer tools. It was shared alerting logic, faster incident detection, and a team that stopped debating which dashboard to trust.
If your platform has been rebuilt twice and still has low adoption, the technology isn't the constraint. The product thinking is.
4. Your compliance team is the reason things are late, not the reason things are right
Bundesdruckerei manages identity infrastructure for eleven federal ministries under KRITIS — the strictest classification in German infrastructure law. Most teams treat regulatory constraints as reasons to move slower.
The sign is when compliance reviews always come at the end of a delivery cycle, always find problems, and always delay the launch. That's a process failure, not a regulation problem.
When I worked on the PLAIN sovereign data platform, we treated KRITIS compliance as a design constraint from day one. Every architecture decision had a clear success criterion: does it pass the regulatory bar or not? There was no ambiguity. Stakeholders couldn't argue with the law.
The result: the 2nd-place eGovernment Competition entry wasn't built despite the regulation. It was built because of it. Constraints narrow the solution space. That makes decisions faster, not slower — if you make the constraint central to the design instead of bolting compliance on at the end.
A product leader bakes regulatory requirements into the design. An architecture team bolts them on at the end.
5. Users can describe your infrastructure
At Gesund.de, I helped build a PaaS for digital health — 417M EUR in Rx revenue running through the platform, AI/ML personalization for product recommendations, regulatory-compliant prescription flows across multiple markets.
Nobody using Gesund.de knows what the platform does. They click a button, they get a recommendation, the prescription goes through. The ML pipeline, the regulatory workflow, the PVS integrations, the multi-market compliance layer — completely invisible.
When users can describe your infrastructure — when they talk about "the new system" or "the migration" or "the API" — something has gone wrong. The best platform work is invisible. Users should experience outcomes, not systems.
A product leader measures success by how little users think about the platform. An architect measures success by how well the platform is designed. Both matter. But if users are aware of your infrastructure, the product discipline is missing.
These five signs come from a decade of building platforms where the technical complexity was real but the product discipline was missing. In every case, the fix wasn't more engineering. It was treating the platform as a product with users, adoption metrics, and someone accountable for the experience.
Recognizing any of these? I've been the product leader in each of these situations. Book a 30-minute call and tell me what you're seeing.