Review
Two modes, one gate
Review appears at two points in the cycle:
Build → [Build Validation] → [Review (pre-ship)] → Ship → [Review (post-ship)] → PlanPre-ship Review
A holistic judgment check before the result goes live. Different from Build Validation, which checks technical correctness. Pre-ship Review checks intent: is this actually what we set out to build? Does it serve the audience?
Post-ship Review
Outcome measurement after the result is live. Did it work in the real world? What does that tell us about the next cycle?
They serve different purposes and happen at different times, but they share the same underlying question: is this doing what it was meant to do?
Pre-ship Review
"Does this serve the original goal and the audience? Are we ready to put this in front of real people?"
Pre-ship Review is not a technical check. Build Validation handles that. Pre-ship Review is a judgment call: does the full result — as a whole — fulfill the intent stated in the Plan Brief?
This is the moment to ask the questions that checklists don't catch.
What pre-ship Review checks
- Does the result actually solve the problem stated in the Plan Brief?
- Would the audience named in the brief find this useful, readable, or usable?
- Is there anything about this result that would embarrass you or mislead its audience?
- Are you shipping this because it's ready, or because you're tired of working on it?
The last question is the hardest and the most important.
How to run a pre-ship Review
Read the Plan Brief. Then experience the result as if you are the audience.
- If you built software: use it as the target user would use it, not as the developer who built it.
- If you wrote an article: read it as someone who doesn't know the background.
- If you built a design: evaluate it against the user's goal, not your aesthetic preferences.
Then answer:
- What is the single weakest thing about this result?
- Does that weakness block shipping, or is it acceptable for this cycle?
- Is there anything that, if you were the audience, would make you trust this less?
Pre-ship Review output
## Pre-ship Review
**Reviewed by:** [Name or "Self"]
**Date:** [Date]
**Does this solve the problem stated in the Plan Brief?**
[Yes / Partially / No — with explanation]
**Would the named audience find this useful/usable/readable?**
[Yes / Partially / No — with explanation]
**Weakest part of this result:**
[Be specific. One thing.]
**Decision on that weakness:**
- [ ] Fix before shipping
- [ ] Accept for this cycle — defer to next
- [ ] It's not actually a problem
**Ship readiness:**
- [ ] Ready to Ship
- [ ] Not ready — return to BuildPost-ship Review
"Did it actually work? What does that teach the next cycle?"
Shipping something live is not the same as knowing it worked. You need real-world signal — not the signal you predicted in the Plan Brief, but the signal the world returned.
Post-ship Review collects that signal, interprets it, and turns it into the starting point for the next Plan.
The three post-ship Review questions
- Did it work? How does the real-world outcome compare to the success criteria?
- Why did it go the way it did? What decisions, assumptions, or events shaped the result?
- What should the next cycle do differently? What did this cycle teach?
When to run a post-ship Review
| What you shipped | When to review |
|---|---|
| Software feature | After 1–2 weeks of real usage |
| Article or post | After 3–7 days live |
| Strategy or decision | After the first observable outcomes |
| Internal tool | After the first real use by its intended users |
| Quick experiment | Within 24–48 hours |
Don't review immediately after shipping — you need real signal, not initial noise. Don't wait indefinitely — at some point signal plateaus and the next cycle is already waiting.
How to run a post-ship Review
Measure against the success criteria
For each success criterion in the Plan Brief, answer: was it met, and how do you know?
Evidence must come from outside yourself: usage data, feedback from real users, observable behavior change, outcomes that happened or didn't. If a criterion cannot be measured with real evidence, note that — it means the criterion was too vague or the measurement method wasn't set up.
Reflect on the cycle
Look at the full cycle — Plan, Build, and Ship — and ask:
- What worked as expected?
- What didn't work as expected?
- What single decision, made differently, would have changed the outcome most?
- Was the Plan Brief accurate by the time you shipped? What changed?
Feed forward
Identify inputs for the next cycle:
- What new problem or opportunity did this cycle reveal?
- What was deferred to "out of scope" that should now be addressed?
- What assumption turned out to be wrong that should inform the next Plan?
Post-ship Review output
## Post-ship Review
**What was shipped:** [Brief description]
**Shipped on:** [Date]
**Reviewed on:** [Date]
**Measurement**
| Success Criterion | Result | Evidence |
|------------------|--------|---------|
| [Criterion 1] | Met / Partial / Not met | [How you know] |
| [Criterion 2] | Met / Partial / Not met | [How you know] |
| [Criterion 3] | Met / Partial / Not met | [How you know] |
**Overall: did it work?**
[One or two sentences. Was the goal achieved? What does the real-world outcome say?]
**What worked**
- [Observation 1]
- [Observation 2]
**What didn't work**
- [Observation 1]
- [Observation 2]
**The decision that mattered most**
[What single decision during this cycle had the biggest impact — good or bad?]
**Feed forward: inputs for the next cycle**
- [New problem or opportunity]
- [Deferred scope item to address]
- [Wrong assumption to correct]What if the result can't be measured yet?
Some results take time to surface. Set a review date at the time of shipping, note what signal you're waiting for, and run a partial Review now (reflect on the cycle) with a full Review later when the signal is available.
The reflection and measurement parts are independent — don't skip reflection because measurement isn't ready.
Using AI in the Review gate
Where AI helps
- Summarizing feedback or data into patterns
- Challenging your interpretation ("Is this signal or noise?")
- Identifying what the next cycle's Plan Brief should address
- Spotting assumptions that recurred across the cycle
Where human judgment must lead
- Deciding whether the outcome was actually good enough
- Interpreting ambiguous signal
- Choosing what to focus on in the next cycle
Here is my Plan Brief: [paste brief]
Here is what I shipped: [describe output]
Here is what happened after shipping: [describe outcomes, feedback, metrics]
Did the outcome match the goal and the audience's needs?
What does the gap between expected and actual tell me?
What should I carry into the next cycle's Plan?Review gate checklist
Pre-ship:
- Result experienced from the audience's perspective, not the builder's
- Weakest part identified and a decision made on it
- Shipping for the right reason — it's ready, not because you're tired of it
- Ship readiness decision is explicit
Post-ship:
- Waited for real-world signal before reviewing
- Each success criterion assessed against actual evidence
- Overall outcome written in one or two sentences
- What worked and what didn't documented separately
- Most impactful decision of the cycle identified
- Feed-forward inputs for the next Plan written down
The loop closes here
Plan ←──── [Review (post-ship)] ←── Ship ←── [Review (pre-ship)] ←── [Build Validation] ←── Build
│
└──→ [Plan Validation] ──→ Plan (refined) ──→ Build ...The Review gate — in both modes — is what makes solveOS a cycle, not a line. Every cycle starts smarter than the last.
Shipping is the beginning of building, not the end
Most frameworks treat shipping as the finish line. solveOS treats it as a transition point.
When something ships, two things become true simultaneously:
- This cycle is complete.
- The next cycle has new material to start from.
The post-ship Review is the mechanism that turns the outcome of one cycle into the inputs for the next. Without it, cycles are disconnected — each one starting from scratch, repeating the same assumptions, making the same mistakes.
The loop after Ship is what makes you a better builder over time, not just someone who ships things.
What "continue building" means
Continuing to build does not mean adding more features indefinitely. It means using what you learned to make the next cycle more targeted, more effective, and more aligned with what actually matters.
After shipping, three things are usually true:
- Some of what you built worked. Double down on it. The next cycle should build on the approaches that produced real results.
- Some of what you built didn't work. Fix it. The next cycle should address the gaps revealed by real-world use — not hypothetical improvements, but actual failures.
- You discovered something you didn't know when you planned. Act on it. Shipping always reveals what planning couldn't — user behaviors, edge cases, assumptions that were wrong. That knowledge is the most valuable input for the next plan.
The post-ship Review captures all three. The next Plan Brief is written from what was captured.
When to stop the loop
The loop stops when one of these is true:
- The problem is solved. The success criteria are fully met and the need no longer exists. This is rarer than most people think.
- The problem is no longer worth solving. The context changed — the audience moved on, the opportunity closed, the goal became irrelevant. Recognize this early and redirect.
- You're building from habit, not signal. If each Review cycle shows diminishing returns and the Feed Forward section is empty, the problem space may be exhausted. A new Plan on a new problem is better than incremental additions with no real impact.
The default is to continue. Stop only when the signal says to.
Revisión
Dos modos, una compuerta
La Revisión aparece en dos puntos del ciclo:
Build → [Build Validation] → [Review (pre-ship)] → Ship → [Review (post-ship)] → PlanRevisión pre-lanzamiento
Una verificación de juicio integral antes de que el resultado salga en vivo. Diferente de la Validación de la Construcción, que verifica la corrección técnica. La Revisión pre-lanzamiento verifica la intención: ¿es esto realmente lo que nos propusimos construir? ¿Sirve a la audiencia?
Revisión post-lanzamiento
Medición de resultados después de que el resultado está en vivo. ¿Funcionó en el mundo real? ¿Qué nos dice eso sobre el próximo ciclo?
Tienen propósitos diferentes y ocurren en momentos diferentes, pero comparten la misma pregunta subyacente: ¿está esto haciendo lo que se supone que debe hacer?
Revisión pre-lanzamiento
"¿Sirve esto al objetivo original y a la audiencia? ¿Estamos listos para poner esto frente a personas reales?"
La Revisión pre-lanzamiento no es una verificación técnica. La Validación de la Construcción se encarga de eso. La Revisión pre-lanzamiento es un juicio: ¿el resultado completo — como un todo — cumple la intención declarada en el Plan Brief?
Este es el momento de hacer las preguntas que las listas de verificación no capturan.
Qué verifica la Revisión pre-lanzamiento
- ¿El resultado realmente resuelve el problema planteado en el Plan Brief?
- ¿La audiencia nombrada en el brief encontraría esto útil, legible o usable?
- ¿Hay algo sobre este resultado que te avergonzaría o engañaría a su audiencia?
- ¿Estás lanzando esto porque está listo, o porque estás cansado de trabajar en ello?
La última pregunta es la más difícil y la más importante.
Cómo ejecutar una Revisión pre-lanzamiento
Lee el Plan Brief. Luego experimenta el resultado como si fueras la audiencia.
- Si construiste software: úsalo como lo usaría el usuario objetivo, no como el desarrollador que lo construyó.
- Si escribiste un artículo: léelo como alguien que no conoce el contexto.
- Si construiste un diseño: evalúalo contra el objetivo del usuario, no tus preferencias estéticas.
Luego responde:
- ¿Cuál es la única parte más débil de este resultado?
- ¿Esa debilidad bloquea el lanzamiento, o es aceptable para este ciclo?
- ¿Hay algo que, si fueras la audiencia, te haría confiar menos en esto?
Resultado de la Revisión pre-lanzamiento
## Pre-ship Review
**Reviewed by:** [Name or "Self"]
**Date:** [Date]
**Does this solve the problem stated in the Plan Brief?**
[Yes / Partially / No — with explanation]
**Would the named audience find this useful/usable/readable?**
[Yes / Partially / No — with explanation]
**Weakest part of this result:**
[Be specific. One thing.]
**Decision on that weakness:**
- [ ] Fix before shipping
- [ ] Accept for this cycle — defer to next
- [ ] It's not actually a problem
**Ship readiness:**
- [ ] Ready to Ship
- [ ] Not ready — return to BuildRevisión post-lanzamiento
"¿Realmente funcionó? ¿Qué le enseña eso al próximo ciclo?"
Lanzar algo en vivo no es lo mismo que saber que funcionó. Necesitas señal del mundo real — no la señal que predijiste en el Plan Brief, sino la señal que el mundo devolvió.
La Revisión post-lanzamiento recopila esa señal, la interpreta y la convierte en el punto de partida del próximo Plan.
Las tres preguntas de la Revisión post-lanzamiento
- ¿Funcionó? ¿Cómo se compara el resultado del mundo real con los criterios de éxito?
- ¿Por qué fue como fue? ¿Qué decisiones, suposiciones o eventos moldearon el resultado?
- ¿Qué debería hacer diferente el próximo ciclo? ¿Qué enseñó este ciclo?
Cuándo ejecutar una Revisión post-lanzamiento
| Lo que lanzaste | Cuándo revisar |
|---|---|
| Funcionalidad de software | Después de 1–2 semanas de uso real |
| Artículo o publicación | Después de 3–7 días en vivo |
| Estrategia o decisión | Después de los primeros resultados observables |
| Herramienta interna | Después del primer uso real por sus usuarios previstos |
| Experimento rápido | Dentro de las 24–48 horas |
No revises inmediatamente después de lanzar — necesitas señal real, no ruido inicial. No esperes indefinidamente — en algún momento la señal se estabiliza y el próximo ciclo ya está esperando.
Cómo ejecutar una Revisión post-lanzamiento
Mide contra los criterios de éxito
Para cada criterio de éxito del Plan Brief, responde: ¿se cumplió, y cómo lo sabes?
La evidencia debe venir de fuera de ti mismo: datos de uso, retroalimentación de usuarios reales, cambio observable de comportamiento, resultados que ocurrieron o no. Si un criterio no puede medirse con evidencia real, anótalo — significa que el criterio era demasiado vago o que el método de medición no estaba configurado.
Reflexiona sobre el ciclo
Mira el ciclo completo — Plan, Construir y Lanzar — y pregunta:
- ¿Qué funcionó como se esperaba?
- ¿Qué no funcionó como se esperaba?
- ¿Qué decisión única, tomada de otra manera, habría cambiado más el resultado?
- ¿Era el Plan Brief preciso cuando lanzaste? ¿Qué cambió?
Alimenta hacia adelante
Identifica entradas para el próximo ciclo:
- ¿Qué nuevo problema u oportunidad reveló este ciclo?
- ¿Qué se aplazó como "fuera de alcance" que ahora debe abordarse?
- ¿Qué suposición resultó ser incorrecta y debería informar el próximo Plan?
Resultado de la Revisión post-lanzamiento
## Post-ship Review
**What was shipped:** [Brief description]
**Shipped on:** [Date]
**Reviewed on:** [Date]
**Measurement**
| Success Criterion | Result | Evidence |
|------------------|--------|---------|
| [Criterion 1] | Met / Partial / Not met | [How you know] |
| [Criterion 2] | Met / Partial / Not met | [How you know] |
| [Criterion 3] | Met / Partial / Not met | [How you know] |
**Overall: did it work?**
[One or two sentences. Was the goal achieved? What does the real-world outcome say?]
**What worked**
- [Observation 1]
- [Observation 2]
**What didn't work**
- [Observation 1]
- [Observation 2]
**The decision that mattered most**
[What single decision during this cycle had the biggest impact — good or bad?]
**Feed forward: inputs for the next cycle**
- [New problem or opportunity]
- [Deferred scope item to address]
- [Wrong assumption to correct]¿Qué pasa si el resultado aún no puede medirse?
Algunos resultados tardan en aparecer. Establece una fecha de revisión al momento de lanzar, anota qué señal estás esperando, y ejecuta una Revisión parcial ahora (reflexiona sobre el ciclo) con una Revisión completa más tarde cuando la señal esté disponible.
Las partes de reflexión y medición son independientes — no omitas la reflexión porque la medición no está lista.
Usar IA en la compuerta de Revisión
Donde la IA ayuda
- Resumir retroalimentación o datos en patrones
- Cuestionar tu interpretación ("¿Es esto señal o ruido?")
- Identificar qué debería abordar el Plan Brief del próximo ciclo
- Detectar suposiciones que se repitieron a lo largo del ciclo
Donde el juicio humano debe liderar
- Decidir si el resultado fue realmente suficientemente bueno
- Interpretar señal ambigua
- Elegir en qué enfocarse en el próximo ciclo
Here is my Plan Brief: [paste brief]
Here is what I shipped: [describe output]
Here is what happened after shipping: [describe outcomes, feedback, metrics]
Did the outcome match the goal and the audience's needs?
What does the gap between expected and actual tell me?
What should I carry into the next cycle's Plan?Lista de verificación de la compuerta de Revisión
Pre-lanzamiento:
- Resultado experimentado desde la perspectiva de la audiencia, no del constructor
- Parte más débil identificada y una decisión tomada al respecto
- Lanzando por la razón correcta — está listo, no porque estés cansado de ello
- La decisión de preparación para lanzar es explícita
Post-lanzamiento:
- Esperaste señal del mundo real antes de revisar
- Cada criterio de éxito evaluado contra evidencia real
- Resultado general escrito en una o dos oraciones
- Lo que funcionó y lo que no documentado por separado
- La decisión más impactante del ciclo identificada
- Entradas de retroalimentación hacia adelante para el próximo Plan escritas
El ciclo se cierra aquí
Plan ←──── [Review (post-ship)] ←── Ship ←── [Review (pre-ship)] ←── [Build Validation] ←── Build
│
└──→ [Plan Validation] ──→ Plan (refined) ──→ Build ...La compuerta de Revisión — en ambos modos — es lo que hace de solveOS un ciclo, no una línea. Cada ciclo comienza más inteligente que el anterior.
Lanzar es el comienzo de construir, no el final
La mayoría de los marcos tratan el lanzamiento como la línea de meta. solveOS lo trata como un punto de transición.
Cuando algo se lanza, dos cosas se vuelven verdad simultáneamente:
- Este ciclo está completo.
- El próximo ciclo tiene nuevo material del que partir.
La Revisión post-lanzamiento es el mecanismo que convierte el resultado de un ciclo en las entradas del próximo. Sin ella, los ciclos están desconectados — cada uno comenzando desde cero, repitiendo las mismas suposiciones, cometiendo los mismos errores.
El ciclo después de Lanzar es lo que te hace un mejor constructor con el tiempo, no solo alguien que lanza cosas.
Qué significa "continuar construyendo"
Continuar construyendo no significa agregar más funcionalidades indefinidamente. Significa usar lo que aprendiste para hacer el próximo ciclo más dirigido, más efectivo y más alineado con lo que realmente importa.
Después de lanzar, tres cosas suelen ser ciertas:
- Parte de lo que construiste funcionó. Apuesta por ello. El próximo ciclo debe basarse en los enfoques que produjeron resultados reales.
- Parte de lo que construiste no funcionó. Corrígelo. El próximo ciclo debe abordar las brechas reveladas por el uso en el mundo real — no mejoras hipotéticas, sino fallas reales.
- Descubriste algo que no sabías cuando planificaste. Actúa en consecuencia. Lanzar siempre revela lo que la planificación no podía — comportamientos de usuarios, casos extremos, suposiciones que eran incorrectas. Ese conocimiento es la entrada más valiosa para el próximo plan.
La Revisión post-lanzamiento captura los tres. El próximo Plan Brief se escribe desde lo que se capturó.
Cuándo detener el ciclo
El ciclo se detiene cuando una de estas cosas es verdad:
- El problema está resuelto. Los criterios de éxito están completamente cumplidos y la necesidad ya no existe. Esto es más raro de lo que la mayoría piensa.
- El problema ya no vale la pena resolver. El contexto cambió — la audiencia se movió, la oportunidad se cerró, el objetivo se volvió irrelevante. Reconoce esto temprano y redirige.
- Estás construyendo por hábito, no por señal. Si cada ciclo de Revisión muestra rendimientos decrecientes y la sección de Retroalimentación hacia Adelante está vacía, el espacio del problema puede estar agotado. Un nuevo Plan sobre un nuevo problema es mejor que adiciones incrementales sin impacto real.
El valor predeterminado es continuar. Detente solo cuando la señal lo indique.