PDF Summary:Click, by Jake Knapp

Spend a year building something nobody wants, and you’ll understand why Jake Knapp and John Zeratsky wrote Click. Knapp—who helped create Gmail and Google Meet and has guided over 300 startups—and Zeratsky—who’s been a design leader at YouTube, Google Ads, and Feedburner—argue that most new products fail not because they were built poorly, but because the strategy was wrong from the start and nobody questioned it.

The “Foundation Sprint” is their solution to this problem: a two-day method that turns your core assumptions about your customers, their problems, and what differentiates your product into a single, testable sentence. In this guide, we’ll walk through this framework and probe the questions it leaves open: why strategy so easily becomes identity, what distinguishes a real differentiator from a plausible one, and how much testing you actually need before you can build a new product with confidence.

(continued)...

Fitzpatrick’s solution is to stop asking people what they think of your idea and start asking what they actually do: What have they tried? What do they currently use to solve this problem? Have they gone looking for a better way? If they’ve noticed the problem but haven’t taken any steps to solve it, that’s a warning sign worth investigating before committing to a strategy. The right orientation to maintain during this process is one where you’re “seeking disappointment”: The questions worth asking are those designed to poke holes in your assumptions, not confirm them.

What’s Your Advantage?

The third step is to consider what makes your team uniquely suited to solve this problem. Knapp and Zeratsky explain that a team’s advantage has three components: capability (what you can do that few others can), insight (understanding of the problem or the people experiencing it), and motivation (the reason you care about solving it). The photo-sharing team has all three: mobile development experience (capability), firsthand knowledge of what it’s like to have family who miss out on small moments (insight), and frustration over watching memories disappear (motivation). A strong advantage combines all three, since no competitor can replicate your exact combination. This points you toward a solution only your team can build.

(Shortform note: Of the three components—capability, insight, and motivation—Peter Thiel’s Zero to One suggests that insight does the heaviest lifting. Thiel’s checklist for startup success touches on all three: whether a team has the technical ability to build something new, whether they’re unified by a compelling mission, and whether they have what he calls “unique insight”—knowing something important about a problem or a market that most people don’t yet believe. But he singles out insight as especially decisive because if the belief underlying your product is one that most people in your industry share, your competition will erode any advantage you have before it can compound into something durable.)

Who’s the Competition?

The fourth step is to establish an understanding of what customers are currently using to solve the problem. Knapp and Zeratsky note that this competition isn’t always another product, but can be a workaround or “doing nothing” about the problem. If no one is spending time or money on the problem, it may not be significant enough to push customers to try something new. For the photo-sharing team, the workaround most families use is a group text thread: It’s free, familiar, and already on every phone. Knapp and Zeratsky recommend identifying the strongest alternative and building a strategy around beating it, so the team should aim at group texts and think about what an app would have to offer to be worth downloading and learning.

The Customers Who Aren’t Buying Yet

Knapp and Zeratsky see the process of understanding your competition as an opportunity to take an honest look at what your customer is choosing between—including workarounds and even inaction—rather than narrowing your view to other products in the same category. In Blue Ocean Strategy, W. Chan Kim and Renée Mauborgne push this logic further: Where Knapp and Zeratsky treat “doing nothing” as a signal that a problem may not be significant enough to drive adoption, Kim and Mauborgne argue that the people who aren’t buying anything yet are often the customers most worth designing for.

They divide this group into three tiers: those who are unhappy with existing options and waiting for something better, those who’ve considered available alternatives and rejected them, and those who’ve never thought of the category as relevant to their situation at all. They contend that if you can figure out what’s holding back this last group of customers, you can create new demand instead of just competing for existing customers. This reframe also sharpens the idea to aim at the strongest competitor: The goal isn’t to beat that competitor on its own terms, but to find dimensions of value the competition hasn’t yet been measured on.

2. Craft Your Differentiation

With the basics established, you’ll turn to what Knapp and Zeratsky consider the most consequential question of the Foundation Sprint: What, specifically, will make your solution better than the competition in ways that customers actually care about? Differentiation is what gives customers a reason to choose your product over what they already use. Adopting anything new costs time, energy, and risk, and customers won’t pay that cost for something that’s only marginally better. Knapp and Zeratsky argue that successful products don’t just improve on the alternatives but reframe the category entirely, making competitors look inadequate by comparison.

