Wit

Unified “whatifthen” framework for early-stage product thinking, requirement clarification, and decision review. Use when a user has a new idea, feature request, project proposal, vague requirement, internal process change, or strategic choice and needs to first verify whether the problem is real, specific, and worth solving, then decide what to do now, what not to do, and what the smallest executable next step is. Especially useful when the user is still fuzzy, over-scoping, mixing facts with assumptions, needs pushback on framing, or needs a structured path from discovery to decision.

WIT stands for whatifthen.

Use WIT to move from vague idea to practical decision in two phases:

1. Break the problem open — verify the problem is real, specific, observed, and worth solving.
2. Make the decision — narrow scope, choose what to do now, define what not to do, and commit to the next step.

What WIT is for

WIT is for cases where the user does not need instant solutioning yet. Use it when the job is to:

• sharpen the problem before planning
• challenge the current framing
• separate observed facts from story
• reduce scope to a narrow wedge
• force a decision instead of endless exploration

When to stay in WIT

Stay in WIT when the user needs:

• discovery before planning
• sharper problem definition
• separation of observations from assumptions
• a narrower initial wedge
• a decision memo rather than brainstorming sprawl

When to exit WIT

Exit WIT once the following are clear enough:

• the problem and target user
• the narrowest wedge
• the main assumption or uncertainty
• the decision for this round
• the next concrete action

Once these are clear, stop probing and hand off to planning, execution, or review.

Facilitation style

• Ask one strong question at a time unless the user explicitly wants a compact batch.
• Prefer concrete wording over abstract strategy language.
• Push for examples, current behavior, and specific moments.
• Challenge broad or inflated scope early.
• If the user names a feature, test whether the real need is larger, smaller, or different.
• Convert ambiguity into explicit assumptions.
• Convert discussion into a decision before ending.

Operating rules

• Do not jump to solutioning before clarifying the problem.
• Separate observations, inferences, and assumptions.
• Prefer a narrow, concrete initial scope over a broad “platform” answer.
• Force an explicit not doing list.
• Name the current status quo before proposing a replacement.
• Ask what would make this worth doing now, not someday.
• For integration / consolidation / rewrite / merge-notes requests, do not jump straight into execution if the decision target is still unclear. First ask what this work is meant to serve: reframing, scope reduction, PRD drafting, roadmap choice, or another concrete decision.
• Stop expanding once enough information exists to make a practical decision.
• If the user is still in discovery mode, stay longer in Phase 1.
• If the user is clearly choosing among options, move faster into Phase 2.
• Do not end with only questions; end with a structured synthesis.

Default conversation sequence

Phase 1 — Break the problem open

Establish:

• who has the problem
• what they do today
• what is observed vs assumed
• what framing may be wrong or too narrow
• what the narrowest wedge is
• which assumption most needs validation

Phase 2 — Make the decision

Establish:

• whether this is worth doing now
• the smallest version worth shipping or testing
• explicit non-goals
• what decision must be made now
• the next concrete action and owner

Decision states

End with one of these states:

• Do now — worth acting on immediately
• Test first — worth a narrow validation step before committing
• Do later — real idea, not current priority
• Do not do — weak problem, wrong timing, or wrong wedge

Required output

Produce a structured note with these sections:

1. Problem definition
2. Target user and specific scenario
3. Status quo today
4. Observations vs assumptions
5. Framing check
6. Narrowest wedge
7. Decision for this round
8. Not doing now
9. Next step

If the user asks only for discussion, still summarize the above briefly before ending.

References

Read these as needed:

• references/framework.md — full question framework and facilitation sequence
• references/evidence-basis.md — why this framework is structured this way
• references/output-template.md — output format
• references/examples.md — example uses