Breaking the Cycle of Agile Insanity Validating Solutions with Design Sprints

Stop investing months of engineering time into solutions that customers may not want. In just four days, discover what works, what does not, and what is worth building.

Amaia Lesta

12/3/20255 min read

(Video version of this post in our channel https://youtu.be/ibb8uVq1PTs)

Tech teams work hard. They ship sprint after sprint, they refine backlogs, they plan, deliver and fix issues under constant pressure. Yet so many organisations still face the same problem: after months of development, the thing they release does not fully land with customers.

The team has worked with great intentions. The delivery process was “Agile”. The conversations with customers happened. The research looked reasonable. Still, the reality arrives too late: users do not value what was built. Confidence drops. Priorities shift. Roadmaps are rewritten. Teams lose momentum.

This is not a failure of talent. It is a failure of process.

Why so many Agile teams are still at risk

Agile helps build solutions iteratively, although teams often start with very limited certainty. They rush into sprints without validating properly the core user problem, without testing the concept with real users and without alignment across product, engineering, marketing and leadership.

The result is predictable:

  • Late and conflicting customer feedback

  • Endless debate and unclear direction

  • Complex features that do not solve the right problem

  • Roadmaps that move in response to the loudest stakeholder

  • Resource waste in the most expensive part of the process: engineering

Talking to customers is essential. Although talking to customers without structure often reinforces biases, captures what people say rather than what they actually do and creates false confidence.

What is missing is a structured method that challenges assumptions early, tests ideas with real users and creates alignment across functions before any code is written.

Enter the Design Sprint

A Design Sprint is a four-day structured process created at Google Ventures to help organisations solve big challenges, test ideas rapidly and avoid wasting months building the wrong thing.

It answers four critical questions before the first Agile sprint even begins:

  • Are we solving the right problem?

  • Will users actually want this solution?

  • What is the minimum version worth building?

  • Do we have real alignment across functions?

It works because using proven design thinking and facilitation methodologies it compresses what usually takes weeks or months into a focused, collaborative and evidence-based process that ends with real user feedback.

What actually happens in a Design Sprint?

Over four days, a small, cross-functional team works together to:

  • Day 1 – Understand and ideate

Clarify the challenge, map the user journey, identify risks and define what success looks like. Generate multiple solutions.

  • Day 2 – Decide & Plan A Prototype

Evaluate solutions, and select the strongest direction to prototype and plan the prototype.

  • Day 3 – Prototype

Build a realistic prototype in one day.

  • Day 4 – Test with real users

Interview five real users, observe reactions and gather evidence on what works and what does not.

The result is a validated (or invalidated) solution, clear insights and a confident next step: iterate, refine or stop.

Why this matters for agile organisations

Many teams hear “Design Sprint” and assume it is an alternative to Agile, although in reality it is one of Agile’s strongest complements. The method was originally created in 2010 by Google Ventures as a five-day process to validate ideas before writing a single line of code. As the methodology has evolved and AI-enabled tools have accelerated prototyping, a full sprint can now be completed in four days without losing depth.

This makes it an ideal precursor to Agile delivery, being the missing strategic complement to Agile rather than a replacement for it. Agile is excellent at delivering solutions iteratively once the problem and direction are clear. The challenge is that many teams enter Agile delivery with assumptions, unclear requirements, or competing stakeholder opinions that create confusion, rework, and delays.

A Design Sprint runs before the first agile sprint, tests assumptions with real users, and allows teams to decide which ideas genuinely deserve a place in the backlog. It gives Agile teams clarity on what to build, while Agile provides the engine to build it well. Agile teams iterate on something already validated instead of guessing, reducing waste and accelerating delivery.

Design Sprints solve the biggest delivery risks you see every day in many agile delivery organisations:

  • They reduce development waste and risks: Teams validate ideas before touching code, which means engineers invest effort only where there is evidence.

  • They accelerate innovation: Decision-making that normally takes months happens in days.

  • They create alignment instantly: Bringing product, engineering, design, marketing and commercial perspectives together eliminates misunderstandings.

  • They put the customer at the centre: Teams stop guessing what users need and start observing real behaviour.

  • They prepare teams for successful Agile delivery: When a Design Sprint happens first, the Agile process becomes clearer, more focused and more predictable.

Examples Across Industries

Design Sprints are used wherever organisations need clarity fast, regardless of sector or product.

Tech companies use them to validate new features before investing engineering time. At Uber, teams sprinted to redesign the driver experience, creating safer and more intuitive flows that increased driver satisfaction. At the UK Home Office, a sprint transformed a complex visa-selection journey into a clearer, more accessible service for thousands of users. Netflix: improved declining subscriber engagement by adding new functionalities in their landing page to presente relevant content to users. Slack: validated a marketing strategy to grow outside tech companies when active users stopped growing.

Hardware and physical product teams use Design Sprints to explore behaviour, usability and customer expectations without building expensive prototypes. Savioke, a robot manufacturer, validated how service robots should behave in hotels so guests would trust and enjoy using them. 3M used sprints to imagine the future of Post-it® products, bridging analogue and digital workflows and inspiring award-winning apps.

Highly regulated industries benefit as well. In pharma, Johnson & Johnson research teams design-sprinted at early stages of research, identifying risks much earlier than with traditional proceses. And healthcare teams used design sprint to understand patient barriers and design solutions that improved access to pain treatment. Other research teams use sprints to accelerate early insight, reduce risk and clarify the real problem before investing in long, costly programmes of work.

The common pattern is simple: teams facing uncertainty use a Design Sprint to reveal what users actually need, test a real prototype quickly and gain clear direction before committing time, budget and people.

Is a Design Sprint right for your organisation?

Consider a Design Sprint if:

  • You are about to invest significant resources in a new idea

  • You want clear evidence from real users before committing

  • Stakeholders disagree on direction

  • Priorities shift frequently and alignment is difficult

  • You need fast insight rather than months of debate

  • You want your Agile teams to start with a validated foundation

If you recognise your situation in these statements, a Design Sprint will dramatically reduce risk and improve confidence.

Start small and scale

You do not need a huge transformation. Most organisations begin with:

  1. One carefully chosen challenge

  2. One Design Sprint with a small, committed team

  3. A clear set of insights that guide product and engineering

  4. Then, once the value is visible, they scale the practice

This is how innovation becomes predictable, intentional and aligned with real user needs.

Your next step

If you are facing a large challenge, exploring new market opportunities or simply want to improve the way your teams make decisions, a conversation is the best place to start. I can help you decide whether a Design Sprint fits your situation and how to tailor it to your organisation.