(Shortform note: How much better is “significantly better?” In Zero to One, Peter Thiel contends that to get a customer to switch, an improvement needs to be an order of magnitude better—roughly 10 times superior on some dimension that matters. Anything less registers as incremental, not compelling. Geoffrey Moore adds a further wrinkle in Crossing the Chasm: The threshold isn’t the same for every customer. Early adopters will switch for something promising that offers a strategic edge, and they’re willing to accept unproven technology to get there first. Mainstream customers won’t move for product superiority alone; they also need proof that others have already adopted it and that industry support exists.)

To find the right differentiators, Knapp and Zeratsky suggest starting with the most common dimensions on which products compete—things like speed, simplicity, price, automation, or ease of integration—and plotting your solution against competitors on each, as honestly as possible. From there, you’ll often need to identify dimensions specific to your product that competitors haven’t been measured on before, ones that could change how customers think about what’s possible.

What Makes Differentiation Real

The Foundation Sprint gives you a method for generating differentiators, but not a test for evaluating whether the ones you’re considering are meaningful enough to be decisive. In Obviously Awesome, positioning expert April Dunford argues that a differentiator is real only if you can trace a complete chain from a concrete, verifiable feature to a specific benefit that resolves a customer problem. For Google Meet, “We’re simpler than the competition” fails this test, while “Our browser-based interface eliminates the need for software installation that keeps teams from joining a call” passes it.

The reason the chain must be complete connects to an observation Clayton Christensen makes in How Will You Measure Your Life? Customers don’t choose products based on general attributes, but to accomplish specific jobs. When a fast-food chain studied who was buying milkshakes early in the morning, it discovered those customers were looking for a portable, filling breakfast to enjoy on their commute. Understanding the job revealed the right differentiators, like the thickness of the shake and the width of the straw. The same logic applies to any differentiator: The question isn’t whether it sounds distinctive, but whether it connects to a job a specific customer is actually trying to get done.

Once you’ve identified your two strongest differentiators, map them on a 2x2 chart—one differentiator per axis—and plot your competitors honestly. The chart makes your advantage immediately visible. For our photo-sharing team, the differentiators might be how organized and lasting the experience is (compared to message threads) and how inclusive it is, reaching every family member rather than fragmenting across separate conversations. The goal is to place your product alone in the top-right quadrant, with competition in the other three. On a 2x2, group texts land in the lower half: inclusive, but chaotic. One-on-one texts are chaotic and fragmented. The photo-sharing app sits alone at the top right: organized and inclusive.

The final step in this stage is to translate those two differentiators into practical principles: short, specific statements that will guide your decisions throughout the project. Knapp and Zeratsky distinguish these from vague values statements, which are too general to decide anything, while something precise like “one tap, one moment” for our photo-sharing team is specific enough to immediately rule out any feature that adds friction to the posting process. Each of your two differentiators becomes one guiding principle.

Where You Stand Versus What You Do

The 2x2 grid and the practical principles solve different problems: The chart shows where you stand relative to the competition, and the principles translate that position into decisions that build and maintain it. The Dungeons & Dragons alignment system shows what makes such a chart work and why it can’t do everything. It classifies characters on two axes: one running from “lawful” (rule-following) through neutral to “chaotic” (rule-rejecting), the other from “good” to neutral to “evil,” creating nine possible moral/ethical alignments. The axes don’t predict one other: You can follow rules without being virtuous or vice versa (think about a disciplined villain and a morally driven outlaw). The same condition governs the 2x2.

But the alignment system’s history also reveals the gap between the 2x2 grid and practical principles. D&D’s creator eventually reconsidered it because players started announcing their alignments to each other. But a declaration of what you are, it turns out, is nearly useless for deciding what to do: An alignment only describes a disposition, and two characters with the same label could make opposite choices in the same situation without either being clearly wrong. Modern D&D has largely replaced alignment with commitments called Bonds, Flaws, and Ideals that name what a character values and owes to others. Knapp and Zeratsky’s principles make the same move: They tell you what to do, not just where you stand.

3. Choose an Approach

With differentiators in place, you can turn to a question your team has probably been circling since before the sprint began: What form should this product actually take? Knapp and Zeratsky argue that most teams answer this too quickly, committing to their first idea before seriously considering alternatives. Examining alternatives before you’ve built anything costs almost nothing, but pivoting after months of work is expensive. The authors advise generating at least three possible approaches and writing a brief summary of each, to resist the pull of the obvious first idea.

The photo-sharing team considers three approaches: a mobile app where parents post and family members view (their instinctive first choice), an email digest service that collects photos and delivers them to family members weekly without requiring an app, and a physical photo-book subscription that automatically compiles and mails monthly prints.

