Plan Interview

Plan Interview Skill

Transform rough plans into comprehensive, implementation-ready specifications through adaptive, structured interviews.

When to Use

• Converting a plan or idea into a detailed specification
• Gathering requirements through structured questioning
• Transforming rough documentation into implementation-ready specs
• Ensuring all edge cases, risks, and stakeholders are considered before implementation

Available Components

Command: /plan-interview:interview [plan-file]

Adaptive interview that calibrates depth based on plan complexity:

Usage:

/plan-interview:interview docs/feature-plan.md
# Output: docs/feature-plan-spec.md

Agent: spec-reviewer

Autonomous quality analysis of specifications across 4 dimensions:

• Completeness (25 pts) - All sections populated?
• Consistency (25 pts) - No contradictions?
• Clarity (25 pts) - No ambiguous language?
• Edge Cases (25 pts) - Error handling defined?

Triggers when you say "review my spec" or "check specification quality".

Interview Phases

1. Foundations & Scope - Stakeholders, success criteria, constraints, MVP scope 2. Technical Deep-Dive - Architecture, data models, scalability, security 3. User Experience - Personas, flows, cognitive load, error recovery 4. Risks & Tradeoffs - Risk categorization, blast radius, contingency plans 5. Operationalization - Testing, deployment, monitoring 6. Wrap-Up (optional) - Only for complex plans with remaining gaps

Interview Philosophy

Core Principle: Depth over breadth. Better to deeply understand critical aspects than superficially cover everything.

Key Techniques:

• Non-obvious questions - Skip what the plan already answers
• Edge probing - What happens in unusual cases?
• Assumption surfacing - Make implicit beliefs explicit
• Contradiction detection - Flag when answers don't align
• Adaptive depth - Probe deeper on complex areas, move faster on clear ones

Spec Output Structure

Generated specs include:

• Overview (problem, solution, success criteria, stakeholders)
• Functional and non-functional requirements
• Technical design (architecture, data models, APIs, security)
• User experience (personas, flows, states, edge cases)
• Risks and mitigations (risk register, tradeoffs, contingency plans)
• Implementation notes (key decisions, dependencies, migration)
• Operationalization (testing, deployment, monitoring)
• Open questions and out-of-scope items
• Phasing (MVP vs future)

References

Load these for deeper guidance during interviews:

• references/phase-1-clarifications.md - Foundations questions and pitfalls
• references/phase-2-technical.md - Architecture discussion patterns
• references/phase-3-ux.md - Persona development, UX patterns
• references/phase-4-risks.md - Risk assessment frameworks
• references/interview-techniques.md - Cross-cutting interview skills
• references/example-spec.md - Annotated high-quality spec example

Example Specification

This is an annotated example of a high-quality specification produced by the plan-interview process.

---

Task Assignment System Specification

Annotation: Title is clear and specific. Not "Task System" but "Task Assignment System" - scope is clear.

Overview

• Problem: Team leads spend 30+ minutes daily manually assigning tasks based on team member availability and skills. This is error-prone and creates bottlenecks when leads are unavailable.

• Solution: An automated task assignment engine that matches tasks to team members based on skills, current workload, and availability, with human override capability.

• Success Criteria:
• Reduce average assignment time from 30 minutes to under 2 minutes
• 80% of auto-assignments accepted without modification
• Team leads report task assignment as "easy" (7+ on 10-point scale)

• Key Stakeholders:
• Primary: Team leads (assign tasks)
• Secondary: Team members (receive assignments)
• Impacted: Project managers (visibility into assignments)

Annotation: Success criteria are MEASURABLE. Not "faster" but "under 2 minutes". Not "users like it" but "7+ on 10-point scale".

---

Detailed Requirements

Functional Requirements

1. FR-1: System MUST display unassigned tasks in priority order 2. FR-2: System MUST suggest top 3 team members for each task based on skill match 3. FR-3: System MUST show each member's current workload (tasks, hours) 4. FR-4: System MUST allow one-click assignment from suggestions 5. FR-5: System MUST allow manual override to assign any team member 6. FR-6: System MUST notify assigned member within 30 seconds via Slack 7. FR-7: System MUST log all assignments with timestamp, assigner, reasoning 8. FR-8: System MUST allow reassignment with reason capture 9. FR-9: System MUST display assignment history for each task 10. FR-10: System MUST support bulk assignment of multiple tasks

Annotation: Each requirement is numbered for traceability. "MUST" vs "SHOULD" vs "MAY" is deliberate. Requirements are testable.

