Phase 1: Plan

What is the Plan phase?

Planning is not about producing a perfect roadmap. It is about achieving clarity — enough clarity to start building with confidence and to recognize when you are drifting.

The Plan phase follows the diverge → converge pattern. It starts by opening up: exploring the problem, questioning assumptions, considering who is affected and why. It ends by closing down: committing to one specific goal, one audience, one set of success criteria. Both halves matter. Starting with convergence produces plans that solve the wrong problem. Never converging produces analysis without action.

A good plan answers these questions:

What is the problem? — What is actually broken, missing, or needed?
Who is this for? — Who experiences this problem? Who will use or read what you build?
What is the goal? — What does a successful outcome look like, specifically?
What is the appetite? — How much are you willing to invest in this? This is a conscious bet, not an estimate. Scope is variable within it.
What are the constraints? — Skills, dependencies, non-negotiables beyond the appetite.
What is the success criteria? — How will you know, objectively, that this is done?
What is the core assumption? — What must be true for this plan to work? If this turns out to be false, the plan fails.
What are the rabbit holes? — What unknowns could drag the build into territory you don't want to explore in this cycle?

The Plan Brief

The output of the Plan phase is a Plan Brief — a short, written document that captures the answers above. It doesn't need to be long. It needs to be clear.

The Plan Brief is also the instruction set you hand to an AI agent when Build begins. Every ambiguity in it becomes a guess in the output. Write it so that someone (or something) who didn't write it could execute it and produce the same result.

## Plan Brief

**Problem**
[One or two sentences. What is broken, missing, or needed? Be specific.]

**Audience**
[Who experiences this problem? Who will use, read, or interact with what you build?]

**Goal**
[One sentence. What does success look like? Start with a verb: "Build", "Write", "Fix", "Define".]

**Appetite**
[How much are you willing to invest in this cycle? This is a bet, not an estimate. Scope should fit inside it.
Example: "One week of focused work. If it can't be done in that, we scope it down — not extend the time."]

**Constraints**
- [Constraint 1 — e.g. no new dependencies]
- [Constraint 2 — e.g. must work on mobile]

**Success Criteria**
- [ ] [Measurable criterion 1]
- [ ] [Measurable criterion 2]
- [ ] [Measurable criterion 3]

**Core assumption**
[What must be true for this plan to work? If this turns out to be false, the plan fails.
Example: "Users are abandoning because of load time, not because of missing features."]

**Rabbit holes**
[What unknowns could drag the build into territory you don't want to explore in this cycle? Name them so they don't get explored.
Example: "Do not investigate why the legacy endpoint is slow — that is a separate system."]

**Out of scope**
[Explicitly list what you are NOT solving. This prevents scope creep.]

Common mistakes in the Plan phase

Mistake	Why it fails	Fix
Writing a goal that starts with "improve" or "better"	Not measurable, not falsifiable	Rewrite with a specific outcome: "Reduce load time from 4s to under 1s"
Skipping appetite	You'll keep expanding scope until you're exhausted or late	State how much you're willing to invest upfront. Then scope to fit it.
Skipping constraints	You'll discover them mid-build and lose momentum	List every known constraint upfront, even obvious ones
Conflating problem with solution	"We need a dashboard" is a solution, not a problem	Dig to the actual need: "Users can't track their usage at a glance"
Not defining out of scope	Every undefined boundary becomes a potential scope expansion	Be explicit about what this effort does NOT address
Skipping the audience	The solution will be shaped by who it is for — a beginner and an expert need different things	Name the specific person or group this is built for
Not naming the core assumption	The plan looks solid but rests on an unexamined belief that might be wrong	Write down what you're betting on. It makes the post-ship review honest.
Not naming rabbit holes	The build goes down a rabbit hole that could have been flagged upfront	Name the unknowns you're choosing not to explore in this cycle

When is the Plan phase done?

The Plan phase is done when you can hand your Plan Brief to someone else and they can understand:

What you are solving
Who it is for
What you are building
What done looks like

If they have to ask clarifying questions about any of these, the plan is not ready.

Optional gates from Plan

Before moving to Build, consider using a gate if:

The problem space is unfamiliar → use Research first
The plan has high cost to change once started → use Plan Validation
The plan involves multiple people → use Plan Validation to align before execution

Using AI in the Plan phase

AI is a useful thinking partner in Plan — but the goal must remain yours. A vague brief produces vague output from a human and from an AI agent. A precise brief makes AI dramatically more effective.

