SAP — Why a Design Sprint Hackathon beats a regular hackathon every time

The assumption most innovation programs make

When large organizations run hackathons, they tend to assume two things: that the best ideas come from the people who can build them, and that energy in the room translates into outcomes after the room disperses.

Both assumptions are wrong often enough to matter.

The first one excludes the people who understand the problem most clearly — the operations lead who knows where the workflow breaks, the customer-facing manager who hears the same complaint every week, the analyst who has been sitting on data that nobody has connected to anything actionable. These people don't think of themselves as hackers. They don't sign up for hackathons. And so their insight never enters the room.

The second one runs into the reality that a pitch night, no matter how energizing, is not a decision. A great idea presented to a panel of judges produces applause. It does not produce a clear next step, a business owner, or any of the evidence a leadership team needs to fund what comes next.

SAP had run hackathons before. Cameron Rouse, who led the devXchallenge initiative from the inside, had tried them. Design thinking workshops too. What he was looking for was something that combined the energy and inclusivity of a hackathon with the structural discipline that actually moves an idea from a room to reality.

The answer was the Design Sprint hackathon.

What is a Design Sprint Hackathon?

A Design Sprint hackathon is a structured innovation event that uses the Design Sprint methodology as its operating format.

Unlike a standard hackathon — where teams self-organize, build freely, and pitch at the end — a Design Sprint hackathon runs every team through the same structured process: understanding the problem, generating solutions individually before collectively, converging on one direction, building a realistic prototype, and testing that prototype with real users before the event ends.

The result is not a pitch deck. It is a tested solution — something a real person has interacted with and responded to — with documented insight into what works, what doesn't, and what a team would need to do next to take it further.

SAP named their version of this format the devXchallenge. It ran across 2020 and 2021, reaching 328 participants across 6 locations, engaging 45 external customers and partners as ecosystem voices, and accumulating 13,210 hours of collective work on real-world challenges: sustainable urban mobility, economic recovery, and the EU Green Deal.

Those numbers came from a format that most people would still call a hackathon. What they wouldn't recognize is how different the process was inside it.

What made the format different

✅ It started with context

Before any team touched a problem, the format opened with what Cameron called a Primer Talk — a structured set of keynote perspectives from four different stakeholders in the challenge space. Each speaker answered the same four questions, so teams could compare and contrast viewpoints before they started generating solutions. The context was then packaged and given to teams as a reference throughout the sprint — not just a pre-event briefing that faded by lunchtime.

This matters because the most common reason hackathon solutions don't survive contact with the real world is that teams built something for a problem they understood only from the inside. The Primer Talk was designed to correct that before the work began.

✅ It was built for everyone, not just developers

Edina Siwell, who participated in the devXchallenge as a business stakeholder before moving into a solution management role, put it clearly: in a standard hackathon, the word itself creates a barrier. People who aren't developers assume the format isn't for them. They opt out before they've even seen the challenge.

The Design Sprint hackathon was open to all SAP employees, regardless of function, background, or technical skill. Teams were deliberately mixed — people from product, operations, sales, and business units who had never worked together before were placed in the same group. That mix was the point. The Design Sprint process is built to surface contributions from everyone, through individual ideation before group discussion, structured voting, and a facilitator whose job is to make sure the most senior voice in the room doesn't automatically win.

As Cameron described it, the design sprint reminded him of something he had experienced twenty years earlier — an environment where it was not the highest-paid person in the room driving the decisions. Where you could present your idea anonymously and have it judged on its merits. That quality of inclusion is structural in the Design Sprint. It is not something you can achieve in a standard hackathon by telling people to speak up.

✅ The challenges were real

SAP chose themes that connected to things their employees were already living — sustainable urban mobility was picked in part because conversations in the office cafeteria were already about commuting, pollution, and delivery logistics. The EU Green Deal framing connected to regulatory pressures their customers were already navigating. Crisis planning connected to events people were watching in the news.

This was deliberate. Cameron's view was that people engage differently when the problem feels like it belongs to them as citizens and professionals — not just as corporate participants. Local challenges were brought to local events, so teams in Dublin worked on problems rooted in Dublin's urban mobility context, and teams in Munich worked on challenges shaped by what Munich's city government was actually trying to solve.

The 45 external customers and partners who participated as ecosystem voices — mobility providers, city representatives, sustainability consultants — weren't there for optics. They were the source of the problem context that made the challenge feel real and the solutions feel consequential.

