User Context Briefing (CQ)¶
Owner: Vi | Updated: 2026-02-05
Purpose¶
Devs must understand WHO they're building for, not just WHAT to build. Without user empathy, devs interpret everything through their own lens and build the wrong thing.
The problem: Devs have never seen users, never talked to them, never listened to what they actually say. They build based on assumptions, not reality.
Why This Matters¶
| Without User Context | With User Context |
|---|---|
| "I think users want X" | "I heard a user say they need X" |
| Build for imaginary user | Build for real user |
| Interpret through own lens | Interpret through user's lens |
| Surprised when users don't like it | Already knew what users needed |
The goal: Devs should be able to explain what the user is trying to do and why—not just what feature to build.
The Professor vs Student Problem¶
Watching someone else scope a product is easy. Doing it yourself is hard.
| Professor Mode (Bad) | Student Mode (Good) |
|---|---|
| Erik explains what to build | Dev figures out what to build |
| Dev just executes specs | Dev understands the "why" |
| If spec is unclear, dev is stuck | Dev can fill in gaps themselves |
| No ownership | Full ownership |
We want devs who can think like mini product managers. That requires understanding users deeply.
Minimum User Exposure Requirements¶
Every CQ dev must complete these before being fully productive:
1. Watch at Least One User Interview¶
Options: - Sit in live on a user interview (preferred) - Watch recorded user interview (interview watch party)
What to pay attention to: - What words does the user use? - What problems do they describe? - What frustrates them? - What do they wish existed? - What surprised you?
After watching, write:
## User Interview Notes
**User type:** [Role, industry, company size]
**Main problem they have:** [In their words]
**What they're trying to accomplish:** [Goal]
**What surprised me:** [Something I didn't expect]
**How this changes how I build:** [Insight]
2. Know the User Personas¶
Be able to answer: - Who uses CQ? - What industry are they in? - What's their job title/role? - What are they trying to accomplish? - What's their technical level? - What do they care about most?
If you can't answer these: You're not ready to build features.
3. Understand the Domain¶
CQ exists in a specific domain. Devs should understand: - What problem does CQ solve? - Why do users pay for this? - What did users do before CQ? - Who are the competitors and why do users choose us?
Interview Watch Party¶
What: Team watches a recorded user interview together When: Monthly, or when a new dev joins Who: All CQ devs Duration: 30-60 minutes
Format: 1. Watch interview together (or key clips) 2. Discuss as a group: - What did you notice? - What surprised you? - How does this change how we build? 3. Document key insights
Output: Shared understanding of who we're building for
User Context Checklist¶
Before a dev is considered "ramped up" on CQ:
- Watched at least one user interview (live or recorded)
- Can describe the typical CQ user (role, industry, goals)
- Can explain what problem CQ solves in user's words
- Understands basic domain concepts
- Has written user interview notes
Vi tracks: Which devs have completed user context requirements
Ongoing User Exposure¶
This isn't one-time. Devs should continuously hear from users:
| Activity | Frequency |
|---|---|
| Watch user interview | At least once |
| Read user feedback summaries | When shared |
| Ask Ryan/Erik about user context | When starting new feature |
| Attend interview watch party | When scheduled |
When Starting a New Feature¶
Before building, dev should ask:
- Who is this for? (Which user persona?)
- What are they trying to do? (Their goal, not our feature)
- Why do they need this? (The problem)
- What do they do today? (Current workaround)
- How will they know it's working? (Success criteria from user POV)
If you can't answer these: Talk to Ryan or Erik before starting.
The Lens Problem¶
Bad: Dev interprets requirements through their own lens - "I would want this to work like..." - "I think users probably..." - "In my experience..."
Good: Dev interprets through user's lens - "The user we interviewed said..." - "Based on how users describe the problem..." - "Users in this industry typically..."
How to fix: Always tie decisions back to user evidence, not personal opinion.
Who to Ask About Users¶
| Question | Ask |
|---|---|
| What do users need? | Ryan or Erik (they understand best) |
| How do users talk about this? | User interview recordings |
| What's the priority? | Ryan or Erik |
| How should UI work? | Study competitors + user feedback |
Note: Vi may not always have deep product understanding. For user context, go to Ryan or Erik.
Red Flags¶
| Red Flag | What It Means |
|---|---|
| "I think users want..." (with no evidence) | Dev is guessing |
| Building feature without knowing who uses it | Missing context |
| Surprised by user feedback | Wasn't connected to users |
| "This is how I would use it" | Own lens, not user lens |
| Can't explain user's problem | Doesn't understand "why" |
Integration with Other SOPs¶
| SOP | Connection |
|---|---|
| Pre-Build Research | Research includes understanding user context |
| Alpha-Beta-Final | User understanding deepens through phases |
| Stakeholder Feedback | Feedback often includes user context |
FAQ¶
Q: What if we don't have user interviews recorded? A: Ask Ryan or Erik to include a dev in the next user call. Or ask them to share key user quotes and feedback.
Q: What if I already know users from another project? A: CQ users may be different. Confirm your assumptions with Ryan or Erik.
Q: How do I build empathy if I can't talk to users? A: Watch recordings, read feedback, ask Ryan/Erik to share user stories. Direct contact is best, but secondhand is better than nothing.
Q: What if Vi gives me user context that seems wrong? A: Verify with Ryan or Erik. They have the deepest understanding.
Summary¶
| Principle | Why |
|---|---|
| Watch user interviews | Hear users in their own words |
| Understand the domain | Context makes features better |
| Ask "who is this for?" | Every feature has a user |
| Use user's lens, not own lens | Build what THEY need |
| When in doubt, ask Ryan/Erik | They know users best |
You can't build for users you don't understand.