Where AI helps

Challenging your problem statement
Helping you define the audience more precisely
Surfacing constraints you might have missed
Rewriting vague goals into specific, measurable ones
Generating alternative framings of the same problem

Where human judgment must lead

Deciding what problem is worth solving
Setting success criteria that reflect real value
Determining what is out of scope
Owning the plan brief as a commitment

Prompt to try:

Here is my plan brief: [paste brief]

Challenge my problem statement. Is this the real problem or a symptom of something deeper?
What constraints am I likely missing?
Are my success criteria measurable and falsifiable?
Would an AI agent be able to execute this brief without asking clarifying questions?

Exit checklist

Problem is stated in one or two sentences without a solution embedded in it
Audience is named — a specific person or group, not "everyone"
Goal starts with a specific verb and describes a concrete outcome
Appetite is stated — a conscious investment decision, not a guess
Constraints are listed beyond the appetite
Success criteria are measurable and checkable
Core assumption is named — what this plan is betting on
Rabbit holes are named — unknowns explicitly set aside for this cycle
Out of scope is explicitly defined
Someone else (or an AI agent) could read this brief and execute it without asking questions

¿Qué es la fase Plan?

Planificar no se trata de producir un mapa de ruta perfecto. Se trata de lograr claridad — suficiente claridad para comenzar a construir con confianza y para reconocer cuándo te estás desviando.

La fase Plan sigue el patrón divergir → converger. Comienza abriéndose: explorando el problema, cuestionando supuestos, considerando quién se ve afectado y por qué. Termina cerrándose: comprometerse con un objetivo específico, una audiencia, un conjunto de criterios de éxito. Ambas mitades importan. Comenzar con convergencia produce planes que resuelven el problema incorrecto. No converger nunca produce análisis sin acción.

Un buen plan responde estas preguntas:

¿Cuál es el problema? — ¿Qué está roto, qué falta o qué se necesita?
¿Para quién es? — ¿Quién experimenta este problema? ¿Quién usará o leerá lo que construyas?
¿Cuál es el objetivo? — ¿Cómo se ve un resultado exitoso, específicamente?
¿Cuál es el apetito? — ¿Cuánto estás dispuesto a invertir? Es una apuesta consciente, no una estimación. El alcance es variable dentro de ella.
¿Cuáles son las restricciones? — Habilidades, dependencias, elementos no negociables más allá del apetito.
¿Cuáles son los criterios de éxito? — ¿Cómo sabrás, objetivamente, que esto está terminado?
¿Cuál es el supuesto central? — ¿Qué debe ser verdad para que este plan funcione? Si esto resulta falso, el plan falla.
¿Cuáles son los pozos sin fondo? — ¿Qué incógnitas podrían arrastrar el build hacia territorio que no quieres explorar en este ciclo?

El Plan Brief

El resultado de la fase Plan es un Plan Brief — un documento escrito breve que captura las respuestas anteriores. No necesita ser largo. Necesita ser claro.

El Plan Brief también es el conjunto de instrucciones que entregas a un agente de IA cuando comienza el Build. Cada ambigüedad en él se convierte en una suposición en el resultado. Escríbelo de modo que alguien (o algo) que no lo escribió pueda ejecutarlo y producir el mismo resultado.

## Plan Brief

**Problema**
[Una o dos oraciones. ¿Qué está roto, qué falta o qué se necesita? Sé específico.]

**Audiencia**
[¿Quién experimenta este problema? ¿Quién usará, leerá o interactuará con lo que construyas?]

**Objetivo**
[Una oración. ¿Cómo se ve el éxito? Comienza con un verbo: "Construir", "Escribir", "Corregir", "Definir".]

**Apetito**
[¿Cuánto estás dispuesto a invertir en este ciclo? Es una apuesta, no una estimación. El alcance debe caber dentro.
Ejemplo: "Una semana de trabajo enfocado. Si no puede hacerse en ese tiempo, reducimos el alcance — no extendemos el tiempo."]

**Restricciones**
- [Restricción 1 — ej. sin nuevas dependencias]
- [Restricción 2 — ej. debe funcionar en móvil]

**Criterios de éxito**
- [ ] [Criterio medible 1]
- [ ] [Criterio medible 2]
- [ ] [Criterio medible 3]

**Supuesto central**
[¿Qué debe ser verdad para que este plan funcione? Si esto resulta falso, el plan falla.
Ejemplo: "Los usuarios abandonan por el tiempo de carga, no por falta de funcionalidades."]

