POC Workflow
Validate the idea works. Ship something stakeholders can see and steer on. Rough is fine — speed over polish.
What you're proving
A POC answers the question: "Does this idea work?" You're not building a product yet — you're building enough to make a decision. Ship something stakeholders can see and steer on.
Overview
Who it's for
Stakeholders and decision makers. Show them working software so they can make informed decisions about what to build next.
Typical duration
3-5 days with AI assistance. Compress or extend as needed, but keep the sequence. Speed is the priority.
The rhythm
Workshop
- • Capture context, requirements, and constraints
- • Identify key stakeholders and decision makers
- • Define success criteria for the POC
- • Agree on scope boundaries
Stress Test + Artefacts
- • Project Agent stress tests requirements
- • Challenge assumptions and identify gaps
- • Produce Vision document
- • Produce Architecture document
- • Produce Requirements (Phase 1)
- • Create initial State of Play
Build POC
- • Coding Agent proposes phase plan
- • Build against agreed scope with Stack A
- • Daily check-ins on progress
- • Update State of Play as decisions are made
Client Review + Steering
- • Live review session with stakeholders
- • Demonstrate working proof
- • Capture feedback and decisions
- • Adjust scope for next phase if needed
User Feedback (Optional)
- • Test with representative users
- • Gather feedback on core assumptions
- • Validate UX decisions
- • Document findings in State of Play
AI-assisted development patterns
AI builds fast: Let the Coding Agent generate the initial proof. Focus on the core flow, not edge cases.
Human reviews for intent: Check that what's built matches what stakeholders expect. Alignment over perfection.
Iterate quickly: AI can regenerate entire features in minutes. Don't get attached to code.
Meeting cadence
Workshop
When: Start of project
Duration: 2-3 hours
Who: Project Lead, Client stakeholders, Project Agent
Capture context and requirements. Define scope.
Client Review
When: End of each phase
Duration: 1-2 hours
Who: Project Lead, Client stakeholders, Demo of work
Review progress. Make decisions. Steer next phase.
Daily Check-in
When: During build
Duration: 15 min
Who: Project Lead, Coding Agent/Dev
Progress update. Blockers. Quick decisions.
Follow-up Workshop
When: As needed
Duration: 1-2 hours
Who: Project Lead, Client, Project Agent
Address scope changes. Clarify requirements.
Quality bar
What "good enough" looks like at POC stage:
Mock data is acceptable
UI polish is secondary to function
Error handling can be basic
No authentication required
Speed over completeness
Core flow working end-to-end
Boundaries
Allowed
- • Hardcoded data
- • Simplified UI
- • Missing edge case handling
- • No tests (acceptable, not recommended)
- • Rough design and layout
Not Allowed
- • Real user data
- • Production deployment
- • Public URLs without protection
- • Building beyond agreed scope
- • Feature creep
Anti-patterns to avoid
Building features beyond scope
Stick to what was agreed. More features = more time = less validation.
Premature optimization
Don't worry about performance yet. If it's slow, that's fine for a POC.
Setting up production infrastructure
This is a proof, not a deployment. Keep infrastructure minimal.
Creating real user accounts
POCs don't need auth. Use mock users or skip login entirely.
When to run a follow-up workshop
Not every change needs a workshop. Use this guide:
Workshop NOT needed
- Minor scope adjustments within phase
- UI/UX refinements
- Bug fixes or polish
- Technical implementation decisions
Workshop needed
- Major scope change
- New stakeholders with different priorities
- Pivot in product direction
- Significant assumption proven wrong
Promotion to MVP
Before moving to MVP stage, verify:
- Stakeholder approval to proceed
- Core flows validated with stakeholders
- Learnings documented in State of Play
- Refine checkpoint passed
- Decision to invest in MVP stage documented
How to run live steering
The client review is not just a demo — it's a decision-making session. Here's how to run it:
Set expectations upfront
"We'll show progress, then make decisions together about next steps."
Demo working software
Show the actual product, not slides. Let stakeholders interact if possible.
Capture feedback live
Have State of Play open. Add decisions as they're made.
Force decisions
"Given what you've seen, should we proceed, adjust scope, or pause?"
Summarise before ending
Read back decisions. Confirm next actions. Share updated State of Play.
Capturing decisions
Every decision should be captured durably. Use the State of Play document as the single source of truth.
Decision entry template
## Decision: [Brief title] - **Date:** YYYY-MM-DD - **Context:** Why this decision was needed - **Decision:** What was decided - **Rationale:** Why this option was chosen - **Impact:** What changes as a result - **Owner:** Who is responsible for action
Roles in POC delivery
See Roles & Collaboration for detailed role definitions.
Key principle
Different AIs should own different responsibilities. A single agent trying to handle context, scope, code, and sequencing produces inconsistent results. Separate Project Agent and Coding Agent roles.
Design at POC
Use design system basics (spacing, typography) but don't polish. The goal is to validate the idea, not to win design awards.
Explore the Design System