Autodesk Hannover — How Design Sprints and Problem Framing fix what Agile can’t

The problem Agile doesn’t solve

Agile is a delivery methodology. It is exceptionally good at what it’s designed to do: take a defined piece of work, break it into manageable chunks, execute it iteratively, and respond to feedback as it arrives. Teams that run Agile well ship consistently, adapt to change, and operate with a level of discipline and transparency that waterfall projects typically can't match.

But Agile has a dependency that often goes unexamined: it requires the input to be good. If the thing at the top of the backlog is a poorly defined idea, an assumption-laden requirement, or a solution that nobody has verified with a real customer, Agile will deliver it efficiently. The efficiency is real. So is the misdirection.

This is the gap that Autodesk's product team in Hannover was navigating in January 2020. They were running Agile well — and still ending up with products that didn't resonate, backlogs that had grown beyond what any team could meaningfully prioritize, and a recurring question: how do we know we're building the right thing before we commit to building it?

Why Autodesk's product context makes this question high-stakes

Autodesk builds design and manufacturing software used by architects, engineers, product designers, and manufacturers. Their customers are domain professionals with deep expertise and exacting standards. When a feature doesn't work the way a structural engineer expects it to, or when a product update disrupts a workflow that a manufacturing team has refined over years, the feedback is specific and the cost is real.

This is a different pressure from consumer software development, where poor feature decisions produce churn and low engagement. In professional tools, a wrong direction can erode trust with expert users who have built their entire practice on your platform. They don't switch easily — but they don't forgive easily either.

For Autodesk's Hannover team, the imperative to get product decisions right before committing development resources wasn't theoretical. It was the practical reality of building software for professionals who know exactly what they need and notice immediately when something falls short.

What Design Sprints and Problem Framing address — and where they sit in the process

In January 2020, Design Sprint Academy introduced the Autodesk team to Design Sprints and Problem Framing as the upstream layer their Agile process was missing.

The logic is precise. Problem Framing answers the question: what is the right problem to solve? It brings together product teams and stakeholders to surface assumptions, align on what the actual customer need is, and produce a problem statement specific enough to be acted on. Without this step, product ideas enter the backlog pre-loaded with assumptions that nobody has tested.

Design Sprints answer the next question: do real users actually want this? In a structured process, teams move from defined problem to tested prototype, getting direct customer feedback on desirability before any Agile sprint commits development capacity to building it.

Together, they create a validation gate that sits upstream of the Agile process rather than inside it. By the time a product idea reaches the backlog, it has been tested against a real problem definition and a real customer response. What enters the backlog is not an assumption — it's a direction with evidence behind it.

For product teams running Agile, this changes the nature of what the backlog is. Instead of a repository of ideas awaiting prioritization, it becomes a queue of validated directions awaiting execution. The distinction matters because it changes what prioritization means: instead of debating which untested idea to pursue, teams are deciding which validated direction to develop first.

The three problems the Autodesk team was trying to solve

Reducing wasted resources. The most direct cost of building the wrong thing is the development time spent building it. But the waste compounds: design work, testing, stakeholder communication, and project management all accumulate around a direction before anyone discovers it doesn't resonate. For Autodesk's professional user base, the cost also includes the relationship capital spent convincing expert customers to adopt something that turns out not to meet their needs. Problem Framing and Design Sprints move the discovery earlier, when the cost of changing direction is low, rather than later, when it's high.

Elevating customer satisfaction. Autodesk's customers are professionals who have highly specific expectations. Satisfying them requires understanding what they're actually trying to accomplish — not just what they say they want, and not just what the product team assumes they need. Problem Framing creates a structured process for developing that understanding before it's translated into a solution. Design Sprint testing puts a prototype in front of real users and produces specific, observable feedback that assumptions-based product development can't generate.

Gaining stakeholder buy-in. In large product organizations, stakeholder alignment is a persistent friction point. Different stakeholders hold different views about what the product should do, which customer needs are most important, and which direction is worth investing in. Those disagreements often surface as late-stage resistance — after development is underway, when the cost of changing direction is highest. Problem Framing brings stakeholders into the problem definition process before any solution work begins, so the direction that emerges has been shaped by — rather than presented to — the people who will need to support it.

How Design Sprints and Agile work together

The most common question from product teams considering Design Sprints is whether the method competes with Agile or complements it. The Autodesk case is a direct answer: the two processes operate at different stages and address different questions.

Agile is optimized for execution: taking a defined direction and delivering it well. Design Sprints are optimized for desirability testing: finding out whether real users actually want the solution before committing to executing it. They work sequentially, not in competition. A Design Sprint answers "do users want this?"; Agile answers "how do we build it well."

The practical flow looks like this: a potential product direction is identified. Before it enters the backlog, it goes through Problem Framing — aligning the team and stakeholders on the actual problem worth solving. Then a Design Sprint prototypes and tests a solution direction with real users. If the feedback validates the direction, it enters the Agile backlog as a tested, stakeholder-aligned item ready for development. If the feedback suggests a different direction, the course changes before any development capacity has been spent.

For Autodesk's Hannover team, this upstream validation layer addressed the root cause of the backlog bloat they were managing: ideas were entering the backlog faster than they could be evaluated, and without a structured validation step, the backlog grew with items whose viability nobody had tested. Adding Problem Framing and Design Sprints as a prerequisite for backlog entry created a natural filter — only directions with real customer evidence got through.

What changes when validation moves upstream

The most significant shift that Design Sprints and Problem Framing produce in an Agile environment isn't in the execution — it's in the conversations that happen before execution begins.

When a team knows that every product direction will be tested with real customers before it reaches the backlog, the quality of ideas submitted for consideration improves. The discipline of having to prototype and test something changes how ideas are formed. Teams think differently about what they're proposing when they know they'll have to make it tangible enough for a real customer to respond to.

Stakeholder conversations change too. When the question is no longer "should we build this?" but "here's what customers said when we put this in front of them," the basis for decision-making shifts from opinion to evidence. That shift doesn't eliminate disagreement, but it changes what disagreement looks like — from competing intuitions to competing interpretations of real data.

For a team building professional software for domain experts, the value of that shift is particularly high. Autodesk's customers can articulate their needs precisely and evaluate proposed solutions rigorously. A prototype tested with a structural engineer produces feedback at a level of specificity that internal discussion rarely achieves. The Design Sprint closes the gap between what the team thinks the customer needs and what the customer actually needs — before any code is written.