Two Days to a Founding Hypothesis: Inside the Foundation Sprint

Knapp traces the Foundation Sprint back to the Design Sprint. While at Google around 2007 to 2009, he worked on a three-year side project with colleagues in Stockholm whose office faced closure after the financial crisis. Polished pitches and ideal product requirement documents were not winning executive support, so he went there for a week, cleared calendars and built a prototype instead.

That prototype became Google Meet, a video conferencing tool that ran in the web browser. The experience led to a five-day recipe, refined over about five years at Google Ventures with a couple of hundred teams: map, sketch, decide, prototype and test, with one focal point each day. Knapp and Zeratsky later left to found Character Capital with Eli Blee-Goldman.

At their own firm they wanted to work on the earliest stage of company-building, which is where they felt they could have the most impact. With pre-seed, pre-product companies, design sprints kept running into the same unanswered questions: what problem are you solving, who is the ideal customer, who are your real competitors, and how are you different. That gap led them to create the Foundation Sprint around 2021 to 2022.

The pair recommend a slightly crazy idea: the core team, meaning co-founders or the product, engineering, design and marketing leads, clears the calendar for roughly 10 hours, ideally split into two blocks of four to six hours. Those hours follow a highly scripted sequence of activities. The result is a founding hypothesis, after which the team runs design sprints for two to three weeks or more so they have a chance to be wrong.

The three phases are the basics, differentiation and approach. In the basics, the team identifies the customer, the problem, the competition, and the alternatives and workarounds people use today. The questions sound almost embarrassingly simple, but when everyone proposes an answer the team discovers that perspectives differ widely.

Everything combines into a Mad Libs-style sentence: if we solve this problem for this customer with this approach, we think they will choose it over the competitors because of differentiator one and differentiator two. The pair call the sentence almost silly in its simplicity but powerful for the clarity it provides. Lenny Rachitsky sums it up as a way to supercharge validating an idea.

To illustrate, they use Latchet, a startup from their Character Labs program, founded by two engineers who previously led growth at Substack. They wanted to help artisans such as jewelers, painters and woodworkers sell beyond their local community, using network techniques like Substack's recommendations. Shopify requires you to do your own marketing, and Etsy has become commoditized, so identity is hard to build there.

Zeratsky notes the founders were builders who were excited but nervous about being asked not to write code right away. The first step uses work alone together: everyone silently writes answers to a question such as who the most important customer is, the team votes, and a designated decider, usually the CEO, picks one. The resulting one-page sheet named artisans who find tech and marketing hard as the customer, sales growth as the problem, Shopify and Etsy among the competitors, and Substack network-growth experience as an advantage.

Asked where teams are most surprised, the pair say the moment of value comes when people look up from their notes and see that others wrote something different. Problem definitions are often less clear than expected, and competition prompts an aha when teams realize that a customer's workaround counts as an alternative. Advantages matter later because startups cannot beat big companies on scale or distribution, so they must find what only they can do.

The pair say the basics boot up the right context in everyone's head for the main event of day one. People ignore new products by default, they argue, so a product needs a clear promise that is radically different from the alternatives and that it actually delivers. That promise should be about what the customer gets, not what is special about the technology or the market opportunity pitched to investors.

The team starts with classic differentiators, such as fast versus slow, smart versus not so smart, easy versus hard, free versus expensive, focused versus one size fits all, simple versus complicated, and integrated versus siloed. Then they write custom ones, scoring themselves honestly against competitors. For Latchet, ideas included networked versus siloed and painless versus labor-intensive growth.

The output is a two-by-two diagram in which your product sits in the top right and every competitor falls into the L-shaped zone they call Loserville. Both conditions must hold: you can deliver on the promise, and customers care and believe it. They argue that ordinary two-by-twos feel like consultant baloney because one person makes them for investors without evidence, whereas here the whole team weighs in and later tests the claim.

Rachitsky points to earlier guests such as naming expert David Placek and positioning expert April Dunford as further evidence that differentiation matters. The pair say founders and people at AI labs, where they were invited to speak, react strongly to the idea, while others find it elementary. The problem, they say, is that differentiation gets backgrounded: teams build technology and then paint a marketing page over it at the end.

On price, they say it is rarely the most important differentiator because it is hard to beat large companies that can underprice. Exceptions are products using AI on problems previously unsolvable by software. They cite their portfolio company BindWell, which uses AI to design precision pesticides without a large team of lab chemists. Rachitsky adds that AI coding tools compete on saving expensive engineering time, and the pair mention a rule of thumb of roughly 10x cheaper than the legacy manual approach.

Looking at the startup Mellow's scores, they point out that a team will not be the best on every scale, and that is normal. Driving home one or two things customers care about, and being radically better at them, improves the odds of finding product-market fit. Mellow, which builds simple, focused AI agents for tasks like summarizing email or cleaning up a calendar, ended up differentiating on being mobile first and working out of the box.

The first day closes with project principles that guide decisions in line with the differentiator. Knapp recalls the list at Google called Ten Things We've Found To Be True, whose line that fast is better than slow was used in meetings to settle trade-offs such as an approach that rendered 12 milliseconds faster. Latchet's principle was to help sellers help each other, and the chart plus principles form a one-page mini manifesto they call a decision-making guide.

