Learning Transition
Purpose: Extract what survived the last version and turn it into the next scope.
When to use: Between capability stages: after a first artifact, after a pilot, before hardening, or before handoff.
Inputs Required
- Working current artifact or capability
- Usage data and feedback
- Your own observations from building it
Process
1. Document What Worked
What should we keep? What patterns emerged that users liked? What technical decisions were correct?
2. Document Limitations
What will not scale? What shortcuts now hurt? What assumptions were wrong? What risk remains unresolved?
3. Document Functionality Gaps
What did users ask for? What did we wish existed? What edge cases did we hit?
4. Decide: Keep vs. Rebuild
For each component:
- Keep: Works well, fits future needs
- Refactor: Core is good, needs cleanup
- Rebuild: Wrong approach, start fresh
5. Write Next Scope
Based on all of the above. Be specific. "Previous version = requirements for next version."
6. Archive Current Version
Tag it, document how to run it, move on. You might need to reference it later.
Outputs
- Transition document with all the above
- Clear scope for the next version, pilot, hardening phase, or handoff
- Archived current version
Tips
- This should take 1-2 hours, not days. Don't over-document.
- Be honest about what didn't work. That's the point.
- "Rebuild" doesn't mean "bad." Sometimes the fastest path forward is starting fresh with new knowledge.
- Do not be precious. Code is cheaper than learning; keep what the learning justifies.
- The transition doc is for you. Write what's actually useful, skip the formality.
The Key Insight
Each version teaches you what the next version needs. The first artifact's limitations become pilot requirements. Pilot feedback becomes readiness scope. Readiness work becomes an operating playbook.
The transition isn't overhead—it's where the learning happens.
Next: First Useful Version | Pilot Feedback Loop | Readiness & Handoff