Non-Functional Requirements

1. NFR-1: Page load time MUST be under 2 seconds (p95) 2. NFR-2: Assignment suggestions MUST appear within 500ms 3. NFR-3: System MUST handle 100 concurrent users 4. NFR-4: System MUST be available 99.5% during business hours 5. NFR-5: All data MUST be encrypted at rest and in transit 6. NFR-6: System MUST meet WCAG 2.1 AA accessibility standards

---

Technical Design

Architecture

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   React     │────▶│   Node.js   │────▶│  PostgreSQL │
│   Frontend  │     │   API       │     │  Database   │
└─────────────┘     └─────────────┘     └─────────────┘
                           │
                           ▼
                    ┌─────────────┐
                    │   Slack     │
                    │   Webhook   │
                    └─────────────┘

Components:

• Frontend: React SPA with TypeScript, hosted on Cloudflare Pages
• API: Node.js/Express, hosted on Cloudflare Workers
• Database: PostgreSQL on Neon Serverless
• Notifications: Slack Incoming Webhooks

Annotation: Architecture is visual AND textual. Technology choices are specific with hosting locations.

Data Models

-- Core entities
tasks (
  id UUID PRIMARY KEY,
  title VARCHAR(255) NOT NULL,
  description TEXT,
  priority INT (1-5),
  required_skills TEXT[], -- array of skill tags
  estimated_hours DECIMAL,
  status ENUM('unassigned', 'assigned', 'in_progress', 'complete'),
  created_at TIMESTAMP,
  due_date TIMESTAMP
)

team_members (
  id UUID PRIMARY KEY,
  name VARCHAR(255),
  email VARCHAR(255),
  skills TEXT[],
  max_weekly_hours INT DEFAULT 40,
  slack_id VARCHAR(50)
)

assignments (
  id UUID PRIMARY KEY,
  task_id UUID REFERENCES tasks,
  member_id UUID REFERENCES team_members,
  assigned_by UUID REFERENCES team_members,
  assigned_at TIMESTAMP,
  assignment_reason TEXT, -- "auto" or free text
  unassigned_at TIMESTAMP, -- null if current
  unassign_reason TEXT
)

Annotation: Actual schema, not just "we'll have a tasks table". Shows relationships and key fields.

APIs & Integrations

External Integration: Slack Incoming Webhook

• Trigger: On assignment (FR-6)
• Payload: task title, due date, link to task
• Retry: 3 attempts with exponential backoff

Scalability Considerations

• Current estimate: 50 concurrent users, 500 tasks/day
• Bottleneck: Suggestion algorithm (O(n*m) for n tasks, m members)
• Mitigation: Cache member skills/workload, invalidate on change
• Future scaling: If >1000 tasks/day, add Redis caching layer

Security Design

• Authentication: SSO via company Okta
• Authorization: Role-based (admin, team_lead, member)
• Data protection: All PII encrypted, audit log immutable
• API security: JWT tokens, 1-hour expiry, refresh tokens

---

User Experience

User Personas

Sarah - Team Lead (Primary)

• 8 years experience, manages 12 people
• Assigns 20-30 tasks per day
• Values speed and accuracy
• Uses desktop 95% of time
• Quote: "I just want the right person on the right task without thinking about it."

Alex - Team Member (Secondary)

• 2 years experience, receives 3-5 tasks per day
• Wants clear expectations and context
• Primarily mobile for notifications
• Quote: "I hate getting tasks with no context."

User Flows

Primary Flow: Assign a Single Task 1. Sarah sees unassigned tasks dashboard (default view) 2. Clicks on high-priority task 3. Sees task details + 3 suggested assignees with skill match % 4. Clicks "Assign" on top suggestion 5. Sees confirmation toast 6. Task moves to "assigned" list

Time target: Under 30 seconds for experienced user

UI States

Edge Cases

• No matching skills: Show all members, sort by workload, display warning
• All members overloaded: Show warning banner, allow override with confirmation
• Member on PTO: Exclude from suggestions, show PTO badge if selected
• Task has no skills tagged: Prompt to add skills before suggesting

---

Risks & Mitigations

Risk Register

Accepted Tradeoffs

1. Skills are self-reported: We accept potential inaccuracy because surveying all skills would delay launch by 3 weeks. Mitigation: Skill verification in Phase 2.

2. No mobile-optimized view: Team leads primarily use desktop. Mobile will wait for Phase 2 based on usage data.

3. English only: 95% of users are English speakers. Localization deferred to Phase 3.

Contingency Plans