Day two locks in the approach. Latchet had four paths in mind: an app, a newsletter platform, a Shopify plugin, or a full stack. All solve the same problem for the same customer, like different routes in Google Maps to the same destination. The team plots options on magic lenses, imagining a team of advisors who each pound the table for the customer, for pragmatism, for growth, for money, and for differentiation, plus custom lenses such as founder conviction.

They explain that the plotted lenses either show one option winning in most lenses or show that nothing wins everywhere, which is reassuring in its own way, because then the team picks the most important lens. Teams also name a backup plan so that pivoting after early experiments feels less scary. Rachitsky notes this step answers the common question of why not just build and learn, since an hour or two of comparison can save weeks or months.

The pair say building has momentum of its own, especially with AI tools that make progress easy to see, but progress in the wrong direction hurts. They compare it to a fellowship choosing the right path to Mordor before marching through the swamps. They also observe that teams building quickly with AI tend to produce more generic products, because models are largely pre-trained on the same data.

Launching early also gives skewed data: you learn what people who found your product did, but nothing about what they did not do, and nothing about visitors who bounced as soon as they saw another generic AI-made page. The recommendation is to slow down for deep thinking about what makes the product unique and then switch to going as fast as possible. Rachitsky relates guest Bob Baxley's advice to delay sketching because everything afterwards becomes a response to the first drawing.

Zeratsky and Knapp say the Foundation Sprint keeps teams away from ideation for a little longer, and that the design sprint idea was often boiled down to just building a prototype when in fact the prototype only happens on day four. They argue that the pattern across a few hundred companies does not match the narrative that you should create the product as fast as possible. They also see it as a tool for product managers, almost a product requirements document for a company.

Rachitsky asks about Base44's founder Maor, who built a product for his own problem and sold it within six months for $80 million without a process like this. The pair reply that many bright, capable founders fail, and that stories of success suffer from selection bias. Their view is that the process increases the odds that a product clicks with customers, and that a founder with real traction should simply keep going, as one lab founder did when he stopped running experiments.

To answer skeptics who want proof, they admit the method is only about three years old. When creating it, they looked back across projects they had been involved in and found that the successful ones had clear differentiation, even without the Foundation Sprint. Knapp shows a chart of companies spanning Google, Google Ventures and Character Capital, and says all the biggest hits shared that common element.

They give examples: Gmail's promise of massive storage and great search against Hotmail and Yahoo, Slack's pitch of fun and teamwork when switching cost a whole team, ChatGPT's no-click answers against search, and Reclaim using AI to prioritize calendars, a company Dropbox acquired last year. They say they want founders to have that same clarity. Their special sauce, they add, is a focus on the sequence of decisions and how teams make good ones quickly.

Latchet's founding hypothesis was that if they help artisans solve online sales growth with a social sales app, with a full-stack solution as the backup, artisans would choose it over Shopify and Etsy because it is cooperative and easy to use. The pair stress that every new product has a founding hypothesis, but it is usually implicit and different people hold different versions, so it cannot be tested. Making it explicit allows each variable to be examined.

Each design sprint starts with the hypothesis, identifies the biggest risk, and maps how customers discover the product to find the key moment. For Latchet the risk was whether artisans would want a community sales platform at all, so the moment to test was a landing page. They prototyped three versions head to head with fake brands. A new scorecard then breaks down whether this was the right customer, whether they had the problem, whether they chose the approach over competitors, and whether the differentiation worked.

Latchet's first scorecard after four customer interviews was mostly red, though the customer and problem looked right. By the third week, they say, everything was green, which they call an extreme but real example of a recurring pattern. Founders say the process compresses three or four months of work into three or four weeks, and one lab founder said that after 50 conversations the first one with a prototype taught him more than the rest.

To show a more technical case, they walk through Axion Orbital, run solo by a founder aiming to help geospatial developers with a browser-based no-code environment. His first prototype was a bare-bones marketing page and a rudimentary demo video, focused on messaging and finding people in that role. In week two he used AI tools and real coding, guided by pencil sketches, to produce a far more realistic page and a product video, so the product did not have to be fully functional.

AI's biggest use in sprints so far, they say, is making realistic prototypes quickly, like having a prototyping team on standby. They stress not to skip the thinking about what the copy says and how the product differs. Teams in the current cohort that jumped straight to vibe coding found their prototypes generic, because the models were trained on existing products, and had to step back in the second sprint.

Knapp describes detailed paper sketches as a form of prompt engineering: a clear plan up front is likelier to yield an opinionated product than co-designing in a chat with an LLM. Rachitsky ties it back to the primal-mark idea, that everything after the first prototype becomes a response to it. The pair also point out which parts can be real, vibe coded or static mockups, since the goal is a convincing simulation for customers.

Zeratsky says they have a Miro template for running a Foundation Sprint, the same one they use with founders, which they will make available at character.vc. Rachitsky points out that the template makes it plug and play alongside the book *Click*. They also invite founders to apply to Character Labs through the same site.

Knapp closes by acknowledging that clearing the calendar is a lot to ask, but he believes beginnings are essential. A side benefit, he says, may matter most: it brings you close to the customers you are building for, since you interact with them weekly. It also brings teammates together in an authentic way, without the usual social dynamics of one person pitching an idea or constant context-switching.

They say the structure takes care of much of the difficulty of deciding what to do, so people come out with renewed energy and motivation about working on what matters. Rachitsky jokes that it is like a yoga class for startups: you do not know the poses, and someone simply walks you through step by step. He skips the lightning round because the conversation ran long.