We Combined a Design Sprint with a Hackathon. It Helped Us Rethink Customer Activation
How we used a design sprint-hackathon hybrid to build AI-powered prototypes, spark urgency, and move fast
Customer onboarding was strangling our business’s growth. It was taking months for customers to launch the product internally to their employees. The process was too complex, too confusing, and too hard to do alone. Customers were stuck.
We needed some rocket fuel. Nathan Bilbao, the activation product designer, and I had been planning an offsite in Munich. We asked: what if we used that time to chase moonshots? How might we do that in a productive way? Would it be a design sprint? A hackathon?
It turned out to be a little of both. This is the story of how we challenged a group of 15 people from across Europe and the US to create concepts that would empower customers to activate in 5 days. What followed was an AI-first hybrid design sprint where four bold prototypes emerged; each reimagining how we onboard customers. This post breaks down how we ran it, what worked, what we’d change, and how you can use the format to tackle big, thorny problems in your own org.
👋 Hey, I’m Alex. I write Shipping on Fridays to explore the craft of how great products get built and what we can learn from the people behind them. I publish 1–2x a month, and every post is meant to be fun, useful, and a little unexpected; from design sprints to sailing races to holiday chaos. If you’re into learning, product or design, this is for you.
How we created a supercharged design sprint
How might we get moonshot concepts out of 15 people traveling across two continents to come together in Munich for just 3 days?
We built a hybrid: the structure of a design sprint, the speed of a hackathon. We divided the group into 4 x-functional teams that included PMs, Designers, Engineers and Customer Experience members. The teams were intentionally shuffled so that people were working with other people they usually didn’t work with. Mixing teams killed old assumptions, forced fresh thinking, and ensured cross-pollination.
In the six weeks leading up to the design sprint we did a lot of prep work in addition to the normal planning and logistics of running a design sprint. First, we mapped the full onboarding journey across teams and channels to expose problems that were slowing activation. We wanted to arrive at the design sprint with a journey map to align everyone on the current process, customer pain points, and internal friction. To incorporate customer quotes into the journey map, we leveraged reams of raw data: Gong calls, customer surveys, as well as Salesforce data detailing win and loss reasons. Nathan leveraged NotebookLLM, a research specific LLM, to help us sift through this data. Nathan used the LLM to create summary reports of top customer problems identified within each source.
Knowing that we would be encouraging teams to take an AI-centric approach to prototyping, Nathan also prebuilt code assets so that each team would have a library to build from - giving our design sprint teams a jump start.
At the design sprint itself, we created a culture that balanced group collaboration with individual team identity. We wanted to spark some competition and for the teams to work independently and take full ownership over the concept they develop, while also ensuring that the group learned from each other.
We accomplished this by creating daily agendas that balanced points of convergence - where we heard from each other or subject matter experts with long periods of divergence and individual teamwork. See our sample agenda (that you can copy!) here. Our three days looked like this:
Day 1 — Understand + Brainstorm
AM: Customer pain points (empathy exercise, expert talks and journey map)
PM: Team breakouts + brainstorming / early storyboardingDay 2 — Storyboard + Prototype
Storyboarding → Prototype buildingDay 3 — Refine + Demo
Finish prototyping → Rapid-fire testing → Iterate → Demos!
Building Empathy Early
To kick things off on Day 1, we gave each team a fake company account, the onboarding project plan given to customers, and 45 minutes to get as far as they could into onboarding. The goal? Feel the pain our customers face every day.
We took a few steps to make this scenario real. First, we worked with Implementation Managers (the folks who help our customers onboard) to build company dossiers based off of actual customers complete with messy data and typical human errors. Second, we included “mystery envelopes” with special requirements. Implementation Managers had stressed to us that edge cases show up for every customer. It was crucial for our design sprint participants to experience these curve balls - again based on actual customer scenarios. Lastly, after the 45 minutes ended we came back as a group (one of our convergence times!) and several Implementation Managers led the whole group in a discussion to reflect on the customer problems.
We ended with a group of frustrated people. Sticky notes filled with “why can’t I…?” and “how am I supposed to…?” moments. One team member nailed it in our reflection:
“This sprint isn’t just about optimizing form fields — we’re going to have to rethink onboarding.”
Exactly. That moment flipped the switch - our empathy exercise had not only helped team members understand the end user pain, but also the severity of the business problem. It also acted as a fast-forward button for team cohesion. Working under pressure on a shared problem quickly broke the ice.
Empathy exercises are common in design sprints. We took it further by designing one we knew was impossible. No team was going to successfully onboard a fake company in 45 minutes — and that was the point. They’d hit the same roadblocks our customers face.
AI Centric Approach
We replaced typical low-fidelity paper prototypes with an AI centric approach. Instead of teams expressing their ideas on flip charts we urged teams to utilize the code assets Nathan created coupled with Figma Make and Cursor. This had three main benefits.
First, it allowed more members of the team to actually contribute to the prototype creation. Instead of team members operating within their single sphere of expertise, designers, PMs and engineers were all able to build and create together. Non-designers were able to express ideas visually. Designers were able to make interactive flows. Utilizing AI allowed teams to take ideas from sticky notes to interactive prototypes in minutes and hours. This sped everything up and let teams test ideas earlier. Instead of debating solutions, using AI allowed teams to quickly put those ideas in front of Implementation Managers for feedback.
Lastly, AI gave us durability and momentum to move forward at speed with next steps after the design sprint ended. By utilizing AI all the teams created designs and prototypes in a company repo, which we were then able to access and begin iterating and remixing in the weeks after the design sprint.
In Context Testing
When Nathan and I developed the agenda we built in six touchpoints for teams to test their concepts. I’m a strong believer in testing early and often (read more on testing strategies here) and being in Munich gave us a unique opportunity.
Munich is home base for our Implementation Managers, whom, given their daily work with customers, we could proxy for actual customer testing. We locked in 2-3 30-minute sessions with them for Day 2, giving each sprint team direct feedback on storyboards and early concepts. This differed from a classic design sprint where testing is normally in a last validation phase. By starting testing early we ground the culture of the workshop in constant iteration (like a hackathon). The check-ins themselves accomplished three things: they ensured ideas were based on real-world experience, they created time pressure by splitting the day into short, focused build sprints (a la hackathon), and it built cross-functional engagement with the Implementation Managers for future adoption.
Day 3 was more intense. Each team ran three back-to-back user tests with different Implementation Managers — no breaks, no time to iterate. Test, capture, reset. Only after the final test did teams regroup, synthesize the feedback, and adjust their prototypes ahead of the final demo.
This rhythm worked. The Implementation Managers didn’t just review concepts, they pressure-tested them, shared customer stories, made ideas sharper and allowed sprint teams to kill concepts that wouldn’t work. With over five points of feedback, teams were able to spot patterns. The result? Prototypes that were more grounded, more useful, and way more likely to stick.
The Results
The sprint wrapped with a full-room demo: our COO, his leadership team, and the entire Implementation crew. Basically, everyone in the company who cared about Activation.
Each team took a bold swing at rethinking onboarding. Some leaned into AI to cut manual steps, letting customers start with whatever documentation they could provide: tax statement, employee handbooks, even email threads. Another team designed ways for customers to browse configuration examples and copy settings into their own account.
All the teams made clear which customer problems they were solving, why those problems mattered and their hypothesis to solve them. Our sprint had both deepened our understanding of the problems customers face and offered concrete concepts (which with some iteration could be shipped). We could now chart a plan for getting customers to go live in a fraction of the time - maybe even 5 days! 😉
By working in a hybrid design sprint hackathon format we let teams move fast, stay focused and accountable. The final demos didn’t just showcase the prototypes, they also revealed how much can be built when rapid iteration is balanced with ownership and structure.
Reflections & Learning
Plan obsessively. Start early to align calendars, secure travel, book rooms, and prep materials. Details like sticky notes and lunch matter more than you’d think.
Use empathy as your icebreaker. We skipped a traditional icebreaker in favor of a hands-on onboarding simulation. It got teams talking fast and framed the challenge perfectly.
Protect your agenda. Time is tight. Every session needs to earn its spot. To sanity check, ask yourself the re-org question — would I fight to keep this if I knew this was the last time I was working on this problem? (More on that in this post.)
Prepare for success / Lighten your participants load Give your teams the best chance to take big swings by pre-seeding assets you think they might need to build their prototypes.
Test early and often. The biggest unlock came from repeated, real-time feedback. Don’t save testing for the end.
Own the tension between structure and speed. We gave teams autonomy but held a tight daily rhythm. That mix pushed teams to move fast and stay focused.
Design for moments, not just outputs. The onboarding simulation, feedback loops, and demo hour all created energy and alignment. Think beyond the sprint wall.
Steal our Playbook
A design sprint gives you structure. A hackathon gives you speed. Together, they gave us something better: momentum to improve customer onboarding.
We didn’t leave Munich with a perfect prototype or something we could immediately ship. We left with a deep understanding of the customer problem, lots of ideas on how to work better cross functionally, and four prototypes that contained the kernels of a solution to supercharge customer onboarding.
If you’re stuck in slow progress, give it a shot. Use our agenda. Try the empathy setup. Adapt the format to your world — and let us know how it goes.
 | A guest post by
|