office-hours

name	office-hours
description	Product interrogation before commitment. Challenges whether you're solving the right problem for the right user at the right time. Use when starting a feature, exploring an idea, or before writing a spec. Triggers: "should I build this", "office hours", "is this worth building", "product check", "challenge this idea".
argument-hint	<one-line description of what you're thinking about building>

Office Hours: Product Interrogation

Challenge whether to build something before committing. Not brainstorming (test the idea you brought). Not a spec (use /spec-out after). Not council (product decisions, not technical).

Positioning

• Upstream of council: office-hours challenges whether to build; council challenges how to build
• Upstream of /spec-out: office-hours challenges the why; spec-out clarifies the what
• Flow: /office-hours → /spec-out or /design → council seats

Process

1. Frame the idea

Restate the user's idea in one sentence. Confirm you understand before questioning.

2. Seven-question framework

Ask questions one at a time. Wait for the answer before asking the next. Follow up on weak or vague answers before moving on.

Three acts, adaptive questioning:

Act I — The User

Q1. Who specifically? Name the person, not a persona or segment. "Mobile developers who deploy to TestFlight weekly" — not "developers." If the user can't name someone specific, stay on this question.

Q2. What job are they hiring this to do? A verb and outcome in the user's language, not the builder's. Apply the Jobs-to-Be-Done framework (see references/jobs-to-be-done.md). The job exists independent of your solution.

Act II — The Problem

Q3. What happens if you don't build this? Concrete cost to the user. Not "they'd be disappointed" — what breaks, what takes longer, what stays impossible? If the answer is "nothing much," that's a signal.

Q4. What are you assuming about user behavior? The riskiest assumption, stated as a falsifiable claim. "I assume users will check this dashboard daily" is testable. "Users want better tools" is not.

Act III — The Bet

Q5. Smallest version that tests the hypothesis? Not MVP — the experiment. What can you build in days (not weeks) that proves or disproves the riskiest assumption from Q4?

Q6. What would make you kill this in 3 months? A measurable kill signal. This question is non-negotiable — always ask it. If the user can't define failure, they can't define success.

Q7. How much time is this worth? Shape Up appetite: not how long it will take, but how much you'd bet. "Two days of effort, max" is an appetite. "However long it takes" is a blank check.

Adaptation rules

• Minimum 3 questions: Q1, Q3, Q6 (always asked)
• Maximum 7 questions: all seven
• Stay on Act I if the user is poorly defined — don't advance until Q1 has a real person
• Skip to Q6 if the problem is hypothetical or the user seems to be exploring rather than committing
• Skip Q2 if the user already described the job clearly in their framing
• Skip Q5 if the user already described a minimal experiment
• Skip Q7 if the user volunteered a time constraint

3. Synthesize the verdict

After questioning, produce the verdict using this template:

## Office Hours: {Title}

**Date:** {YYYY-MM-DD}
**Verdict:** BUILD | NARROW | DEFER | KILL

### The User

{Who, specifically — from Q1}

### The Job

{What they're hiring this to do — from Q2}

### The Hypothesis

{The riskiest assumption, stated as falsifiable claim — from Q4}

### The Bet

{Smallest experiment + appetite — from Q5/Q7}

### Kill Signal

{What kills this in 3 months — from Q6}

### What I Noticed

{Patterns, contradictions, unstated assumptions surfaced during questioning.
Be direct. This is the value-add beyond the user's own answers.}

Verdict criteria

Verdict	Criteria
BUILD	User real, problem concrete, hypothesis falsifiable, appetite proportional
NARROW	Good instincts, scope outpaces evidence — reduce to what you can prove
DEFER	Interesting, insufficient evidence — name what to learn first
KILL	No real user, hypothetical problem, or unfalsifiable bet — stop here

Anti-patterns

• Generating ideas: test the idea the user brought, don't brainstorm alternatives (use /brainstorm for that)
• Writing specs: the verdict points to next steps, it doesn't define them
• Being encouraging: the value is honest challenge, not validation
• Asking all seven questions mechanically: adapt to what the user reveals