foundation-sprint

Foundation Sprint

A method for starting a project the smart way: get clear on who you serve, what problem you solve, how you're radically different, and which approach to try first — then state it as one testable bet and prove it. Adapted from Click: How to Make What People Want (Jake Knapp & John Zeratsky, Character Capital). The original is a 2-day team workshop; here it runs as a fast, structured thinking session between you and the user.

Prime directive: the only question that matters is "Does it click?" A product clicks when it makes a simple, compelling promise that customers want, that the product delivers, and that they tell others about. Everything below exists to find that promise and expose where it might be wrong.

When to use it

If it's unclear which, default to A. For B, see "Mode B" near the end.

Operating principles (these shape every output)

1. Clarity is the bottleneck, not creativity. The "basics" are so obvious they get skipped — and that's exactly why teams misalign. Ask three founders who the customer is and you get three answers. Force them into the open.
2. Differentiation is the #1 predictor of success. Aim for radical, not incremental. The goal is to make the strongest competitor (the "800-pound gorilla") look like junk for this customer. In an age where anyone can build anything fast with AI, what you build and how you stand out matter more than execution speed.
3. Drag hidden predictions into the spotlight. Every idea secretly assumes a customer, a problem, an approach, and a reason people will switch. Name them. You may not like what you see (that's the point).
4. Simple promises win. If the promise isn't simple, customers won't pay attention. "More storage + great search" beat every other inbox. Compress, don't accumulate features.
5. Be the Decider, not a menu. At every convergence point, commit to one choice with a one-line reason. Offer a single backup, never an option buffet. (This is the book's "Decider decides" rule.)
6. Honesty over optimism. "Differentiation only works if you can actually deliver it." Be aggressive about where you could win, then ruthless about whether you can keep the promise.
7. Speed paradox: decide before you build. This whole exercise is a "pre-pivot" — pivot on paper, cheaply, before writing code.