Anthropic says slow down. Are you listening?

May 22, 2026
John Vetan

Claude Founder Playbook names four questions every team should answer before building anything with AI. This article takes those four questions and explains what answering them requires once the decision lives inside a large organization rather than in one founder's head.

If you own an AI mandate, you'll leave knowing which two methods answer Anthropic's four questions for a cross-functional team — and which question your current process is in fact skipping.

Anthropic published The Founder's Playbook: Building an AI-Native Startup last week.

Its core argument is not something you'd expect from an AI company. Because it's not about the technology or AI. Here is the short version:

You still have to validate before you build, you still have to talk to real people, and the hard work of understanding the problem doesn't disappear just because building has become fast and cheap.

In this article I want to explore what that means in practice, and why it's worth paying attention to regardless of whether you're a founder or leading AI inside a large organization.

First, pay attention to Anthropic's stark warning. AI failure rates will only climb in the future.

"Even before the current era of agentic coding, 42% of startups failed because they built something nobody wanted. Now, though, agentic coding solutions like Claude Code have drastically collapsed the distance between 'I have an idea' and 'I have a product' — and that failure rate is only going to climb."

And it makes sense. When building is frictionless, the temptation to skip validation becomes almost irresistible. Why spend weeks talking to customers and pressure-testing assumptions when you can have a working prototype with a few prompts? But that prototype doesn't tell you if you're solving the right problem. It just tells you that you can build.

Enterprises are not immune to this. They just do it at a different scale. Instead of one founder building the wrong product, you get a dozen (hundreds?!) AI pilots running in parallel — each one well-resourced, technically impressive, and disconnected from a real problem anyone agreed was worth solving. The waste isn't just money. It's the six months of misaligned effort, the stakeholder fatigue, and the growing suspicion that AI isn't actually delivering anything.

The four questions that matter before you build anything

Anthropic's playbook identifies four questions every team must answer before committing to build:

Is the problem real and specific?
Who exactly has it — and is that a market?
Does your solution address the actual problem?
Do you have enough signal to justify building?

They are the difference between building something people use and building something that gets shelved after the demo.

There is a temptation to get these answers from AI. Anthropic advises against it.

"Ask an AI tool for evidence supporting what you already believe, and it will find it. Confirmation bias now comes with a research engine."

The answers need to come from the people closest to the problem.

For a solo founder, this is a single-player game. One person holds the full context, does the customer discovery, pressure-tests the idea with Claude, and makes the call. The playbook shows exactly how to do this — and it's worth reading if you're building something individually.

Enterprise teams are playing a different game. They are in multiplayer mode. AI can sharpen one person's thinking. It does not get five people to agree on what problem is worth solving.

The enterprise environment is fundamentally different

When a large organization decides to build something with AI, the decision rarely sits with one person. A typical AI initiative involves a business owner who identified the opportunity, a VP or SVP who controls the budget and has their own view on what matters, an IT or data team with strong opinions on feasibility, a legal and compliance function that needs to assess risk before anything moves forward, and the operational teams closest to the actual work — the people who know where the process breaks and why. Each of these stakeholders brings a different frame, different priorities, and often a different definition of what the problem actually is.

Before a single line of code gets written, all of these people need to look at the same evidence, have the same conversation, and reach a shared decision about what is worth building and why. It is a people problem, not a technology problem. And it is the part that most AI initiatives underestimate — or skip entirely in the rush to show progress.

The result is what you see in so many organizations right now: AI pilots that generate impressive demos but stall at deployment, because the people who need to adopt the solution were never part of the decision to build it.

And in the background, that cost compounds silently — because nobody is calculating what it costs to keep solving the wrong problem.

The methods that answer the questions

At Design Sprint Academy, we have worked in this environment for over ten years — helping product, innovation, and AI teams answer the same questions the playbook advocates for.

Our methods were built specifically for this: getting the right people into the same room, working the same problem, and reaching a decision that holds.

The first two questions — whether the problem is real and who has it — are the domain of AI Problem Framing. It is a structured one-day session that brings together the cross-functional group: business owners, technical leads, operational experts, and the decision-maker who will be accountable for the outcome. Together they work through real customer and business data, challenge assumptions, and narrow a broad AI mandate down to a specific, prioritized use case that the team agrees is worth pursuing.

The last two questions — whether the solution works and whether there is enough signal to build — are answered through the AI Workflow Sprint. Over four days, the team maps the workflow in detail, designs an AI-powered solution, builds a working prototype, and tests it with five real users. By the end, the evidence either supports moving forward or it doesn't. Both outcomes are valuable, because both save the organization from committing to the wrong path.

Anthropic recommends putting a prototype in front of five users before committing to build. That's exactly what the AI Workflow Sprint does — and it's not a coincidence. It's what rigorous validation looks like in practice, whether you're a founder working alone or a team of twenty. Some things never change.

Book a 30-minute call with me to walk through how to validate both the problem and the solution in an enterprise environment — with the multiple stakeholders who need to align before anything gets built.

Book a call →

FAQs

We're under pressure to show AI progress. Won't a discovery process slow us down?

It feels slower for a week and is faster for a year. The expensive delay isn't a structured session — it's the six months spent building a pilot nobody adopts, then starting over. Discovery front-loads the disagreement so it surfaces before engineering commits, not after.

We already run AI workshops. How is this different?

Two things. First, who is in the room. Most AI workshops are run by and for the AI engineers — the people building it. A real discovery session needs the cross-functional group: the business owner, the budget holder, legal or risk, and the operational people who know where the work actually breaks. The engineers can build anything; the question is whether the rest of the organization agrees it is worth building.

Second, what the method does once they are in the room. Someone usually can see the flaw in the plan — but the senior voice has set the direction, and disagreeing with a peer in front of leadership carries a cost, so the hard question goes unasked. The method's job is to force that challenge into the open, early, while it can still change the decision. A workshop that ends in polite agreement skipped the most valuable part.

What if we run discovery and the answer is "don't build it"?

That is a result, not a failure. A clear no early saves the engineering budget, the team's time, and the credibility hit of a pilot that quietly dies. "We stopped this before it cost us a quarter" is something you can take to the board as proof the process works.

We've already started building. Is it too late for discovery?

No, but the question changes. Instead of "should we build this," it becomes "is what we're building still solving the real problem." That is worth asking before more engineering goes in — a half-built pilot is a cheaper place to stop than a deployed one.

We hired an AI team — or consultants — for this. Why didn't that solve it?

Technical teams answer whether something can be built. Consultants often deliver a roadmap and leave. Neither closes the gap this article describes: getting the people who have to live with the decision to agree on the problem first. That is a coordination problem, and it needs a method that runs inside your organization, not a deliverable handed to it.