Avoiding Pitfalls: Making Foundation Sprints Work in Large Organizations

About the Foundation Sprint

Jake Knapp and John Zeratsky, authors of the best-selling book Sprint, have just launched their latest book Click. The topic will surely capture the interest and attention of anyone who’s working in product and innovation. It’s about getting the fundamentals right and something people want.

Just like the book Sprint introduced to the world the design sprints, as a method to solve big problems and validate ideas, Click introduces the Foundation Sprint - a two day workshop,  to help teams get clarity on their customers, their value proposition , and how to differentiate their approach to build winning products … that click.

Spoiler alert, the book is brilliantly written and it makes a lot of sense. The method, Foundation Sprint, shines in its simplicity — much like the design sprints. But don’t be fooled: that simplicity is deceptive. Mastering and applying  this method requires deep thought, expertise, and hard work.

I believe product and innovation teams, along with consultants, will be eager to adopt it. Many will come from large organizations and when they will try to apply it many will also fail. Why? Because, just as with design sprints, they’ll miss what’s said between the lines.

That’s exactly what this article is about: helping those who want to try the Foundation Sprint get it right. At Design Sprint Academy, we’ve created a free Miro template to help you get started—already downloaded by hundreds of people.

But before you jump in, here’s what you should consider—especially if you’re applying it in an enterprise setting.

Context is critical before a Foundation Sprint

The Foundation Sprint may look like a problem-definition exercise, but it’s actually firmly rooted in the solution space. If you’re hoping to use it in a large organization to explore a fuzzy, complex problem space, it’s likely to fall short.

Here’s why: The Foundation Sprint starts by identifying two basics—who your customer is and what problem you want to solve for them. The team brainstorms options individually, votes silently, and briefly discusses them before the Decider (the senior stakeholder or decision-maker) chooses a focus. Simple, right? If it were, every organization would always solve the right problems for the right audience.

But at Design Sprint Academy, after a decade of helping teams frame problems, we know it’s rarely that simple—especially in large enterprises.

In large organizations, customer personas multiply, and every problem has ripple effects across operations and internal stakeholders. Without context, asking “Who is the customer?” and “What is the problem?” produces scattered answers on a wide-spectrum, making decisions murky and alignment superficial. It will be hard for the team to focus and for the Decider to choose with confidence.

Let’s see an example. I recently worked with a $20 billion construction company launching their first AI product. Their starting point: “We need to use AI”—broad and directionless.

The leadership could see AI applications in sales, construction, engineering, safety, training, all impacting customers, vendors, partners and employees at every level. At that scale just asking “Who is the customer?” and “What is the problem?” was futile without context. To narrow their focus, we ran two workshops: AI Opportunity Mapping for strategic direction and a Problem Framing Workshop to surface real opportunities. Only then was a Foundation Sprint viable.

Sure, the team can still decide—perhaps even align—but in most cases, it’s a guess. An assumption, not a conviction. The book encourages “Get started, not perfect” mindset—a principle I partially agree with. In large enterprises, wasted time and resources on projects that go nowhere is all too common.

But still—two full days of people’s time should be worth it. The project should matter. The problem should feel real. Context is key: you need data, insights, and focus to drive decisions.

And there is another aspect. The book assumes that founders are the research, which for startups might be true (not always though). But in enterprises, skipping research is a serious risk—teams may waste time exploring assumptions that contradict existing data or customer insights. Without research, the sprint can quickly derail into guesswork, undermining trust in outcomes. Enterprises should leverage existing research teams, customer data, and insights to ensure the sprint is anchored in reality.

And here’s the catch—the book’s case studies all had that context. That’s the 'between the lines' insight: the book was written from a startup perspective.  Founders live and breathe their market. They have the context—they’re solving a problem they already understand.

In enterprises, that’s rarely the case. Context-setting is critical because people are juggling multiple projects with fragmented, sometimes conflicting, priorities. That’s why, before a Foundation Sprint, there should be a proper onboarding session—or better yet, a Problem Framing workshop—to create clarity and focus from the start.