(Shortform note: There’s a name for the pull teams feel toward their first idea: In Decisive, Chip and Dan Heath call it “binary thinking,” explaining that we instinctively frame decisions as whether or not to pursue whatever option is already in mind. This cognitive shortcut stops the search for alternatives before it’s really begun. Knapp and Zeratsky’s advice to generate “at least three approaches” is a direct corrective, and research cited in Decisive puts a ceiling on it as well as a floor. The Heaths say that three to four distinct options is the sweet spot—enough to break the binary habit and ensure you have a fallback, but not so many that the team gets overwhelmed and starts making careless choices.)

To evaluate your options without defaulting to whoever argues most forcefully, Knapp and Zeratsky introduce a technique called “Magic Lenses.” Each lens represents a different perspective: for example, that of a customer evaluating whether the product actually solves their problem, that of a pragmatic engineer focused on what can be built quickly, that of a growth-minded marketer, or that of a financially focused evaluator.

For each lens, your team plots all your options on a 2x2 chart and assesses how each performs from that point of view. You can also create custom lenses for criteria specific to your situation—our photo-sharing team, for instance, might add a “grandparent-ready” lens, asking which approach a less tech-savvy family member could adopt without any help.

Working through multiple perspectives forces the team to see its options differently. The mobile app—our team’s first choice—performs well on the pragmatic lens, since the team already knows how to build it. But it struggles on the customer and grandparent-ready lenses, because recipients have to download and learn a new app. The email digest, which the team initially dismissed as too simple, lands in the upper-right because it solves the core problem (every family member gets the photos) without asking grandparents to change their behavior at all. This kind of counterintuitive result is exactly what Magic Lenses are meant to reveal.

Exploration Over Argument

In Six Thinking Hats, Edward de Bono set out to solve the same problem Knapp identifies with conventional group discussion: When everyone thinks out loud simultaneously, argument crowds out exploration, and the strongest personality—not the best idea—often wins. De Bono’s fix isn’t to separate strategic positions (as Magic Lenses do) but types of reasoning. Everyone tries out the same mode collaboratively, like putting on hats of a different color all at once.

De Bono identifies six modes: a blue hat for organizing the session itself; a white hat for gathering neutral facts without interpretation; a red hat for naming emotions without justification; a yellow hat for offering constructive proposals and reasons that something could work; a black hat for surfacing risks and failures; and a green hat—specifically shielded from the black hat—for generating new ideas. The core rule is that the whole team wears the same hat at the same time, so criticism, optimism, and creative generation don’t compete for the floor at the same time.

The black hat is worth pausing on here, because it asks one question above all others: Has this type of thing failed before, and if so, why? That is what the photo-sharing team’s first prototype was eventually forced to answer in testing, rather than earlier in discussion. An email that looks like a newsletter, arrives from an unfamiliar sender, and lands in a spam folder is a predictable failure—the kind a designated black hat session might have brought up before anyone built the first version. De Bono’s insight is that criticism and creativity interrupt each other. If you give each a dedicated turn, both can be more thorough.

After you’ve thoroughly evaluated all of your options, the team’s designated Decider selects a primary direction and a backup. With that choice in hand, you can complete the Founding Hypothesis, filling in the final slot—approach—alongside the customer, problem, competition, and differentiation. The completed Founding Hypothesis is now a testable statement of what you believe must be true for your product to succeed.

The Problem With Picking a Backup Plan

Having the Decider choose a Plan A and a Plan B sounds reasonable. But decision-making experts say the question we often ask when choosing a backup—”What do we do if Plan A doesn’t work?”—treats failure as a single event instead of acknowledging that Plan A can fail for many different reasons. To get ahead of this, psychologist Gary Klein recommends that before you implement Plan A, play out a scenario in which it’s failed and ask what caused that failure. (People’s accuracy in identifying such causes rises by about 30% when they treat the failure as given rather than hypothetical.) Those causes of failure help you design a Plan B that can succeed under the conditions that would sink Plan A.

However, researchers have discovered a complication with picking a Plan B before you’ve tried Plan A. Across multiple experiments, researchers found that study participants who’d been asked to think through a backup before attempting a task scored lower on that task than those who hadn’t formulated a backup. The gap held even when the backup required nothing: no time, no preparation, and no competing work. What changed was how much participants wanted to succeed at the primary task. In other words, having a backup lowers the stakes of Plan A. This doesn’t argue against having one; it argues for making it conditional enough that it doesn’t feel like a standing offer.

