Red Bull — Validating a new platform before committing to build it

The situation before the sprint

Every digital product team reaches this moment - there are more ideas than capacity, more stakeholder opinions than shared clarity, and a growing pressure to move. The risk at this point is committing to the wrong ones.

Red Bull's digital experience team was there. The organization had plans to launch a Community platform — a dedicated section of their site designed to bring fans closer to the athletes, events, and content they care about. The ambition was clear. What wasn't clear was which features would actually deliver value to users, and which ones were assumptions that sounded reasonable in a meeting room but hadn't been tested in the real world.

The team had no shortage of directions to pursue. What they were missing was a structured way to decide which of those directions deserved the investment.

Why the week before you build matters

There's a pattern that shows up repeatedly in product development. Teams invest weeks, sometimes months, in building something their customers never asked for. More often than not, the reason is because they started solving before they'd finished understanding.

The challenge Red Bull named it clearly: too many people in-house were starting from a feature idea and then working backward to fit it to an audience. The instinct to build first and validate later feels like speed, but it usually produces rework. And at the scale Red Bull operates, rework is expensive.

The question worth asking before any product investment is not "can we build this?".

It's

does building this solve something real for our users — and is that something we can verify before we commit?

That's the question a Problem Framing day followed by a Design Sprint is designed to answer.

Groundwork: understanding the audience before entering the room

Before the onsite week in Salzburg, the work started with qualitative research. Four interviews with biking enthusiasts — chosen because of their high engagement levels in the context Red Bull was exploring — gave the team a grounded picture of how this audience actually experienced Red Bull events.

The interviews surfaced the behaviors, pain points, and patterns that desk research and internal assumptions rarely capture. What the team found was that many of the most pressing user needs weren't complex platform features — they were what the team called "hygiene needs." Knowing the event schedule. Navigating the venue. Finding the best spots. Staying updated on results. Basic coordination that currently required users to piece together information from multiple tools and channels.

That single insight — that users had no central hub for the things that mattered most in the moment — became one of the most important inputs the team carried into the rest of the week.

The Problem Framing day

The Problem Framing workshop brought together key decision-makers from across the Red Bull digital organization: the Product Manager, UX Lead, Brand Manager, and Audience Marketing Manager. Four perspectives, one room, one day.

The goal wasn't to generate solutions. It was to align the group on what they were actually trying to solve — for the business and for the customer — before any solution thinking began.

The session worked through three interconnected objectives.

First, the team mapped the business goals: what the Community platform needed to achieve, how success would be measured, and what would happen if nothing changed.

Second, they moved into the customer experience — using the qualitative research conducted beforehand, alongside team knowledge and input from external experts, to map how someone experienced a Red Bull live event. What were they doing? What was getting in the way? What did they actually want?

The third objective was to convert that understanding into opportunities: specific areas where the platform could create value for both the user and the business.

The session did something that's harder to achieve without this kind of structure: it aligned the room on a shared definition of the problem before anyone started proposing answers. That alignment is the foundation on which everything that follows depends. Without it, a Design Sprint surfaces competing views rather than converging on them.

By the end of the day, the Red Bull team had a well-defined problem to take into the sprint, a shared prioritization of opportunities, and a clear sense of where user and business value overlapped.

The four-day Design Sprint

The sprint team was deliberately cross-functional — UX Designers, UX Engineers, Product Designers, Audience Marketing Managers, Programming Managers from Sports, Music, Culture, and E-sports, Digital Analysts, a Social Media Manager from Sports, Commissioning Editors from Bike, and Brand Managers. Breadth of perspective is one of the things that makes a Design Sprint produce decisions rather than just ideas.

Day 1 — Understand and Define. The team identified the most critical moment in the biking fan experience at live events — the specific point where a solution would have the greatest impact. This is the sprint's target: a concrete moment in a real user's experience, not a vague area of opportunity.

Day 2 — Sketch and Decide. Working individually first — a core principle of the Design Sprint, which separates idea generation from group influence — team members developed their own solutions. The group then reviewed and converged, merging the most promising directions into a single cohesive storyboard.

Day 3 — Prototype. The storyboard became a realistic, interactive prototype built in a single day. The goal isn't polish; it's fidelity — enough detail that a real user can interact with it as if it were the actual product.

Day 4 — Test. Five target users tested the prototype in structured interviews. The team observed their behavior, listened to their reactions, and captured direct feedback on what worked, what confused them, and what they'd actually use.

What the team left with

The testing session on Day 4 is where the sprint earns its value. Five conversations with real users, watching a realistic version of your idea in someone else's hands, surfaces a quality of feedback that no internal review can produce.

For Red Bull, the insights were specific and actionable. The team could distinguish between features users genuinely wanted and features that had seemed reasonable but failed the test of real use. They had a prioritized backlog of experiments for future work — not a long list of possibilities, but a ranked set of directions with user evidence behind them.

Most importantly, the team left with a clear direction for the Community platform. The ambiguity that existed at the start of the week — too many ideas, no structured way to decide — had been replaced by a shared understanding of what to build next, grounded in validated user insight.

The sprint also gave the team something harder to measure but equally valuable: a repeatable process. The approach they went through in that week — from customer research to problem framing to prototyping to user testing — is the same approach they can apply to the next decision, and the one after that. The week produced a platform direction. It also produced a method.

What this means if you're facing a similar decision

Red Bull's situation isn't unusual. Most digital product teams carry more ideas than bandwidth and face real pressure to move.

The instinct is to start building — to interpret momentum as progress.

The risk is that the first version of the product reflects the team's assumptions rather than the user's actual experience. And once something is built, the cost of changing direction is significantly higher than the cost of validating direction before you build.

A Problem Framing day followed by a Design Sprint is one week. The output is a tested prototype, a prioritized backlog, and a cross-functional team that has aligned on a direction through shared work rather than shared meetings.

That week doesn't guarantee the right answer. What it does is dramatically reduce the chance of the expensive wrong one.