• If adoption <50% after 2 weeks: Hold feedback sessions, prioritize top 3 complaints
• If performance unacceptable: Disable auto-suggestions, fall back to manual assignment

---

Implementation Notes

Key Decisions

Dependencies

• External: Okta SSO (exists), Slack workspace (exists), Neon account (needs setup)
• Internal: HR system skill export (needs coordination with HR)
• Blocking: Cannot launch until SSO integration complete

Migration Plan

1. Week 1: Shadow mode - system runs alongside manual process 2. Week 2: Opt-in - team leads can try new system 3. Week 3: Default - new system is default, old available 4. Week 4: Cutover - old system deprecated

---

Operationalization

Testing Strategy

• Unit tests: 80% coverage for business logic
• Integration tests: API endpoints, database operations
• E2E tests: Critical paths (assign, reassign, notify)
• Manual testing: Accessibility, edge cases

Deployment Plan

• Environment: Staging → Production
• Feature flag: ENABLE_TASK_ASSIGNMENT_V2
• Rollout: 10% → 50% → 100% over 1 week
• Rollback: Disable feature flag, no data migration needed

Monitoring & Observability

• Metrics: Assignment time (p50, p95), suggestion acceptance rate, API latency
• Dashboards: Datadog - assignment volume, error rates, performance
• Alerts: API error rate >1%, latency p95 >2s, Slack webhook failures

---

Open Questions

1. Skill taxonomy: Who owns the master skill list? How do we add new skills? 2. Cross-team assignments: Can leads assign tasks to other teams? If so, what approval is needed? 3. Workload calculation: Does 40 hours include meetings or just task work?

Annotation: Open questions are genuine unknowns, not forgotten requirements. Each needs a decision before implementation can complete.

---

Out of Scope

• Time tracking for assigned tasks
• Task creation (use existing system)
• Performance reviews based on assignments
• AI-generated task descriptions
• Mobile app (web responsive only)

Annotation: Clear boundaries prevent scope creep. "Out of scope" is as important as "in scope".

---

Phasing

Phase 1: MVP (8 weeks)

• FR-1 through FR-7
• Single team pilot
• Success: 60% suggestion acceptance

Phase 2: Enhancement (4 weeks)

• FR-8 through FR-10
• Mobile optimization
• Skill verification system
• Expand to all teams

Phase 3: Future

• Cross-team assignment
• ML-improved suggestions
• Localization
• Advanced analytics

Interview Techniques - Deep Dive

Cross-cutting skills for conducting effective specification interviews.

---

Contradiction Detection

Pattern Recognition

Watch for contradictions between:

• What the plan says vs what the person says
• Earlier answers vs later answers
• Stated priorities vs implied priorities
• Written requirements vs verbal clarifications

Surfacing Technique

When you detect a contradiction:

1. State both positions neutrally: "Earlier you mentioned [X], but just now you said [Y]."

2. Ask for clarification without judgment: "Help me understand how these fit together."

3. Accept either resolution: "Which is correct, or are they both true in different contexts?"

Example Phrases

• "I want to make sure I understand correctly. You said [X] earlier, and now [Y]. Which takes priority?"
• "These seem to conflict. Is there something I'm missing that reconciles them?"
• "The plan says [X], but you're describing [Y]. Should we update the plan?"

---

Follow-Up Probing

The "5 Whys" Technique

Keep asking "why" to get to root causes: 1. "Why do you need that feature?" 2. "Why is that important?" 3. "Why does that matter to users?" 4. "Why can't they do that today?" 5. "Why is now the right time to solve this?"

The "Give Me An Example" Technique

Abstract answers become concrete with examples:

• "Can you give me a specific example of when that would happen?"
• "Walk me through a real scenario where a user would do that."
• "What would that look like in practice?"

The "What If" Technique

Test edge cases and assumptions:

• "What if [assumption] is wrong?"
• "What if [edge case] happens?"
• "What if users don't do what we expect?"

The "How Would You Know" Technique

Make success measurable:

• "How would you know if this is working?"
• "What would you see that tells you it's broken?"
• "What metric would prove this was worth building?"

---

Thread Tracking

The Open Loop Method

Keep a mental (or actual) list of topics to return to: 1. When an answer reveals complexity, note it 2. Continue with current topic to completion 3. Return to open loops before concluding

Example Phrases

• "I want to come back to something you mentioned earlier about [X]."
• "Before we move on, let's revisit the point about [Y]."
• "That reminds me of something you said earlier. Can we connect those?"

When to Open a Thread