Starting Point: Problem or Solution?

The Foundation Sprint can start from either a well-defined problem space—helping prioritize opportunities—or from a solution concept—guiding the team to break down assumptions into testable approaches.

Either path works, but I believe the method shines brightest when starting from a solution. Why? Because starting with a solution is where teams most often get stuck. Ideally, we'd all begin with a problem-first approach, but let’s face it—that’s not how it usually happens.

Starting with a solution isn’t a flaw—it’s a reality. And the Foundation Sprint is built to challenge that solution and create differentiators from the competition. By the end of the sprint, you’ll have a hypothesis on a better approach—one that leverages your team’s unique advantages.

So which path should you take?

• Start problem-led if your team needs to explore opportunities, clarify customer needs, or evaluate where to place bets. But make sure the problem space is ‘somewhat’ defined and supported by insights.
• Start solution-led if you already have a concept and need to refine it or test its desirability.

Either starting point is valid. But whatever you choose, make sure it’s an important project—one that has the potential to create meaningful impact. The sprint is a commitment, and it should be worth the time invested.

Team Trouble: Who’s in the Room Defines Success

Jake Knapp and John Zeratsky recommend a senior team of up to five people including the Decider—CEO, head of engineering, head of sales, head of product and the head of marketing. Their competing perspectives are meant to spark better decisions.

But while this setup works well for startups, it rarely translates in large organizations. Good luck getting those leaders in a room for two days. And even if you do, alignment alone won’t guarantee success if the team lacks firsthand customer insights.

Imagine a Foundation Sprint with only senior leaders—heads of departments—who miss critical customer pain points due to their distance from day-to-day operations.

They’ll  debate strategy, but their distance from day-to-day customer pain points reduces the sprint to guesswork. Frustration follows and they’ll see the process as a waste of time.

If you do manage to get them in the room, set them up for success. Provide essential context and customer insights upfront. Without it, they’ll struggle to make informed decisions.

On the flip side, a team made up only of doers—product managers, designers, and engineers—risks missing the bigger picture. Without strategic direction or decision-making power, their two-day sprint becomes a tactical exercise without teeth.

The solution? Strike a balance: Combine a Decider for strategic direction with hands-on experts who understand customer needs and can propose approaches. Since the Foundation Sprint is solution-focused, subject matter experts are critical to ensure realistic, impactful approaches.

Without this mix, you risk one of two extremes: a disconnected strategy or a tactical plan with no strategic backing.

The Foundation Sprint is the beginning, not the end.

The Foundation Sprint delivers a founding hypothesis—a direction, not a solution. It’s about creating an approach you can test immediately, not a perfect plan.

Getting buy-in for a Foundation Sprint isn’t enough. If teams stop here without validating their ideas, they risk pursuing untested assumptions, which can lead to costly missteps.

Enterprises must plan for follow-up experimentation. Since Foundation Sprints tackle big projects, experimentation means more than simple A/B tests. When validating risky yet potentially disrupting solutions the best next step is a Design Sprint — where assumptions meet the real world.

So, when planning a Foundation Sprint, plan for a follow-up Design Sprint—or even multiple rounds—to refine and validate your direction, until you land on a solution that truly clicks.

Comparison: Foundation Sprint vs. Design Sprint

The two sprints complement each other: the Foundation Sprint sets the strategic direction, while the Design Sprint validates it with real users. Enterprises should see the Foundation Sprint as a launchpad for experimentation—not the finish line.

Final Thought

The Foundation Sprint is a powerful tool, but its real impact comes when paired with proper context setting, a balanced team, and follow-up experimentation.

If you’re new to this method, join our upcoming webinar. We’ll break down how to apply it effectively in your organization and share real-world insights.

Want to get started right away? Explore our free Miro template, already downloaded by hundreds of teams to try their first Foundation Sprint. If you’re ready to dive deeper, reach out for additional resources or to discuss how Foundation Sprints can fit into your process.

Ready to try it? Get started with our free Miro template—and let your sprint click.

‍