Product leaders love to share their wins. Here's what I don't hear enough: the bets that seemed right at the time, cost real money and time, and taught more than any success story.
These are four of mine.
1. I bet on greenfield when consolidation was the answer
Early in my career, my instinct when inheriting a messy platform landscape was to build something new. The existing tools were fragmented, poorly documented, and nobody liked them. A greenfield build would be clean, well-architected, and solve everyone's problems.
Why it seemed right: The existing tools really were bad. Users really were frustrated. A new platform really would be better.
What actually happened: The new platform was better technically. But adoption stalled because users had workflows built around the old tools. They had scripts, integrations, saved configurations, and muscle memory. Asking them to switch was asking them to rebuild their entire operational practice — not just install a new tool.
What I do differently now: At E.ON, I faced the same situation — six monitoring tools, nobody happy with any of them. Instead of building a seventh, we consolidated into one unified observability platform on OpenTelemetry. Same technical outcome, but we migrated existing workflows instead of asking users to abandon them. The difference in adoption was night and day.
The lesson: The instinct to build fresh is a trap. The value is in the integration, not the invention. The unsexy work of consolidation almost always beats the exciting promise of greenfield.
2. I underestimated the politics of multi-stakeholder platforms
On a multi-brand platform project early on, I thought the hard part was the technical architecture. Design a good shared backend, build a flexible frontend layer, ship it. The technology was tractable. What I didn't account for was that each business unit's leadership saw the platform as a threat to their autonomy.
Why it seemed right: The technical challenge was genuinely complex. Multiple countries, languages, legal entities, payment systems. It made sense to focus on solving the hard engineering problems.
What actually happened: The technical solution was ready. But three of the five stakeholder groups hadn't bought in. They stalled, raised objections, escalated to their own leadership. The project timeline doubled. The technical architecture sat idle while political negotiations dragged.
What I do differently now: At Volkswagen, I faced the same pattern — five brands, five sets of leadership, each convinced their customer journey was unique. This time I designed the architecture to serve the politics. WhiteLabelFrontEnd + MonoRepo gave each brand visual independence while sharing the backend. Each brand's leadership could point to "their" frontend. The architecture gave everyone something to claim as a win. The 1M+ unified users happened because the politics were solved first.
The lesson: In multi-stakeholder environments, the architecture must serve the politics, not the other way around. If your architecture can't survive a stakeholder who hates it, it's not ready.
3. I over-engineered compliance instead of designing around it
Before I worked at Bundesdruckerei, my approach to regulatory constraints was to build the product first and add compliance later. Compliance was a checkbox exercise — something you handled in the last sprint before launch.
Why it seemed right: Compliance requirements are often vague at the start of a project. Building the product first lets you understand what you're building before you figure out how to make it compliant.
What actually happened: Compliance reviews at the end of a cycle found structural issues, not surface problems. The architecture had assumptions that conflicted with the regulatory requirements. Fixing them late meant rework — sometimes significant rework. The launch slipped, not because the regulation was strict, but because we had designed a system that fought the regulation instead of working with it.
What I do differently now: At Bundesdruckerei, building the PLAIN sovereign data platform under KRITIS — Germany's strictest infrastructure classification — I made the regulatory constraint the first design input, not the last review gate. Every architecture decision had a clear criterion: does this meet the regulatory bar? There was no ambiguity. Stakeholders couldn't argue with the law. And the resulting architecture was simpler because the constraint narrowed the solution space.
The lesson: Compliance bolted on at the end is expensive. Compliance designed in from the start is a forcing function that makes everything faster. If your regulatory review keeps finding structural problems late, you're designing the wrong system.
4. I optimized acquisition when retention was leaking
Before working at Nelly Solutions, I would have told you that growth is about acquisition. More users, more revenue, more market share. The funnel starts at the top, and that's where you invest.
Why it seemed right: Acquisition metrics are visible. You can measure CAC, track conversions, A/B test landing pages. Growth feels like a top-of-funnel problem because that's where the measurable levers are.
What actually happened: On a previous engagement, we spent months optimizing the acquisition funnel. Conversion rates improved. But revenue didn't grow proportionally. We were acquiring users faster, but they were also leaving faster. The churn problem was invisible because we were looking at the wrong metrics.
What I do differently now: At Nelly, we maintained 0.7% monthly MRR churn across 1,200+ medical practices. That number didn't happen by optimizing the top of the funnel. It happened by building detection logic — usage frequency drops, support ticket spikes, feature abandonment patterns — that flagged at-risk practices weeks before they cancelled. The insight was that churn is visible in the data long before the cancellation. You just have to build the detection first.
The lesson: If your growth metrics are improving but revenue isn't, the problem is retention, not acquisition. Build the detection logic before you build the next feature.
These four bets cost me time, credibility, and in some cases real money. But they're the reason I know what to look for now. Success stories tell you what worked. Failure stories tell you what to watch for.
Every platform leader makes these bets. The question is whether you catch them early enough. If you're facing a similar call, I've probably been on both sides. Book a 30-minute call and let me save you the tuition.