POC v2 Playbook
Purpose: Get real users on it. Collect feedback. Answer: "Is it useful?"
Duration: 1 week
When to use: After POC v1 proves the mechanics work.
Inputs Required
- Working POC v1
- List of limitations from v1
- Identified pilot users (2-5 people who will actually use it)
Principles
Focus: Is it useful?
Real users start using it daily. Not a demo. Not a review session. Actual use in their actual workflow.
Built-in feedback mechanism. Users should be able to report issues without leaving the app. Add a feedback widget, a "report bug" button, something frictionless.
Architecture evolves with the version. v2 choices serve v2 needs. If something needs rebuilding for v3, rebuild it—that's the model working correctly.
Daily feedback sessions. 15-minute syncs to review what users encountered. Quick decisions on small fixes.
Process
Day 1-2: Prepare for Users
- Add feedback widget
- Fix the most obvious v1 limitations
- Create minimal onboarding (enough to get started)
- Set up usage tracking (basic analytics)
Day 3-5: Users Live
- Pilot users start using daily
- Daily feedback sessions (see Daily Feedback Session)
- Rapid fixes based on feedback
- Document patterns in what users struggle with
Day 6-7: Consolidate
- Review all feedback
- Categorize: quick fixes vs. architectural changes vs. feature requests
- Draft v3 requirements
Outputs
- Working POC v2 with active users
- Usage data (who's using it, how often, what features)
- Feedback log (categorized)
- Input for v3 requirements
- Decision: proceed to v3 or pivot?
Tips
- 2-5 pilot users is enough. More users = more noise, not more signal at this stage.
- Pick users who will actually use it, not users who will be polite about it.
- If users stop using it after day 2, that's critical feedback. Find out why.
- "Is it useful?" is harder than "Does it work?" Prepare for uncomfortable answers.
- Don't fix everything. Some feedback is v3 scope, some is out of scope entirely.
Next: Version Transition → POC v3 Playbook