Un Foundation Sprint es un taller de dos días para convertir las intuiciones de un equipo en una estrategia explícita: cliente, problema, ventaja, competencia, diferenciación y enfoque. Su resultado es una Founding Hypothesis —una hipótesis fundacional— que puede someterse a pruebas antes de comprometer meses de diseño y desarrollo.
Eso es lo que propone Click: How to Make What People Want, de Jake Knapp y John Zeratsky. Pero conviene comenzar con una precisión que el entusiasmo por los workshops suele borrar:
El Foundation Sprint no demuestra que la gente quiera un producto. Demuestra que el equipo ha sido capaz de expresar con claridad qué cree, por qué lo cree y qué tendría que ser verdad para que su apuesta funcione.
La validación empieza después.
Por qué existe Click
Knapp creó el Design Sprint después de una experiencia que casi termina mal.
En 2007 comenzó a trabajar con Serge Lachapelle y Mikael Drugge en una idea de videoconferencia desde el navegador. Durante casi dos años, el proyecto acumuló presentaciones, funciones y complejidad: una sala tridimensional, documentos interactivos, agendas y pizarras. La propuesta crecía, pero dentro de Google nadie terminaba de entender por qué debía importarle.
Una crisis interna les impuso una semana para demostrar valor. El equipo eliminó casi todo y conservó una promesa: la forma más rápida y sencilla de iniciar una videollamada grupal desde el navegador. El viernes ya tenían un prototipo utilizable. Esa versión reducida comenzó a circular dentro de Google y con el tiempo se convirtió en Google Meet. Knapp relata la historia en el extracto de Click publicado por Lenny’s Newsletter.
La lección no es “construye cualquier cosa en cinco días”. Es más específica:
- Una idea compleja puede ocultar una promesa débil.
- Una promesa clara permite decidir qué eliminar.
- Un prototipo sólo enseña algo cuando representa una hipótesis concreta.
El Design Sprint convirtió la semana de Estocolmo en un método para probar soluciones. Años después, Knapp y Zeratsky detectaron un problema anterior: muchos equipos llegaban al prototipo sin haber acordado qué cliente, qué problema, qué ventaja y qué alternativa debían poner a prueba.
El Foundation Sprint fue diseñado para cerrar esa brecha. Según Character Capital, los autores lo construyeron a partir de su trabajo con más de 300 productos y empresas.
Foundation Sprint, Design Sprint y ejecución no son lo mismo
Los nombres se parecen, pero cada método responde una pregunta distinta.
| Método | Pregunta principal | Entregable | Cuándo usarlo |
|---|---|---|---|
| Foundation Sprint | ¿Cuál es nuestra apuesta estratégica? | Founding Hypothesis, diferenciación, enfoque principal y respaldo | Al iniciar o replantear un producto |
| Design Sprint | ¿Esta solución funciona para clientes reales? | Prototipo y evidencia cualitativa de cinco pruebas | Cuando existe una hipótesis que representar |
| Continuous Discovery | ¿Qué oportunidades y supuestos debemos investigar continuamente? | Evidencia recurrente, oportunidades y pruebas de supuestos | Durante toda la vida del producto |
| Shape Up | ¿Vale la pena apostar tiempo de construcción a esta solución acotada? | Pitch con problema, apetito, solución, riesgos y límites | Antes de comprometer un ciclo de entrega |
El Foundation Sprint no reemplaza esas prácticas. Se coloca antes y les entrega una dirección.
La guía oficial del Design Sprint comienza con un reto y termina con un prototipo probado. Shape Up exige convertir una idea en un pitch delimitado antes de llevarla a la mesa de apuestas. La práctica de assumption testing de Product Talk descompone una solución en supuestos de deseabilidad, usabilidad, factibilidad, viabilidad y ética.
Un flujo sensato puede combinar los cuatro:
Lo que debe producir el sprint
Dos días de conversación no bastan. El valor está en salir con artefactos que puedan revisarse, cuestionarse y probarse:
- The Basics: cliente, problema, ventaja y competidores.
- Mapa de diferenciación: dos criterios donde la propuesta aspira a separarse de las alternativas.
- Principios: reglas prácticas para sostener esa diferenciación al diseñar.
- Mini Manifesto: diferenciación y principios en una sola página.
- Approach summaries: varias formas posibles de resolver el problema.
- Magic Lenses: comparaciones de esas opciones desde perspectivas distintas.
- Top Bet y Backup: enfoque principal y alternativa explícita.
- Founding Hypothesis: la estrategia condensada en una oración.
- Scorecard: preguntas que pueden demostrar o refutar cada predicción.
Preparación: las condiciones importan tanto como los ejercicios
La receta oficial pide un equipo de máximo cinco personas, incluido el Decider, y dos días de aproximadamente seis horas. También necesita una persona que facilite, aunque puede formar parte del grupo.
Quién debe estar
No invites a toda la empresa. Invita a quienes poseen perspectivas irreemplazables:
- quien decide la inversión o la dirección del producto;
- alguien cercano al cliente y a ventas;
- producto o diseño;
- tecnología u operaciones;
- una persona con conocimiento específico del mercado o del problema.
La diversidad no significa llenar asientos por cortesía. Significa incluir información que cambiaría una decisión.
El Decider no es un moderador
El Decider tiene autoridad para elegir cuando la evidencia disponible no produce consenso. Puede respetar la votación o apartarse de ella, pero debe explicar qué incertidumbre está aceptando.
Sin esa autoridad, las decisiones vuelven a abrirse al terminar el taller. Con demasiada autoridad y poca escucha, el sprint se convierte en una presentación elaborada para confirmar lo que el jefe ya quería. El mecanismo funciona sólo si la decisión queda clara y sus supuestos quedan expuestos.
Qué llevar preparado
La guía puede ejecutarse sin un research project previo, pero un equipo serio debería llegar con:
- entrevistas o llamadas de ventas recientes;
- consultas de soporte y motivos de pérdida;
- datos de uso, abandono o tiempos operativos;
- alternativas que los clientes usan hoy;
- restricciones técnicas, regulatorias y comerciales conocidas;
- decisiones anteriores que no deben reabrirse sin evidencia nueva.
El taller sintetiza información. No puede sintetizar lo que nadie se molestó en observar.
Note-and-Vote: pensar juntos sin pensar en grupo
El motor de casi todos los ejercicios es Note-and-Vote. Los autores rechazan el brainstorming abierto porque suele premiar velocidad verbal, estatus y capacidad para defender una idea. Su guía específica de Note-and-Vote usa seis movimientos:
- Escribir una pregunta concreta y visible.
- Pensar en silencio durante unos cinco minutos.
- Colocar respuestas anónimas, una por nota.
- Leer sin debatir y votar en silencio.
- Debatir brevemente sólo si el Decider necesita contexto.
- Decidir y avanzar.
Esto no vuelve objetiva a la decisión. Lo que hace es separar tres actividades que las reuniones mezclan: generar, evaluar y decidir.
Una regla útil para facilitarlo: si una pregunta genera respuestas demasiado diferentes, no corras a votar. Primero comprueba si todos entendieron la misma pregunta. “¿Quién es el cliente?” puede significar usuario, comprador, administrador, beneficiario o canal. Votar sobre categorías incompatibles produce una falsa claridad.
Día 1 por la mañana: The Basics
La primera mitad parece obvia, y ésa es precisamente la trampa. Los equipos pueden discutir arquitectura durante horas y seguir usando cinco definiciones distintas de cliente.
1. Elegir un cliente concreto
“Empresas”, “pymes”, “equipos distribuidos” y “usuarios digitales” no describen a una persona capaz de reconocer un problema y cambiar de conducta.
Una formulación útil incluye:
- rol o situación;
- contexto donde aparece el problema;
- frecuencia o intensidad;
- capacidad para adoptar o comprar.
“Responsables de operaciones de distribuidoras con varias sucursales que reconcilian pedidos e inventario cada día” ofrece más información que “empresas de retail”.
Esto no significa que sólo exista un tipo de usuario. Significa que la primera prueba necesita un blanco.
2. Elegir un problema que justifique cambiar
Probar una solución cuesta tiempo, atención, dinero, confianza y aprendizaje. Por eso el ejercicio oficial pregunta qué dolor es lo bastante importante para compensar ese costo.
Un problema fuerte tiene rastros observables:
- ocurre con frecuencia;
- causa errores, demora, riesgo o pérdida;
- ya provoca un workaround;
- alguien tiene responsabilidad sobre el resultado;
- empeora si no se resuelve.
Evita redactarlo como ausencia de tu función: “no tienen un dashboard” no es un problema. “Tardan dos días en saber qué pedidos no podrán surtir” sí lo es.
3. Identificar la ventaja real
Click separa la ventaja en tres fuentes:
| Fuente | Pregunta | Ejemplo |
|---|---|---|
| Capability | ¿Qué sabemos hacer excepcionalmente bien? | Integrar sistemas legacy sin detener la operación |
| Insight | ¿Qué entendemos que otros pasan por alto? | El dato se captura tarde porque el personal trabaja lejos de un escritorio |
| Motivation | ¿Por qué este equipo perseverará donde otros no? | Conocimiento directo del problema y compromiso de largo plazo |
Una ventaja no es “calidad”, “innovación” o “usar IA”. Es una asimetría concreta que permite entregar una promesa difícil de copiar.
La motivación por sí sola tampoco crea una ventaja. Importa cuando ayuda a tolerar una dificultad que otros evitarán: una venta lenta, integración incómoda, mercado pequeño al inicio o necesidad de conocimiento especializado.
4. Nombrar la competencia real
La competencia no se limita a productos de la misma categoría. Incluye:
- software directo;
- herramientas genéricas;
- procesos manuales;
- outsourcing;
- hojas de cálculo y mensajería;
- no hacer nada.
“No hacer nada” merece atención especial. Si la mayoría tolera el problema, quizá no sea lo bastante urgente. Si lo tolera porque cambiar es demasiado riesgoso, la oportunidad puede estar en reducir la adopción, no en añadir funciones.
El ejercicio también pide identificar al competidor más difícil de desplazar: el 800-pound gorilla. A veces es una marca enorme; otras, una hoja de cálculo que todos entienden y nadie necesita presupuestar.
Ejemplo: una distribuidora regional
Supongamos un caso representativo, no un cliente real:
| Elemento | Decisión inicial |
|---|---|
| Cliente | Responsable de operaciones de una distribuidora con 3 a 15 sucursales |
| Problema | No sabe con suficiente anticipación qué pedidos fallarán por inventario o coordinación |
| Capacidad | Integrar ventas, almacén y facturación por etapas |
| Insight | El problema no es capturar más datos, sino hacerlo dentro del flujo operativo |
| Motivación | Reducir carga manual sin imponer una transformación total |
| Competidor principal | Excel + WhatsApp + experiencia del encargado |
| Alternativas | ERP genérico, desarrollo interno, conciliación manual |
Todavía no sabemos si esto es verdad. Pero ahora sabemos exactamente qué investigar.
Día 1 por la tarde: diferenciación que se pueda entregar
La diferenciación no es una lista de adjetivos. Es una predicción sobre cómo el cliente comparará opciones.
Empezar con ejes clásicos
La guía propone puntuar posibilidades como:
- lento ↔ rápido;
- difícil ↔ fácil;
- costoso ↔ gratuito;
- disperso ↔ enfocado;
- complicado ↔ simple;
- aislado ↔ integrado;
- manual ↔ automático;
- poco inteligente ↔ inteligente.
Estos ejes sirven como calentamiento, no como estrategia final. Casi todos quieren estar del lado rápido, fácil, simple e inteligente. Si todos pueden decir lo mismo, no existe separación.
Crear ejes propios
Los mejores criterios nacen del contexto del cliente y de la ventaja del equipo:
- reemplazo total ↔ implementación por etapas;
- operación desde escritorio ↔ captura en el punto de trabajo;
- configuración genérica ↔ flujo específico del sector;
- proveedor transaccional ↔ acompañamiento operativo;
- dato tardío ↔ alerta antes del incumplimiento.
Después se eligen dos y se dibuja un mapa 2×2 con las alternativas. La meta es encontrar una posición donde la solución quede sola y la competencia forme una “L” alrededor.
Aquí hace falta honestidad. Si los ejes se inventan sólo para mandar a los competidores a los cuadrantes malos, el diagrama es publicidad interna. La pregunta correcta no es “¿cómo quedamos arriba a la derecha?”, sino “¿el cliente usa estos criterios y podemos sostener esta posición?”.
Convertir la diferenciación en principios
El equipo escribe dos o tres reglas capaces de cambiar decisiones reales.
Mal principio:
Crear experiencias intuitivas y de clase mundial.
Principio útil:
La operación diaria debe funcionar antes de completar la migración histórica.
El segundo ayuda a decidir qué construir primero, qué posponer y qué arquitectura aceptar.
La diferenciación y los principios forman el Mini Manifesto. Es el contrato del primer prototipo: la promesa y las reglas que impiden diluirla.
Día 2 por la mañana: producir enfoques, no listas de funciones
El segundo día comienza con una especie de “pre-pivot”: generar varias formas de resolver el mismo problema antes de comprometerse.
Un enfoque no es “dashboard con IA”. Debe explicar:
- qué es;
- cómo cambia la situación del cliente;
- por qué encaja con la ventaja;
- qué se vería o haría de forma diferente.
Cada enfoque cabe en una página: nombre, una frase y un dibujo sencillo. El Decider conserva hasta siete opciones y les asigna una letra o color para compararlas.
Para la distribuidora, podrían existir al menos cuatro:
- Centro de excepciones: prioriza sólo pedidos en riesgo.
- Asistente por mensajería: consulta y actualiza el flujo desde el canal existente.
- Aplicación operativa móvil: captura eventos en almacén y ruta.
- Capa de integración: conserva las interfaces actuales y sincroniza sistemas por detrás.
Observar cuatro direcciones obliga a distinguir la necesidad del primer diseño que alguien imaginó.
Día 2 por la tarde: decidir con Magic Lenses
Las Magic Lenses evitan intentar resolver una decisión multidimensional dentro de una sola discusión. Cada enfoque se coloca en matrices 2×2 desde cuatro perspectivas:
- Customer lens: claridad, utilidad y esfuerzo para el cliente.
- Pragmatic lens: dificultad, costo y velocidad de construcción.
- Growth lens: adopción, distribución y potencial de expansión.
- Money lens: valor económico, mercado y sostenibilidad.
Después se añaden lentes propias. La guía menciona criterios como dolor del cliente, entusiasmo del fundador, singularidad para el equipo, alineación con la misión o capacidad de crecer sin publicidad.
No se suman puntos como si fuera una licitación. El equipo se aleja del tablero y busca patrones:
- ¿una opción gana casi siempre?
- ¿una lente revela un riesgo existencial?
- ¿dos criterios se contradicen?
- ¿qué opción depende de una suposición que todavía no podemos comprobar?
El Decider elige:
- Top Bet: la primera apuesta;
- Backup: el siguiente enfoque si la apuesta principal encuentra un bloqueo.
Nombrar el respaldo evita dos extremos: defender la primera opción por orgullo o pivotar a cualquier ocurrencia cuando algo falla.
La Founding Hypothesis
El sprint termina condensando sus decisiones:
Si ayudamos a [cliente] a resolver [problema] mediante [enfoque], elegirá nuestra solución frente a [competidores] porque es [diferenciadores].
La frase oficial puede consultarse en la guía de Character Capital. Su valor no está en sonar elegante, sino en contener predicciones separables.
Para el ejemplo:
Si ayudamos a responsables de operaciones de distribuidoras regionales a anticipar pedidos que fallarán mediante un centro de excepciones conectado a ventas, almacén y facturación, lo elegirán frente a Excel, WhatsApp y un ERP genérico porque se implanta por etapas y alerta antes del incumplimiento sin reemplazar de golpe su operación.
Es larga. No importa todavía. Primero debe ser precisa; después puede convertirse en una promesa comercial más breve.
De la frase a un scorecard que pueda fallar
La hipótesis contiene al menos seis riesgos:
| Predicción | Pregunta de prueba | Evidencia útil |
|---|---|---|
| Cliente | ¿Elegimos a quien vive y puede cambiar el problema? | Entrevistas, proceso de compra, datos de uso |
| Problema | ¿Es frecuente, costoso y urgente? | Conducta pasada, workarounds, incidentes, tiempos |
| Enfoque | ¿La solución encaja en el flujo real? | Prototipo, prueba de tareas, concierge |
| Competencia | ¿Cambiarán desde la alternativa actual? | Comparación, objeciones, prueba de adopción |
| Diferenciación | ¿Valoran y creen nuestra promesa? | Test de mensaje, elección entre propuestas |
| Factibilidad | ¿Podemos entregar la promesa? | Spike técnico, integración de riesgo, estimación acotada |
La pregunta “¿te gustaría usar esto?” genera cortesía. Conviene pedir evidencia más difícil:
- “Cuéntame la última vez que ocurrió.”
- “¿Qué hiciste y cuánto tardó?”
- “¿Quién tuvo que intervenir?”
- “¿Qué pasa si no se resuelve?”
- “¿Qué has intentado comprar o cambiar?”
Luego se prueba la parte más incierta, no necesariamente el producto completo. Strategyzer propone diseñar cada experimento con una hipótesis, una prueba, una métrica y un umbral mediante su Test Card. Product Talk recomienda probar supuestos específicos para comparar soluciones sin construirlas enteras.
Define criterios antes de ver el resultado
Un experimento sin umbral se interpreta a conveniencia. Para cada riesgo registra:
- qué creemos;
- qué observaremos;
- qué resultado aumenta confianza;
- qué resultado obliga a cambiar;
- quién decide qué ocurre después.
“Cinco personas dijeron que les gustó” no basta. “Cuatro de cinco responsables detectaron correctamente un pedido en riesgo sin ayuda y tres pidieron usar el prototipo con datos reales” es una señal más concreta, aunque siga siendo cualitativa y requiera más evidencia.
Agenda de dos días
La agenda oficial deja bastante espacio para pausas y síntesis:
| Día y hora aproximada | Actividad | Resultado |
|---|---|---|
| Día 1 · 10:00 | Cliente, problema, ventaja y competidores | Basics acordados |
| Día 1 · 12:00 | Diferenciadores clásicos y propios | Dos criterios prioritarios |
| Día 1 · 14:00 | Matriz 2×2 | Hipótesis de posicionamiento |
| Día 1 · 14:30 | Principios | Reglas de decisión |
| Día 1 · 15:30 | Mini Manifesto | Contrato del prototipo |
| Día 2 · 10:00 | Enfoques de una página | Hasta siete alternativas |
| Día 2 · 12:00 | Cuatro Magic Lenses | Comparación multidimensional |
| Día 2 · 13:30 | Lentes propias y revisión | Patrones y contradicciones |
| Día 2 · 14:45 | Decisión | Top Bet y Backup |
| Día 2 · 15:00 | Founding Hypothesis | Apuesta lista para probar |
No reduzcas las pausas para “ser productivo”. La atención cae, la conversación se vuelve defensiva y el Decider empieza a resolver por agotamiento.
Cuándo usarlo
El Foundation Sprint encaja bien cuando:
- una empresa inicia un producto o servicio;
- varios fundadores describen clientes o ventajas distintas;
- existe una tecnología interesante pero no una promesa clara;
- un producto necesita reposicionarse;
- el equipo tiene muchas direcciones plausibles y ninguna apuesta explícita;
- la construcción con IA se volvió fácil, pero decidir qué merece construirse sigue siendo difícil.
También puede servir en productos existentes si se acota a una nueva línea, mercado o cambio estratégico. No hace falta fingir que toda la compañía vuelve a comenzar.
Cuándo no usarlo
No es la herramienta indicada cuando:
- el problema ya está claro y el bloqueo es puramente de ejecución;
- el Decider no asistirá ni respetará las decisiones;
- faltan conocimientos básicos y nadie puede hacer investigación previa;
- el supuesto crítico es regulatorio, científico o técnico y requiere primero un estudio especializado;
- se usa el taller para legitimar una solución ya decidida;
- el equipo espera que dos días entreguen product-market fit.
En sistemas complejos, mercados con varios lados o compras empresariales, una sola Founding Hypothesis puede ser insuficiente. Puede hacer falta una hipótesis por actor: usuario, comprador, administrador, integrador y área de cumplimiento.
Cinco formas de arruinar el sprint
1. Confundir alineación con verdad
Cinco personas pueden ponerse de acuerdo y seguir equivocadas. El entregable debe conservar palabras como “creemos”, “suponemos” y “probaremos”.
2. Elegir ejes que sólo favorecen la narrativa
Si la diferenciación no proviene de cómo decide el cliente, el 2×2 es decoración. Verifica el lenguaje en entrevistas y ventas.
3. Usar “IA” como diferenciador
Una capacidad disponible para todos rara vez crea una posición. La diferenciación suele estar en datos, integración, distribución, workflow, confianza, velocidad de adopción o conocimiento del dominio.
4. Convertir los principios en valores corporativos
“Simple”, “humano” e “innovador” no resuelven tradeoffs. Un principio debe permitir rechazar una función.
5. Tratar la Top Bet como compromiso irreversible
Es una apuesta prioritaria, no una identidad. El Backup existe porque la prueba puede fallar.
Foundation Sprint y Shape Up: una combinación especialmente útil
El Foundation Sprint responde qué promesa merece investigación. Shape Up añade una disciplina que Click no cubre en profundidad: cuánto estamos dispuestos a invertir.
Un pitch de Shape Up contiene problema, apetito, solución, rabbit holes y no-gos. Su concepto de apetito cambia la pregunta de “¿cuánto tardará la solución perfecta?” a “¿qué solución vale una o seis semanas?”. La mesa de apuestas limita el riesgo: si el trabajo no cabe en el tiempo acordado, no recibe extensiones automáticas.
Una secuencia madura sería:
- Foundation Sprint para escoger la apuesta estratégica.
- Pruebas para reducir sus riesgos existenciales.
- Design Sprint cuando una interacción necesita prototipo.
- Shape Up para delimitar la versión que merece construirse.
- Entrega y Continuous Discovery para aprender del uso real.
Qué aporta Click en la era de la IA
Generar interfaces, código y campañas cuesta menos que hace pocos años. Eso no elimina el riesgo de producto: lo desplaza.
Cuando producir es barato:
- aparecen más alternativas;
- copiar funciones es más rápido;
- los equipos pueden construir antes de entender;
- la claridad de cliente, workflow, distribución y confianza pesa más;
- eliminar opciones se vuelve una competencia central.
La propia guía oficial del Foundation Sprint presenta el método como una forma de decidir qué construir cuando la IA vuelve accesible construir casi cualquier cosa.
Ésa es quizá la idea más vigente de Click: la velocidad de producción aumenta el valor del criterio.
No necesitas menos estrategia porque un agente programe rápido. Necesitas una estrategia más explícita, porque ahora puedes desperdiciar meses de trabajo en días.
Checklist para ejecutar uno de verdad
Antes
- Nombrar Decider y Facilitador.
- Limitar el grupo a cinco personas.
- Reservar dos días completos, aproximadamente seis horas cada uno.
- Reunir evidencia reciente y restricciones.
- Preparar tablero físico o plantilla de Miro oficial.
- Acordar qué parte del negocio está dentro y fuera del sprint.
Durante
- Usar lenguaje de personas y conductas, no segmentos vagos.
- Mantener generación, votación y decisión separadas.
- Incluir workarounds y “no hacer nada” como competencia.
- Distinguir capacidad, insight y motivación.
- Crear ejes propios de diferenciación.
- Formular principios que cambien decisiones.
- Explorar enfoques realmente distintos.
- Elegir Top Bet y Backup.
Después
- Descomponer la Founding Hypothesis en supuestos.
- Ordenarlos por riesgo, no por facilidad.
- Definir evidencia y umbrales antes de probar.
- Ejecutar entrevistas, prototipos, tests de mensaje o spikes.
- Registrar qué cambió y por qué.
- Limitar el primer compromiso de construcción.
Preguntas frecuentes
¿El Foundation Sprint valida una idea?
No. Alinea al equipo y convierte la idea en hipótesis comprobables. La validación requiere evidencia externa posterior.
¿Cuál es la diferencia con un Design Sprint?
El Foundation Sprint define cliente, problema, ventaja, diferenciación y enfoque. El Design Sprint transforma una hipótesis en un prototipo y lo prueba con clientes.
¿Puede hacerse en remoto?
Sí. Los autores ofrecen una plantilla de Miro. Conviene mantener trabajo silencioso, cámaras opcionales durante la escritura, notas anónimas, temporizador visible y pausas reales.
¿Sirve para un producto existente?
Sí, si se aplica a una decisión estratégica concreta: nuevo mercado, nueva línea, reposicionamiento o cambio de enfoque. No hace falta reabrir todo el producto.
¿Qué pasa si el Decider elige contra los votos?
El método lo permite. Debe quedar registrada la razón y convertirse en un supuesto explícito. La evidencia posterior, no el rango, decidirá si la apuesta se sostiene.
¿Qué se construye al terminar?
Idealmente, nada de producción todavía. Primero se prueba el riesgo más importante con el artefacto más barato que pueda producir evidencia.
Cómo lo aplicaríamos en Calaverita
En un proyecto de diseño de producto, el Foundation Sprint puede evitar que un brief ambiguo se convierta directamente en backlog. La Founding Hypothesis conecta la conversación estratégica con prototipos, integraciones y decisiones de alcance.
Después la aterrizaríamos en:
- un mapa de supuestos y pruebas;
- un prototipo del flujo crítico;
- un spike de la integración más riesgosa;
- criterios observables para continuar, cambiar o detener;
- un alcance de entrega compatible con nuestro proceso.
La meta no es producir más documentos. Es gastar la menor cantidad de tiempo necesaria para descubrir si la apuesta merece convertirse en software.
Si tienes una idea, varias opiniones y ninguna hipótesis compartida, podemos ayudar a convertirla en una decisión comprobable.
Referencias
- Jake Knapp y John Zeratsky — guía oficial del Foundation Sprint, Character Capital.
- Jake Knapp y John Zeratsky — Click: How to Make What People Want, Avid Reader Press / Simon & Schuster, 2025.
- Jake Knapp y John Zeratsky — extracto e introducción del Foundation Sprint, Lenny’s Newsletter, 2025.
- Character Capital — Note-and-Vote y Design Sprint.
- Ryan Singer — Shape Up, Basecamp.
- Product Talk — Assumption Testing.
- Strategyzer — Validate Your Ideas with the Test Card.