How to Test Your Founding Hypothesis

By the end of the Foundation Sprint, you should have a completed Founding Hypothesis—a statement like, “For parents of young children, our email digest service is better than group text threads because it’s organized and reaches every family member.” But a hypothesis is only as good as the evidence behind it. In this section, we explain why testing your hypothesis before development begins is essential, what kind of testing Knapp and Zeratsky recommend, and how to recognize when your solution is ready to build.

Remember That Your Hypothesis Is a Set of Guesses

Knapp and Zeratsky emphasize that even though it’s easy to lose sight of after two focused days of strategic work, every slot in your Founding Hypothesis is a prediction, and predictions can be wrong. For example, you might have identified the right customer but the wrong problem. The points of differentiation you chose might matter less to real customers than you expected. Your chosen approach might work in theory but fall short in practice. Until you test it, you don’t know which parts of your hypothesis are right.

The risk you incur by skipping the testing stage is significant. Teams that commit directly to development before putting their hypothesis in front of real customers typically spend a year or more before getting meaningful feedback on whether their assumptions were right. By the time problems come into focus, fixing them is expensive and disruptive.

The Double Cost of Committing Too Early

Knapp and Zeratsky frame the risk of skipping testing in terms of lost time. But other experts add that there are two more costs at play. The first is financial: The more you build on a bad foundation, the more you have to dismantle when you discover that you made the wrong assumptions. (For example, a wrong customer definition, carried unchallenged for six months of development, contaminates everything built on top of it.) An analysis of more than 400 VC-backed startups that shut down found that in 43% of cases, the underlying cause was that the product didn’t click: Teams kept investing in something too few customers wanted until the money ran out.

The second cost is less obvious than time or money. Psychology research finds that being involved in starting a project distorts how people evaluate whether it’s working, a dynamic they call “escalation of commitment.” Founding managers are much more likely to interpret feedback positively and to push for continued investment than observers who join the same effort later without that history of ownership. Just as the financial cost of a wrong assumption grows with every month of development, so does the psychological cost of seeing and correcting it. These two forces amplify each other: The more that’s been built, the more has to be undone, and the harder it becomes to admit that that’s what’s needed.

Test With Prototypes, Not Products

Instead of diving straight into development, Knapp and Zeratsky recommend a different approach: Run short, repeated cycles of building a simple prototype and testing it with customers before any major development begins. The key lies in the difference between a prototype and a minimum viable product (MVP). An MVP is a stripped-down but functional version of your product; building one typically takes months. A prototype is a realistic simulation of how your product might look and work that you can build in days. Customers can’t use a prototype to do work, but they can react to it, evaluate it, and form opinions about whether they’d want it—which, for the purpose of testing a hypothesis, is often enough.

Prototypes, MVPs, and the Spectrum Between

The authors draw a line between a prototype and an MVP, but not everyone draws that line in the same place. Eric Ries’s The Lean Startup includes several nonfunctional testing methods under the MVP umbrella that land in the same zone as Knapp’s prototypes: A “concierge MVP” replaces an automated system with a human who manually delivers the service, while a “Wizard of Oz MVP” lets users think they’re interacting with a working product while a person operates it behind the scenes. Dropbox tested initial demand with a video of software that barely existed and used waitlist signups as proof of concept. None of these put a functional product in customers’ hands, but Ries still calls them MVPs.

The more useful organizing concept might not be “prototype versus MVP” but fidelity: how closely your test version resembles the real thing. The right level of fidelity depends on what you need to learn. Knapp and Zeratsky’s prototype tests and Ries’s MVP cycles cover different points on the same spectrum. Low-fidelity tests are usually enough to answer whether customers want something at all, but for higher-stakes questions—if users will stick with a product after the novelty fades, or whether it integrates into a real workflow—you may need what Marty Cagan, in Inspired, calls a live-data prototype: a functional version that lets customers actually use and test the product.

The tool Knapp and Zeratsky recommend for running these experiments is the Design Sprint, a five-day process they introduced in their previous book, Sprint. In a Design Sprint, your team maps the problem on day one, sketches competing solutions on day two, chooses an approach on day three, builds a prototype on day four, and tests it with customers on day five. The whole cycle takes a week, and it can tell you more about whether your hypothesis is right than months of development would.