**Pozos sin fondo**
[¿Qué incógnitas podrían arrastrar el build hacia territorio que no quieres explorar en este ciclo? Nómbralos para que no se exploren.
Ejemplo: "No investigar por qué el endpoint legacy es lento — eso es un sistema separado."]

**Fuera de alcance**
[Lista explícitamente lo que NO estás resolviendo. Esto previene la expansión del alcance.]

Errores comunes en la fase Plan

Error	Por qué falla	Corrección
Escribir un objetivo que comienza con "mejorar" o "mejor"	No es medible ni falsificable	Reescribir con un resultado específico: "Reducir el tiempo de carga de 4s a menos de 1s"
Saltarse el apetito	Seguirás expandiendo el alcance hasta agotarte o llegar tarde	Declara cuánto estás dispuesto a invertir por adelantado. Luego ajusta el alcance a eso.
Saltarse las restricciones	Las descubrirás a mitad del build y perderás impulso	Lista todas las restricciones conocidas por adelantado, incluso las obvias
Confundir problema con solución	"Necesitamos un dashboard" es una solución, no un problema	Llegar a la necesidad real: "Los usuarios no pueden ver su uso de un vistazo"
No definir fuera de alcance	Cada límite indefinido se convierte en una posible expansión del alcance	Sé explícito sobre lo que este esfuerzo NO aborda
Saltarse la audiencia	La solución estará moldeada por para quién es — un principiante y un experto necesitan cosas diferentes	Nombra la persona o grupo específico para quien se construye
No nombrar el supuesto central	El plan parece sólido pero descansa en una creencia no examinada que podría estar equivocada	Escribe en qué estás apostando. Hace que la revisión post-entrega sea honesta.
No nombrar los pozos sin fondo	El build cae en un pozo sin fondo que podría haberse señalado por adelantado	Nombra las incógnitas que decides no explorar en este ciclo

¿Cuándo termina la fase Plan?

La fase Plan termina cuando puedes entregar tu Plan Brief a otra persona y entienda:

Qué estás resolviendo
Para quién es
Qué estás construyendo
Cómo se ve "terminado"

Si tiene que hacer preguntas aclaratorias sobre cualquiera de estos puntos, el plan no está listo.

Gates opcionales desde Plan

Antes de pasar al Build, considera usar un gate si:

El espacio del problema es desconocido → usa Research primero
El plan tiene un alto costo de cambio una vez iniciado → usa Plan Validation
El plan involucra múltiples personas → usa Plan Validation para alinear antes de la ejecución

Usar IA en la fase Plan

La IA es un compañero de pensamiento útil en Plan — pero el objetivo debe seguir siendo tuyo. Un brief vago produce resultados vagos de un humano y de un agente de IA. Un brief preciso hace a la IA dramáticamente más efectiva.

Dónde ayuda la IA

Cuestionar tu enunciado del problema
Ayudarte a definir la audiencia con más precisión
Descubrir restricciones que podrías haber omitido
Reescribir objetivos vagos en objetivos específicos y medibles
Generar encuadres alternativos del mismo problema

Dónde debe liderar el juicio humano

Decidir qué problema vale la pena resolver
Establecer criterios de éxito que reflejen valor real
Determinar qué está fuera de alcance
Ser dueño del brief como un compromiso

Prompt para probar:

Aquí está mi plan brief: [pegar brief]

Cuestiona mi enunciado del problema. ¿Es este el problema real o un síntoma de algo más profundo?
¿Qué restricciones probablemente me estoy perdiendo?
¿Mis criterios de éxito son medibles y falsificables?
¿Podría un agente de IA ejecutar este brief sin hacer preguntas aclaratorias?

Lista de verificación de salida

El problema está enunciado en una o dos oraciones sin una solución incluida
La audiencia está nombrada — una persona o grupo específico, no "todos"
El objetivo comienza con un verbo específico y describe un resultado concreto
El apetito está declarado — una decisión de inversión consciente, no una suposición
Las restricciones están listadas más allá del apetito
Los criterios de éxito son medibles y verificables
El supuesto central está nombrado — en qué está apostando este plan
Los pozos sin fondo están nombrados — incógnitas explícitamente dejadas de lado para este ciclo
El fuera de alcance está definido explícitamente
Alguien más (o un agente de IA) podría leer este brief y ejecutarlo sin hacer preguntas