• Answer mentions something unexpected
• Answer is vague and needs detail later
• Answer conflicts with earlier information
• Answer reveals a risk or constraint

---

Assumption Surfacing

Technique

Make implicit beliefs explicit: 1. Listen for assumptions embedded in statements 2. Ask about them directly without judgment 3. Document confirmed assumptions

Common Hidden Assumptions

• "Users will..." (How do you know?)
• "The system can..." (Has this been verified?)
• "We'll have time to..." (What if we don't?)
• "They'll understand..." (What if they don't?)

Example Phrases

• "It sounds like you're assuming [X]. Is that correct?"
• "What if [assumption] turns out to be wrong?"
• "Have we validated that [assumption] is true?"
• "What evidence do we have for [assumption]?"

---

Summarization Checkpoints

When to Summarize

• After every 3-5 questions
• When transitioning between phases
• After complex or contradictory discussions
• Before making major conclusions

Summarization Template

"Let me confirm my understanding:

• [Key point 1]
• [Key point 2]
• [Key point 3]

Is that accurate, or did I miss something?"

Benefits of Summarizing

• Confirms understanding before building on it
• Gives the interviewee a chance to correct
• Shows you're actively listening
• Creates natural transitions between topics

---

Adaptive Depth

Reading Complexity Signals

Go Deeper When:

• Answers reveal unexpected complexity
• Interviewee uses hedging language ("maybe", "probably")
• Multiple stakeholders have different views
• Answer contradicts previous information
• High-risk areas are mentioned casually

Move Faster When:

• Topic is well-documented in the plan
• Answers are confident and consistent
• Area is low-risk and straightforward
• Interviewee's expertise is clear

Depth Adjustment Phrases

To Go Deeper:

• "Let's explore that more. Tell me about..."
• "That sounds important. Can you elaborate?"
• "I want to make sure I understand the nuances here."

To Move Faster:

• "That's clear. Let's move on to..."
• "Good, that matches what the plan says. Next question..."
• "That makes sense. What about..."

---

Handling Difficult Responses

Vague Answers

• "Can you be more specific?"
• "What would that look like in practice?"
• "Give me a concrete example."

"I Don't Know" Answers

• "Who would know?"
• "What would you need to find out?"
• "What's your best guess, and how confident are you?"

Overly Long Answers

• "Let me make sure I captured the key point: [summary]"
• "That's helpful. The core of it is [summary], right?"
• "To summarize that..."

Defensive Responses

• "I'm not questioning the decision, just trying to understand it fully."
• "This is great context. Help me understand [specific aspect]."
• "I want to document this accurately. Could you clarify..."

---

Question Sequencing

Funnel Technique

Start broad, then narrow: 1. "Tell me about the overall goal." 2. "What are the main components?" 3. "Let's dive into [specific component]." 4. "What about [specific edge case within that component]?"

Reverse Funnel

Start specific, then broaden: 1. "Walk me through this specific scenario." 2. "How does this relate to the broader system?" 3. "What other scenarios follow a similar pattern?" 4. "What's the general principle here?"

Phase Transitions

When moving between interview phases:

• "Great, I have a good understanding of [previous phase topic]. Now let's talk about [new phase topic]."
• "Before we move on, is there anything else about [previous topic] I should know?"

---

Signs the Interview Is Going Well

• Answers are getting more specific, not vaguer
• Interviewee is actively thinking, not reciting
• New information is emerging, not just repeating the plan
• Contradictions are being resolved, not ignored
• Both parties are learning something

Signs the Interview Needs Adjustment

• Interviewee seems frustrated or defensive
• Answers are becoming more vague
• Same ground is being covered repeatedly
• Important topics are being avoided
• Time is running out with major gaps remaining

Phase 1: Foundations & Scope - Deep Dive

Extended guidance for the most critical interview phase. Phase 1 establishes the foundation for everything that follows.

---

Stakeholder Analysis Questions

Primary Stakeholders:

• "Who is the primary user of this feature? Describe a typical day in their life."
• "Who will maintain this after it's built? What's their technical level?"
• "Who signs off on this being 'done'? What are their success criteria?"

Affected Parties:

• "Who else interacts with the systems this touches? How will they be affected?"
• "Who will complain loudest if this breaks? Why?"
• "Are there any regulatory bodies or compliance requirements we need to satisfy?"

Power Dynamics:

• "Who has veto power over decisions? What would trigger a veto?"
• "Are there any political considerations we should be aware of?"
• "Who controls the budget and timeline? What are their constraints?"

---

Success/Failure Criteria Questions

Defining Success:

• "How will we measure success 30 days after launch? 90 days?"
• "What specific metric would tell you this is working as intended?"
• "What does 'good enough' look like vs 'excellent'?"

Defining Failure:

• "What would make you consider this project a failure?"
• "What are the early warning signs that we're heading in the wrong direction?"
• "If this fails, what's the fallback plan?"

Minimum Viability:

• "What's the absolute minimum this needs to do to be useful?"
• "If we could only ship one feature, which would it be?"
• "What would users do without this? How painful is the current workaround?"

---

Constraint Exploration Questions

Hard Constraints:

• "What absolutely cannot change? (deadline, budget, technology stack, etc.)"
• "Are there regulatory or compliance requirements we must meet?"
• "What technical limitations are we working within?"

Soft Constraints:

• "What would be difficult but possible to change?"
• "What's the cost of extending the timeline by 2 weeks? 4 weeks?"
• "What resources could we get if we really needed them?"

Resource Limits:

• "What's the budget? Is there flexibility?"
• "How many people can work on this? What are their skill levels?"
• "What's the hard deadline? What happens if we miss it?"

---

Prior Art Investigation Questions

Previous Attempts:

• "Has anyone tried to solve this problem before? What happened?"
• "What can we learn from those attempts?"
• "Why is now the right time to try again?"

Existing Solutions:

• "What solutions exist in the market? Why aren't we using them?"
• "What would it cost to buy vs build?"
• "Have competitors solved this? How?"

Lessons Learned:

• "What mistakes have we made in similar projects?"
• "What worked well that we should repeat?"
• "Who in the organization has relevant experience we should tap?"

---

Dependency Mapping Questions

Prerequisites:

• "What must exist before we can start building?"
• "What infrastructure, data, or systems do we need?"
• "Are there any blocking dependencies?"

Downstream Impact:

• "What other systems or teams depend on this completing?"
• "What breaks if we're late?"
• "Who needs to be notified when we ship?"

External Dependencies:

• "What external APIs or services do we rely on?"
• "What's the SLA for those dependencies?"
• "What happens if they change or go down?"

---

MVP Scope Definition Questions

Core Value:

• "What's the one thing this MUST do to be valuable?"
• "If you had to ship tomorrow, what would you include?"
• "What's the simplest version that would solve the problem?"

Deferrable Features:

• "What features seem essential but could actually wait?"
• "What's the cost of not having feature X in v1?"
• "What would users do as a workaround?"

Scope Boundaries:

• "Where exactly does this feature end?"
• "What adjacent problems are we explicitly NOT solving?"
• "What requests should we expect to push back on?"

---

Common Pitfalls to Avoid

1. Assuming Shared Understanding

• Terms like "user", "performance", "fast" mean different things to different people
• Always ask: "When you say X, what specifically do you mean?"

2. Accepting Vague Success Criteria

• "Make it better" is not a success criterion
• Push for specific, measurable outcomes

3. Ignoring Political Constraints

• Technical solutions can be politically impossible
• Ask about stakeholder dynamics early

4. Skipping Prior Art

• Someone has probably tried this before
• Learning from their failures saves time

5. Underestimating Dependencies

• Dependencies always take longer than expected
• Ask about what's blocking and what's blocked

---

Red Flags to Watch For

• Conflicting stakeholder goals: Different people want different things
• No clear success criteria: "We'll know it when we see it"
• Unrealistic constraints: Impossible timeline, budget, or scope
• Ignored prior failures: "This time will be different" without explanation
• Circular dependencies: A depends on B depends on A

When you encounter these, probe deeper and surface the conflict explicitly.

Phase 2: Technical Deep-Dive - Deep Dive

Extended guidance for technical architecture and engineering decisions.

---

Architecture Decision Questions

High-Level Structure:

• "Can you draw the system architecture in words? What are the main components?"
• "Why did you choose this architecture over alternatives like [X] or [Y]?"
• "What patterns are we using? (microservices, monolith, event-driven, etc.)"

Component Breakdown:

• "What are the responsibilities of each component?"
• "How do components communicate with each other?"
• "Which components are most critical? Which are most complex?"

Technology Choices:

• "Why these specific technologies? What were the alternatives?"
• "What's the team's experience level with these technologies?"
• "Are there any technologies we're avoiding? Why?"

---

Data Model & State Questions

Core Entities:

• "What are the key data entities in this system?"
• "How do these entities relate to each other?"
• "What's the cardinality of these relationships? (1:1, 1:many, many:many)"

State Management:

• "Where does state live? (client, server, database, cache)"
• "How is state synchronized across components?"
• "What's the source of truth for each piece of data?"

Data Lifecycle:

• "How is data created, updated, and deleted?"
• "What's the data retention policy?"
• "How do we handle data migrations?"

---

Scalability Questions

Growth Scenarios:

• "What happens if we get 10x the expected load? 100x?"
• "Where are the bottlenecks in the current design?"
• "What breaks first under load?"

Scaling Strategy:

• "How do we scale horizontally vs vertically?"
• "What's the scaling unit? (requests, users, data volume)"
• "What's the cost of scaling? Linear, logarithmic, exponential?"

Performance Requirements:

• "What's the target latency? (p50, p95, p99)"
• "What's the expected throughput? (requests/second)"
• "What's the maximum acceptable downtime?"

---

Integration Questions

External Systems:

• "What external APIs or services do we integrate with?"
• "What are the contracts we must honor?"
• "What's the SLA for these integrations?"

Failure Modes:

• "What happens when an integration fails?"
• "How do we retry? Circuit break? Fallback?"
• "How do we notify users of integration failures?"

Data Exchange:

• "What data do we send/receive from external systems?"
• "What's the data format? (JSON, XML, protobuf, etc.)"
• "How do we handle schema changes in external systems?"

---

Technical Debt Questions

Conscious Compromises:

• "What shortcuts are we taking? Why are they acceptable?"
• "What will we regret in 6 months? 2 years?"
• "What's the plan to address this debt?"

Cost Assessment:

• "What's the ongoing cost of this technical debt?"
• "What's the cost to fix it later vs now?"
• "What triggers the decision to pay down debt?"

Risk of Debt:

• "What happens if we never address this debt?"
• "Could this debt become a blocking issue?"
• "Who is aware of and accepts this debt?"

---

Observability Questions

Monitoring:

• "What metrics will we track?"
• "What dashboards do we need?"
• "What's the baseline we're comparing against?"

Alerting:

• "What conditions trigger alerts?"
• "Who gets alerted? What's the escalation path?"
• "What's the expected response time?"

Debugging:

• "How do we debug production issues?"
• "What logs do we need? What format?"
• "How do we trace requests across services?"

---

Security Questions

Threat Model:

• "What are we protecting against?"
• "Who are the potential attackers? What are their capabilities?"
• "What data is most sensitive?"

Authentication & Authorization:

• "How do users authenticate?"
• "How do we manage sessions/tokens?"
• "What authorization model? (RBAC, ABAC, etc.)"

Data Protection:

• "What data is encrypted? At rest? In transit?"
• "How are secrets managed?"
• "What's the data classification scheme?"

---

Architecture Discussion Patterns

The "Why Not" Pattern

When someone proposes architecture A, ask:

• "Why not [simpler alternative]?"
• "What would break if we used [alternative]?"
• "What's the cost of switching later if A doesn't work?"

The "At Scale" Pattern

For any component, ask:

• "What happens to this at 10x scale?"
• "What's the first thing that breaks?"
• "How would we know it's breaking?"

The "Failure Mode" Pattern

For any integration or dependency, ask:

• "What happens when this fails?"
• "How do we detect the failure?"
• "How do we recover?"

The "New Hire" Pattern

Imagine explaining this to a new hire:

• "How would you explain this architecture to someone new?"
• "What's the learning curve?"
• "What documentation do they need?"

---

Red Flags to Watch For

• Premature optimization: Solving scaling problems you don't have yet
• Résumé-driven development: Choosing technology for career advancement, not fit
• Missing error handling: Happy path only, no failure consideration
• God components: One component does too much
• Distributed monolith: Microservices without the benefits
• No observability plan: "We'll add monitoring later"

When you encounter these, probe deeper and surface the concern explicitly.

Phase 3: User Experience - Deep Dive

Extended guidance for understanding users and designing great experiences.

---

User Persona Questions

Primary Users:

• "Describe a specific person who will use this. What's their name, role, daily routine?"
• "What's their technical sophistication level?"
• "What are they trying to accomplish when they use this?"

User Segments:

• "How do different user types differ in their needs?"
• "What do novice users need that experts don't?"
• "What do power users need that casual users don't?"

User Context:

• "Where are users when they use this? (desk, mobile, noisy environment)"
• "What device(s) do they use?"
• "How much time do they have? (rushed vs. focused)"

---

User Flow Questions

Happy Path:

• "Walk me through the ideal user journey from start to finish."
• "What are the key decision points?"
• "How long should this take? What's the target?"

Alternative Paths:

• "What are the common variations of this flow?"
• "What do users do when they change their mind midway?"
• "How do users recover from mistakes?"

Edge Cases:

• "What happens when the user has no data yet?"
• "What happens when the user has too much data?"
• "What happens when the user is interrupted midway?"

---

UI State Questions

Loading States:

• "What do users see while waiting?"
• "How do we indicate progress? (spinner, skeleton, percentage)"
• "What's the maximum acceptable wait time?"

Empty States:

• "What do users see when there's no data?"
• "How do we guide them to populate it?"
• "What's the first-run experience?"

Error States:

• "What errors can users encounter?"
• "What do the error messages say? (exact copy)"
• "What actions can users take to recover?"

Success States:

• "How do we confirm success?"
• "What's the celebration moment?"
• "What's the next action after success?"

---

Cognitive Load Questions

Mental Models:

• "What concepts must users understand to use this?"
• "What metaphors are we using? (folders, cards, streams)"
• "What prior experience can users draw on?"

Learning Curve:

• "How long until a new user is productive?"
• "What's the 'aha moment' when things click?"
• "What's the most confusing part for new users?"

Memory Load:

• "How much must users remember vs. what's shown?"
• "What context do users need to maintain across sessions?"
• "How do we reduce cognitive burden?"

---

Emotion Mapping Questions

Emotional Journey:

• "How should users feel at each step of the flow?"
• "Where might users feel frustrated? Confused? Delighted?"
• "What moments should feel magical?"

Trust Building:

• "What builds user trust in this product?"
• "What might make users suspicious or hesitant?"
• "How do we communicate reliability and safety?"

Delight Opportunities:

• "Where can we exceed expectations?"
• "What small touches would surprise and delight?"
• "What makes this feel premium vs commodity?"

---

Failure Recovery Questions

Error Prevention:

• "How do we prevent errors before they happen?"
• "What validation happens in real-time vs on submit?"
• "How do we guide users toward valid input?"

Error Messages:

• "What exactly does the error message say?"
• "Does it explain what went wrong AND how to fix it?"
• "Is the tone helpful, not blaming?"

Undo & Recovery:

• "Can users undo actions? Which ones?"
• "How long do they have to undo?"
• "What happens when undo isn't possible?"

---

Accessibility Questions

Standards:

• "What WCAG level are we targeting? (A, AA, AAA)"
• "Are there legal requirements? (ADA, Section 508)"
• "What assistive technologies must we support?"

Keyboard Navigation:

• "Can everything be done with keyboard only?"
• "What's the tab order?"
• "Are there keyboard shortcuts for power users?"

Screen Readers:

• "What will screen readers announce for each element?"
• "Are images described with alt text?"
• "Are dynamic changes announced?"

Visual Design:

• "What's the contrast ratio for text?"
• "Can users resize text without breaking layout?"
• "Is color alone never used to convey meaning?"

---

Persona Development Template

## Persona: [Name]

**Demographics**:
- Role: [Job title/role]
- Age range: [X-Y]
- Technical skill: [Novice/Intermediate/Expert]

**Goals**:
- Primary goal: [What they're trying to accomplish]
- Secondary goals: [Other objectives]

**Pain Points**:
- Current frustration: [What's painful today]
- Fear: [What they want to avoid]

**Context**:
- Device: [Desktop/Mobile/Tablet]
- Environment: [Office/Home/On-the-go]
- Time available: [Rushed/Focused]

**Quote**: "[Something this persona might say]"

---

Red Flags to Watch For

• No specific personas: "Our users are everyone"
• Assumption of expertise: Designing for yourself, not actual users
• Happy path only: No consideration of errors or edge cases
• Ignoring accessibility: "We'll add it later"
• No user research: "We know what users want"
• Feature bloat: Adding features without removing complexity

When you encounter these, probe deeper and advocate for the user.

Phase 4: Risks & Tradeoffs - Deep Dive

Extended guidance for surfacing, assessing, and mitigating risks.

---

Risk Categorization Questions

Technical Risks:

• "What technical unknowns could derail us?"
• "What parts of the implementation are we least confident about?"
• "What dependencies are most likely to cause problems?"

Business Risks:

• "What if users don't want this feature?"
• "What if the market changes while we're building?"
• "What competitive risks are we facing?"

Operational Risks:

• "Can we maintain this long-term with our team?"
• "What happens when key people leave?"
• "Do we have the operational capacity for this?"

Security Risks:

• "What's the worst-case security breach?"
• "What data could be exposed or corrupted?"
• "What would attackers target?"

Timeline Risks:

• "What could cause us to miss the deadline?"
• "What dependencies have we underestimated?"
• "What scope could creep?"

---

Impact/Probability Assessment

Impact Assessment:

• "If this risk materializes, what's the damage?"
• "Is it recoverable or catastrophic?"
• "Who is affected? How many people?"

Probability Assessment:

• "How likely is this to happen? (1-10 scale)"
• "What would increase/decrease the probability?"
• "Have we seen this happen before in similar projects?"

Prioritization Matrix:

Risk Questions by Priority:

• "What are our top 3 critical risks?"
• "What are we choosing to accept? Why?"
• "What's our risk appetite for this project?"

---

Blast Radius Analysis Questions

Failure Containment:

• "If this component fails, what else breaks?"
• "Can failures be isolated?"
• "What's the blast radius of a worst-case failure?"

Cascade Scenarios:

• "Walk me through a cascade failure scenario."
• "What's the domino effect if [critical component] fails?"
• "How do we prevent cascades?"

Recovery Time:

• "How long to recover from a failure?"
• "What's the recovery process?"
• "Who needs to be involved in recovery?"

---

Reversibility Assessment Questions

One-Way Doors:

• "What decisions are irreversible?"
• "What data migrations can't be undone?"
• "What contracts are we locked into?"

Two-Way Doors:

• "What decisions can we easily reverse?"
• "What's the cost of reversing each decision?"
• "How long does reversal take?"

Decision Timing:

• "When must we commit to irreversible decisions?"
• "Can we defer any one-way decisions?"
• "What information would change our decision?"

---

Monitoring Triggers Questions

Early Warning Signs:

• "What signals indicate a risk is materializing?"
• "What metrics should we watch?"
• "How early can we detect problems?"

Thresholds & Alerts:

• "At what threshold do we take action?"
• "Who gets alerted when thresholds are crossed?"
• "What's the response time expectation?"

Escalation Path:

• "When do we escalate to leadership?"
• "What decisions can the team make autonomously?"
• "What requires executive approval?"

---

Contingency Planning Questions

Plan B Development:

• "For each critical risk, what's Plan B?"
• "How quickly can we switch to Plan B?"
• "What's the cost of switching?"

Decision Authority:

• "Who makes the call to activate Plan B?"
• "What information triggers the decision?"
• "What's pre-approved vs needs approval?"

Resource Allocation:

• "Do we have resources reserved for contingencies?"
• "What can we deprioritize to address emergencies?"
• "What's the contingency budget (time, money, people)?"

---

Known Tradeoffs Questions

Conscious Compromises:

• "What are we deliberately choosing NOT to do?"
• "Why is this tradeoff acceptable?"
• "What would change our minds?"

Tradeoff Documentation:

• "Who is aware of and has accepted this tradeoff?"
• "Is this documented somewhere?"
• "What's the plan to revisit this decision?"

Tradeoff Implications:

• "What are the downstream effects of this tradeoff?"
• "Who is negatively affected? Do they know?"
• "What's the long-term cost?"

---

Risk Register Template

## Risk: [Name]

**Category**: Technical / Business / Operational / Security / Timeline

**Description**: [What could go wrong]

**Probability**: High / Medium / Low
**Impact**: High / Medium / Low
**Priority**: Critical / Important / Monitor / Accept

**Trigger Signs**: [Early warning signals]

**Mitigation Plan**: [How we prevent or reduce this risk]

**Contingency Plan**: [What we do if it happens]

**Owner**: [Who is responsible]

**Last Reviewed**: [Date]

---

Tradeoff Documentation Template

## Tradeoff: [Name]

**Decision**: [What we decided]

**Alternatives Considered**:
1. [Alternative A] - Rejected because [reason]
2. [Alternative B] - Rejected because [reason]

**Why This Choice**: [Rationale for the decision]

**Accepted Downsides**:
- [Downside 1]
- [Downside 2]

**Conditions for Revisiting**: [When we would reconsider]

**Stakeholders Consulted**: [Who agreed to this]

**Date**: [When decided]

---

Red Flags to Watch For

• No identified risks: Every project has risks
• All low probability: Optimism bias
• No mitigation plans: "We'll deal with it if it happens"
• Single point of failure: One person, one system, one vendor
• Undocumented tradeoffs: Decisions made but not recorded
• No contingency plans: "What's Plan B?" "We don't need one"

When you encounter these, probe deeper and insist on realistic risk assessment.