(Shortform note: The authors see the Design Sprint as the next step for a team with a clear hypothesis and the resources to put something in front of customers. But what if you’re not yet ready to prototype? In Working Backwards, Colin Bryar and Bill Carr report that Amazon has come up with an alternative. Before any Amazon team can begin developing a new product, they must write a hypothetical press release describing the finished product from the customer’s perspective, paired with a set of questions and answers about cost, feasibility, and challenges. The discipline of writing forces much of the same clarity that prototype testing later produces—if you can’t write a compelling press release, the idea probably isn’t ready to build yet.)

When you test your prototype with customers, Knapp and Zeratsky urge you to pay close attention to reactions instead of feedback. Feedback is what customers tell you—it can be polite, vague, or shaped by what they think you want to hear. Reactions are what you observe: a customer leaning in, asking unprompted whether they can sign up, or immediately grasping what the product does without explanation. These unguarded responses are the most reliable signal that your solution is starting to click—or that it isn’t yet.

(Shortform note: Watching behavior, not feedback, has a neurological basis. Verbal feedback doesn’t present a person’s immediate reaction but an edited version of it. The reaction that shows up in someone’s face and body is produced by a faster processing system than the one that generates spoken words. So by the time a person has decided what to say, their expressions and behavior have already signaled their immediate reaction. Their verbal feedback passes through the filter of display rules, the social training that shapes how much of their real feelings gets expressed. In a situation where the person asking clearly has a stake in the answer, this training pushes verbal responses toward encouragement instead of candor.)

Iterate Until It Clicks

Knapp and Zeratsky explain that a single prototype test is unlikely to tell you everything you need to know. Your first prototype will rarely click immediately, and that’s not a failure—it’s the process working as intended. Each sprint teaches you something specific: whether your differentiators resonate, whether your approach delivers on your promise, or whether you’ve correctly identified the problem. You adjust accordingly and run the next sprint.

Consider our photo-sharing team, who built a prototype of their email digest service and tested it with parents and grandparents. The first version failed in an unexpected way: Grandparents didn’t open the emails because they arrived with a generic subject line and unfamiliar sender, and often ended up in spam folders. The team’s hypothesis wasn’t wrong, but the prototype hadn’t delivered on it. So the team revised the emails to look personal, with a subject line reading “New photos from [parent’s name]” and space for a brief note. In the next round of testing, grandparents opened them immediately, recognized them as family photos, and responded with enthusiasm.

(Shortform note: There’s a potential trap in any iteration process: the post hoc explanation. The Latin phrase post hoc ergo propter hoc, “after this, therefore because of this,” describes the tendency to infer cause from sequence. It’s such a persistent problem that scientific experiments are designed around it: Change only one variable at a time, and decide in advance what result would confirm or disprove your hypothesis. Without that discipline, almost any outcome can be rationalized after the fact. In The Lean Startup, Eric Ries draws the same distinction, separating disciplined iteration, where you form a specific prediction before testing, from its undisciplined counterpart, where you construct a story after the fact to explain whatever happened.)

In practice, Knapp and Zeratsky find that most teams need two to three Design Sprints before a solution starts to click reliably. The ideal sequence is one Foundation Sprint to produce your Founding Hypothesis, followed by two to three Design Sprints to test and refine it. When customers consistently react the way you hope, you have the confidence to commit to development. At that point, you’re not just launching a product you hope will find a market—you’re building something you already know people want.

How Much Validation Is Enough?

Experts argue that the answer to “How many tests are enough?” depends on a prior question: How costly is it to build the wrong thing? For many digital products, starting development too early is recoverable—you can relaunch, reprice, or change direction—which can make two to three sprints a reasonable bar. But products where development is expensive or difficult to undo belong to a different tradition. Robert G. Cooper’s Stage-Gate framework—which has guided development in manufacturing and other high-stakes industries since the 1980s—doesn’t prescribe a testing session count, but requires evaluations against specific criteria for deciding whether to advance or terminate a project at each checkpoint.

The number of checkpoints in Cooper’s method are determined by what it would cost to discover a mistake after launch, rather than before. Jeff Bezos frames the underlying logic as the difference between “one-way doors”—choices that carry lasting consequences—and “two-way doors” that carry little penalty for being wrong. Bezos argues that applying a heavy decision-making process to reversible choices curtails experimentation unnecessarily. For teams building software products, committing to development is usually a two-way door. For those whose commitment is harder to reverse, the bar should shift from qualitative reactions toward the kind of documented evidence that makes a difficult decision defensible.