✅ Every team built a prototype — and tested it with real people

This is the sharpest difference between a Design Sprint hackathon and a standard hackathon, and it changes everything about what happens at the end.

In a standard hackathon, teams build what they can in the time available and pitch it to judges. The prototype, if there is one, is optimized for the demo — functional enough to show, not rigorous enough to learn from. The judges are evaluating an idea, not evidence.

In the Design Sprint hackathon, every team built a realistic, interactive, functional prototype and tested it with real people — customers, users, or relevant stakeholders — before the final event. The testing happened as a structured part of the sprint, not as an afterthought. Teams sat with real users, watched them interact with the prototype, and captured what worked, what didn't, and why.

By the time teams arrived at the Reveal Night, they weren't presenting ideas. They were presenting findings. The judges — often the same external stakeholders who had participated in the Primer Talk — heard not just what each team had built, but what real users had said about it. That's a categorically different conversation. Cameron described a recurring moment: a mobility provider watching multiple teams present their testing results and saying the real answer was a synthesis of several of them. That response only happens when the solutions in the room are grounded enough to be credible. It doesn't happen when teams are pitching slides.

‍

This is what a remote design sprint hackathon looked like from the inside - from our office at DSA.

‍

DSA designed the system — and trained SAP to run it

Design Sprint Academy's role in the devXchallenge went well beyond showing up to facilitate.

Before the first event ran, DSA built the full operational infrastructure for the format: the event agenda, the Miro templates teams would work in throughout the sprint, the playbooks, guides, and a replay report structure that documented each event so future facilitators could learn from it. For the remote sprints specifically — which required a different kind of design than in-person sessions — DSA created the digital environment from scratch. Every stage of the process had a pre-built Miro workspace ready to run, so facilitators could focus on the people in the room rather than the logistics around them.

DSA then trained SAP's own design thinking experts to run the format independently, in two layers.

• First, formal training — SAP's facilitators went through DSA's program and learned the methodology, the facilitation principles, and how to guide a cross-functional group through each sprint activity.
• Second, live shadowing — SAP facilitators joined DSA-led events in an observer role, watching the process run in real conditions before taking the lead themselves.

‍

Once trained, the handover was deliberate and gradual. DSA facilitated some events while SAP facilitators shadowed. Then SAP facilitators led while DSA observed and provided feedback. Over time, SAP's team took full ownership of running the format independently. As Cameron described it, a trained internal facilitator needed roughly an hour of onboarding before an event — because everything else was already staged for them.

This is the step that separates an innovation event that becomes a repeatable organizational capability from one that stays an annual set-piece dependent on an external partner. SAP invested in it from the start. The goal was never for DSA to be the permanent engine. It was to build something SAP could run, scale, and own.

Cameron Rouse walked through the full devXchallenge story in a live conversation with DSA's co-founders — watch the recording here.

What This Means If You're Designing an Innovation Event

If you're a Director or Head of Innovation at a large organization, you've probably been asked to justify the ROI of an innovation event before you've run it, and explain why it won't be another one of those things that produces a great week and no follow-through.

The honest answer is that the format determines the outcome more than the energy does. A well-run hackathon produces engaged participants. A Design Sprint hackathon produces engaged participants and tested prototypes and a structured path to what happens next.

The three things that made this format work at SAP are not specific to SAP. They're structural:

Context before creativity. Bring in the external voices who carry the real constraints of the problem before any team starts generating solutions. The Primer Talk format is replicable. The commitment to doing it is the variable.

Inclusion by design. A process that levels the room — individual ideation before group discussion, anonymous idea evaluation, a facilitator whose job is to balance voices — produces different contributions than a free-form event. The people who have the most relevant insight are often not the most confident speakers. The process has to create space for them.

Evidence before the pitch. The Reveal Night works when the teams bring something real. That means prototyping with enough fidelity that real users can interact with it, and testing before the event ends. The feedback from those sessions is what turns a good idea into a defensible one.

None of these require a five-figure budget or an external facilitation team indefinitely. What they require is a structured methodology, trained facilitators who know how to run it, and the discipline to treat the process as seriously as the event.

DSA and SAP built that together over two years. The format compounded because it was designed to compound — each event feeding the next, internal facilitators getting sharper, and the pipeline of ideas getting better grounded with every Reveal Night. Ideas that showed promise at the Reveal Night could move into SAP's longer-form innovation programs — already grounded in user evidence, not starting from scratch.