Ship
Put the result in the world — live, real, in front of people or systems. This is the definition of done.
What is the Ship phase?
Ship is not polish. Ship is not perfection. Ship is the act of making something real — taking it out of your local environment, your draft folder, your private repository, and placing it where it will be used, read, or experienced by others.
Shipping is how you validate that what you built actually works in the real world. Until something is shipped, you are operating on assumptions.
The Ship phase is done when something is live and accessible to its intended audience.
What "shipped" means across different contexts
| Context | Shipped means |
|---|---|
| Software feature | Deployed to production, accessible to real users |
| Article or post | Published and publicly accessible |
| Design | Shared with stakeholders or handed off to development |
| Strategy or decision | Communicated and acted on by the people responsible |
| Internal tool | Running and in use by the people it was built for |
| API or service | Live and returning real responses |
The common thread: someone or something that isn't you is now interacting with it.
How to run the Ship phase
Do a final brief check
Before shipping, re-read your Plan Brief one final time. Specifically check: do the success criteria match what you've built? Is what you're about to ship within the defined scope? Is the Plan Brief up to date?
This is not a gate — it is a 5-minute sanity check. It prevents shipping the wrong version of the right thing.
Ship the minimum that meets the criteria
Ship the version that satisfies the success criteria from the plan — not the version that satisfies everything you thought of during Build. Future improvements belong to the next cycle.
Make it real
Execute the actual shipping action: deploy, publish, send, release, present, hand off. Do not stop at "ready to ship." Ship.
Confirm it is live
Verify the output is actually accessible. Check it from the perspective of the intended audience. This step is skipped more often than it should be.
Capture what you learned
After shipping, take 10 minutes to note: what worked as expected? What didn't? What would you do differently in the next cycle?
This is not a formal retrospective. It is a brief, informal capture that feeds the next cycle's Plan phase.
The most common shipping failures
Shipping the wrong thing. This happens when context was lost between Plan and Build — when what got built no longer serves the original goal. The final brief check exists to catch this.
Not shipping at all. The second most common failure. The work is "done" but lives in draft, in staging, in a private repo. A result that isn't shipped is a result that produced no value. Ship the imperfect thing.
Shipping is not the end
Shipping ends the current cycle — it does not end the work. Use the Review gate to measure whether what you shipped actually worked, reflect on the cycle, and feed what you learned into the next Plan.
After reviewing, one of three things will be true:
- It worked — the goal was met, the success criteria are satisfied. The next problem can begin.
- It partially worked — some criteria are met, some aren't. The unmet criteria and what you learned become the Plan for the next cycle.
- It didn't work — the goal was wrong, the approach was wrong, or the execution was wrong. This is real signal. Use it. Start a new cycle with what you learned.
In all three cases, the next step is a new Plan phase — informed by the Review.
Plan → Build → Ship → [Review] → Plan → ...The continuation loop is not optional for teams that want to improve. It is the mechanism that compounds. Each cycle informed by a thorough Review is better than a cycle started from scratch.
Using AI in the Ship phase
The Ship phase is where human judgment is most critical. AI cannot make the call of "is this ready."
Where AI helps
- Writing release notes, changelogs, or shipping announcements
- Generating the checklist for a specific type of deployment
- Reviewing the output one last time before it goes live
- Drafting the "what we learned" capture after shipping
Where human judgment must lead
- Deciding whether this is actually ready to ship
- Deciding who needs to know and how
- Deciding what the next cycle should focus on
Here is my Plan Brief: [paste brief]
Here is what I'm about to ship: [describe output]
Does this satisfy the success criteria?
Is there anything that would block me from shipping this today?
What should I capture as a learning before I close this cycle?Exit checklist
- The output is live and accessible to its intended audience
- You have personally confirmed it is accessible (not just deployed)
- Success criteria from the Plan Brief are met
- Learnings from this cycle are captured (even briefly)
- Next steps or next cycle inputs are noted
Plan → Build → Ship ✓If you captured learnings and identified next steps, you have everything you need to start the next cycle stronger.
Lanzar
Pon el resultado en el mundo — en vivo, real, frente a personas o sistemas. Esta es la definición de hecho.
¿Qué es la fase de Lanzar?
Lanzar no es pulir. Lanzar no es perfeccionar. Lanzar es el acto de hacer algo real — sacarlo de tu entorno local, tu carpeta de borradores, tu repositorio privado, y colocarlo donde será usado, leído o experimentado por otros.
Lanzar es cómo validas que lo que construiste realmente funciona en el mundo real. Hasta que algo sea lanzado, estás operando sobre suposiciones.
La fase de Lanzar termina cuando algo está en vivo y accesible para su audiencia prevista.
Qué significa "lanzado" en distintos contextos
| Contexto | Lanzado significa |
|---|---|
| Funcionalidad de software | Desplegada en producción, accesible para usuarios reales |
| Artículo o publicación | Publicado y accesible públicamente |
| Diseño | Compartido con las partes interesadas o entregado al equipo de desarrollo |
| Estrategia o decisión | Comunicada y ejecutada por los responsables |
| Herramienta interna | En funcionamiento y en uso por quienes fue construida |
| API o servicio | En vivo y devolviendo respuestas reales |
El hilo común: alguien o algo que no eres tú está interactuando con ello.
Cómo ejecutar la fase de Lanzar
Haz una verificación final del brief
Antes de lanzar, relee tu Plan Brief una última vez. Verifica específicamente: ¿los criterios de éxito coinciden con lo que construiste? ¿Lo que estás a punto de lanzar está dentro del alcance definido? ¿El Plan Brief está actualizado?
Esto no es una compuerta — es una verificación de 5 minutos. Previene lanzar la versión incorrecta de la cosa correcta.
Lanza el mínimo que cumple los criterios
Lanza la versión que satisface los criterios de éxito del plan — no la versión que satisface todo lo que pensaste durante la fase de Construir. Las mejoras futuras pertenecen al siguiente ciclo.
Hazlo real
Ejecuta la acción de lanzamiento: despliega, publica, envía, lanza, presenta, entrega. No te detengas en "listo para lanzar". Lanza.
Confirma que está en vivo
Verifica que el resultado es realmente accesible. Compruébalo desde la perspectiva de la audiencia prevista. Este paso se omite con más frecuencia de la que debería.
Captura lo que aprendiste
Después de lanzar, tómate 10 minutos para anotar: ¿qué funcionó como se esperaba? ¿Qué no? ¿Qué harías diferente en el próximo ciclo?
Esto no es una retrospectiva formal. Es una captura breve e informal que alimenta la fase de Planificar del próximo ciclo.
Los errores de lanzamiento más comunes
Lanzar la cosa equivocada. Esto ocurre cuando el contexto se perdió entre Planificar y Construir — cuando lo que se construyó ya no sirve al objetivo original. La verificación final del brief existe para detectar esto.
No lanzar en absoluto. El segundo error más común. El trabajo está "hecho" pero vive en borrador, en staging, en un repositorio privado. Un resultado que no se lanza es un resultado que no produjo valor. Lanza la cosa imperfecta.
Lanzar no es el final
Lanzar cierra el ciclo actual — no cierra el trabajo. Usa la compuerta de Revisión para medir si lo que lanzaste realmente funcionó, reflexionar sobre el ciclo, y alimentar lo que aprendiste en el próximo Plan.
Después de revisar, una de tres cosas será verdad:
- Funcionó — el objetivo se cumplió, los criterios de éxito están satisfechos. El próximo problema puede comenzar.
- Funcionó parcialmente — algunos criterios se cumplieron, otros no. Los criterios no cumplidos y lo que aprendiste se convierten en el Plan del próximo ciclo.
- No funcionó — el objetivo era incorrecto, el enfoque era incorrecto, o la ejecución fue incorrecta. Esto es señal real. Úsala. Comienza un nuevo ciclo con lo que aprendiste.
En los tres casos, el siguiente paso es una nueva fase de Planificar — informada por la Revisión.
Plan → Build → Ship → [Review] → Plan → ...El ciclo de continuación no es opcional para los equipos que quieren mejorar. Es el mecanismo que genera acumulación. Cada ciclo informado por una Revisión exhaustiva es mejor que un ciclo iniciado desde cero.
Usar IA en la fase de Lanzar
La fase de Lanzar es donde el juicio humano es más crítico. La IA no puede decidir "¿está esto listo?".
Donde la IA ayuda
- Redactar notas de lanzamiento, registros de cambios o anuncios
- Generar la lista de verificación para un tipo específico de despliegue
- Revisar el resultado una última vez antes de que salga en vivo
- Redactar la captura de "qué aprendimos" después de lanzar
Donde el juicio humano debe liderar
- Decidir si esto está realmente listo para lanzar
- Decidir quién necesita saberlo y cómo
- Decidir en qué debería enfocarse el próximo ciclo
Here is my Plan Brief: [paste brief]
Here is what I'm about to ship: [describe output]
Does this satisfy the success criteria?
Is there anything that would block me from shipping this today?
What should I capture as a learning before I close this cycle?Lista de verificación de salida
- El resultado está en vivo y accesible para su audiencia prevista
- Confirmaste personalmente que es accesible (no solo desplegado)
- Los criterios de éxito del Plan Brief están cumplidos
- Los aprendizajes de este ciclo están capturados (aunque sea brevemente)
- Los próximos pasos o entradas del próximo ciclo están anotados
Plan → Build → Ship ✓Si capturaste aprendizajes e identificaste próximos pasos, tienes todo lo necesario para comenzar el próximo ciclo con más fuerza.