The Eureka Experiment: Trying to Transform SAP's Delivery Model

Six months ago, I joined SAP Eureka with a simple mission: help a giant learn to move like a startup. Ship minimal marketable products. Co-innovate with customers. Prove that enterprise software doesn't have to take 18 months to implement.

Half a year in, I can report back: it's harder than it sounds. But not for the reasons I expected.

What We're Actually Building

Eureka's Consumer Industries team has been heads-down on three products: Revenue Growth Planning (RGP) for promotion planning, Revenue Growth Optimization (RGO) for maximizing promotional ROI, and Intelligent Claims Management (ICM) for automating claims. We're still working on getting the names 100% validated with branding - something startups never have to deal with.

I've been deep in the ICM world - learning the difference between billbacks and scanbacks, understanding why claims analysts in Europe handle things differently than their counterparts in North America, mapping out workflows that have been running on spreadsheets and tribal knowledge for decades.

But here's the thing about building enterprise software: the technology is often the easy part. The hard part is getting people to actually use it.

The Adoption Problem

We've been running into a pattern across all three products that I didn't anticipate. We build features. We demo them to customers. They nod enthusiastically, point out things they like, then ask for a billion other features. We iterate on the initial feedback, ship improvements, and something new pops up. The cycle keeps going round and round.

And here's the uncomfortable truth: nobody is signing. No go-lives. No migrations. Which means we don't even have real usage metrics - because no one is actually using the products in production yet.

It's not that the software doesn't work. It's that we're asking people to change how they've done their jobs for years. A claims analyst who's been using the same Excel workflow since 2008 isn't going to switch to a new system just because it's "better." They need to see the value. They need to trust it. They need a reason to care.

But it goes deeper than the individual user. They need their manager onboard - it's a huge deal to change workflows, and they need convincing plus some kind of upfront proof. Then there's the buyer persona - usually a CIO or senior executive - who needs validation that the new workflow not only improves the company but is compliant and future-proof for whatever regulatory environment they're operating in. I'm working across customers in Canada, US, Belgium, Italy, France, and several other countries. Each has different requirements.

This is something I didn't fully appreciate coming from the startup world. At a startup, your users choose you. They're early adopters. They want something new. In enterprise, your users often have no choice - their company bought the software, and now they have to use it. That's a fundamentally different dynamic.

Enter Gamification

One of our design teams has been tackling the adoption challenge head-on with an approach I initially raised an eyebrow at: gamification. The team includes Yen Phoa, Hayley Olsen, Kayla Fathi, and Jenny Kim - all pushing the boundaries of what enterprise UX could look like.

The premise is straightforward. If we can't force adoption, maybe we can encourage it. Points for completing tasks. Badges for hitting milestones. Progress dashboards that make invisible work visible. A "Give Props" feature where teammates can recognize each other's contributions.

I'll admit - when I first heard "gamification for claims management," I thought it sounded like putting lipstick on a pig. These are serious finance professionals processing millions of dollars in claims. Are they really going to care about earning a badge?

Turns out: yes, actually. The user testing has been surprisingly positive.

One tester said, "I'm liking how it lets me see where I am at in the month." Another asked, "Badges are cute! What do I have to do to get them?"

But getting here wasn't straightforward. The first round of testing revealed some painful lessons.

Design Thinking in Practice

The initial gamification designs failed in three specific ways:

Context gap. Users couldn't understand how they were earning points. The mechanics were hidden in modals that nobody clicked. The team had to move instructional content directly into the dashboard widgets - making it visible, not discoverable.

Settings complexity. We gave administrators tons of customization options. Turns out, that's overwhelming when you're just trying to get started. The fix was a tiered approach: light, medium, and maximum complexity. Start simple, add sophistication later.

Visual distraction. Those celebratory badge animations? They were interrupting workflow. Claims analysts process hundreds of items per day. A two-second popup every time they complete something becomes maddening. The team had to dial back the visual impact and shorten display duration.

This is what design thinking actually looks like in practice. Not just sticky notes on walls and empathy maps, but real iteration based on watching real users struggle with your real software.

There's another dimension worth noting: while the UX research was solid - Figma designs validated by user interviews - we couldn't actually prioritize the gamification features in the build. The backlog to reach feature parity on base functionality was too long. We had to get the core claims processing working before we could add the engagement layer on top. So while the design failures above were real, there was also a fundamental prioritization problem.

The Bigger Experiment

Gamification is just one piece of what Eureka is trying to prove. The bigger bet is whether SAP - a company with 100,000+ employees and decades of enterprise software DNA - can operate like a product-led organization.

Can we ship in two-week sprints? Can we co-develop with customers instead of building in isolation for years? Can we make software that people actually want to use, not just software that checks compliance boxes?

Six months in, the jury's still out. And honestly? It isn't looking good.

SAP Global Product Standards are a real problem. They weren't designed for rapid iteration. They create bureaucracy and friction at every turn. We've got no dedicated sales or marketing team. Pricing strategies that are still TBD. The organizational immune system that every large company develops to protect itself from change.

And there's another problem lurking that we're just starting to see: high configurability. Enterprise customers don't actually like opinionated software. They want to change configurations and modify things to match their existing workflows. Every customer wants something slightly different. Building for that kind of flexibility is a fundamentally different challenge than building a focused product with strong opinions.

We've got early wins. Real customers working with us as we build - not building alongside us, but collaborating in shorter feedback loops than traditional enterprise development. Features shipping faster than typical SAP timelines. A team that genuinely believes in what we're doing.

But the structural challenges are real. We're not just building products for Consumer Packaged Goods companies. We're also trying to sell a new way of working internally - to executives, to sales, to the broader SAP machine.

What I'm Learning

The startup world taught me to ship fast and iterate. Boeing taught me that scale requires different disciplines - you can't just "move fast and break things" when millions of dollars and real operations are on the line.

Eureka is teaching me something new: changing an organization is a product problem too.

You can't just build better software and expect adoption. You have to understand the humans in the system. Their incentives. Their fears. Their existing workflows. You have to meet them where they are, not where you think they should be.

That's true for our customers. It's also true for SAP itself. Both are adoption problems. Both require empathy, iteration, and patience.

There's also a retail arm of MMPs spinning up adjacent to what we're building - something I'm aware of but not directly involved in. The scope of what Eureka is attempting keeps expanding, which tells me there's real conviction at the top that this approach is the future.

Here's the thing: the problems we're facing aren't reasons to stop. They're the actual work. Every successful technology transformation looks messy in the middle. The question isn't whether enterprise software can be built differently - we're proving it can, even if slowly. The question is whether we can move fast enough to matter.

I believe the answer is yes. Not because I'm naive about the challenges, but because I've seen what happens when you put builders in a room with real customers and tell them to ship. The energy is different. The feedback loops are tighter. The software gets better, faster.

Six months in, the experiment is still running. The outcome isn't guaranteed. But betting on technology to improve how humans work has always been the right side of history.

The future of enterprise software will be built by the people willing to try.