---
name: "orientation-brief"
description: "Fast, stakeholder-ready product strategy brief (Clarity/Character/Craft, unnamed): answer immediately, separate observed from inferred, invite correction."
---

# Orientation Brief

A fast, two-page strategic read on a product problem. Same engine as the 3 C's (Clarity, Character, Craft), none of the jargon. The goal is a document good enough that someone forwards it without explaining what it is.

**Philosophy: produce, then refine.** Write the best answer possible from available context immediately. Be explicit about what was seen versus what was guessed, and invite correction afterward. Speed to a good answer is the product. Depth is one follow-up question away, not a prerequisite.

**The brief is a hypothesis, not a verdict.** A coherent story is not the same as an accurate one. The brief exists to give a team something to test and correct together, so it must always show its evidence, name its alternatives, and say what would prove it wrong.

## The Shape of the Output

Always two pages. Page one is the whole answer. Page two is optional and only for people who want to see the reasoning.

### Page 1: The Brief (this is the deliverable)

No section may require framework knowledge to understand. Keep the whole page to roughly one screen or one printed page. If it runs long, cut; don't shrink the font.

```
[Title: name the problem/decision in plain language, not the product's internal
name for it]

## The Real Problem
**What we saw:** [1-2 sentences of concrete observations: quotes, behaviors,
numbers, requests. Only things actually present in the context provided.]
**What we think it means:** [1-2 sentences. The fundamental truth under the
surface request, stripped of product jargon. Clearly an interpretation.]
**Ruled out:** [One line: the most tempting alternative explanation, and why
it doesn't hold.]
*This is my best read of the situation, not a verified finding. Tell me what
I've missed or misread.*

## What Success Looks Like
[2-3 sentences: the conviction or obligation at stake, stated as belief. How
do we want people to feel when this product is at its best?]
**This over that:** [One mandatory tradeoff: "We choose X over Y." If nothing
is being given up, the brief isn't finished.]
*This is my best read on your values, not yours yet. Tell me where I've got
it wrong.*

## Product Strategy
[2-4 sentences: the pattern or approach that solves this class of problem, not
just today's version of it. Concrete enough to picture.]
**Working within:** [One line: the real constraints (technical, timeline,
people, politics) this has to survive.]

## How We'll Know
**It's working if:** [1-2 signals that the intended feeling or outcome is
actually happening. Behavior, metric, or something a user would say.]
**We're wrong if:** [The specific observation that would tell us this read of
the problem is mistaken, so we change course instead of defending it.]

## Mission / Vision
[One quotable, memorable sentence. The line repeated in a hallway or a Slack
thread. It should stand alone if screenshotted, and it should settle a real
disagreement between two reasonable people on the team.]
```

### Page 2: The Thinking Behind It (optional, for anyone who wants more)

Only produce this if asked, or attach it by default but clearly marked skippable. Match whatever the person seems to want. Keep the framework mostly implicit here too; it's fine to surface it lightly if useful.

```
## The Reasoning

**Why this is the real problem:** [The evidence and context that led here. The
surface explanation this replaces, and why it's insufficient.]

**Other explanations I considered:** [2-3 rival readings of the same evidence.
For each: what would have to be true for it to be right, and what in the
context argues against it. Be fair to them; this is where the old model gets
taken apart.]

**Seen vs. inferred:** [Which parts of the brief rest on direct observation
and which rest on inference. Name the single most load-bearing inference, the
one that would collapse the brief if wrong.]

**About "What Success Looks Like":** [Flag plainly that this was inferred, not
declared. Name the 1-2 cues in the context that suggested it. Offer the short
version of the values check: How do you want people to feel using this at its
best? What does this choose when it has to choose? What does it owe the people
who depend on it?]

**Why this pattern, not another one:** [What this rules out. What future
related problems it also solves. What it would cost to ignore it and patch
symptoms instead.]

**Worth pressure-testing:** [1-2 sharp follow-up questions: an edge case, a
contested assumption, a place where the stated values and the strategy might
be in tension.]
```

## Process

1. **Gather what's given.** Feature request, notes, a one-line ask: work with whatever arrives. Don't stall on missing context; make a reasonable inference and flag it rather than asking a round of clarifying questions first. Ask only if the request is too thin to say anything real (e.g., a single ambiguous word).
2. **Separate observation from interpretation.** Before concluding anything, list what is actually in the context: what people said, did, asked for, or measured. Everything else is inference. Never let an inference appear in "What we saw."
3. **Find the real problem (Clarity).** Strip the ask down to what's actually true. Generate at least one rival explanation and test it against the evidence before settling. If you can't say the problem without the product's internal vocabulary, keep going. If the evidence is thin, say so on the page rather than sounding more certain than the material allows.
4. **Infer the values, explicitly flagged (Character).** Construct the most plausible conviction or obligation from context: the tone of the request, who it's for, what's been said before. State it with confidence, but always mark it as inferred and invite correction. Always commit to a "this over that" tradeoff. Never present inferred values as settled.
5. **Find the pattern (Craft).** Solve the class of problem, not the instance. Make sure it's traceable back to the stated values: if the pattern doesn't protect the stated value, one of the two is wrong, so loop back. Note the real constraints it has to live within. Then ask "How do we measure this?" and point to the feelings and outcomes we said we care about, plus the observation that would show we're wrong.
6. **Write Page 1 first, alone.** Read it as the stakeholder with 90 seconds. Cut anything that doesn't earn its place.
7. **Offer Page 2 rather than forcing it,** unless the person has already signaled they want depth.
8. **After delivery, treat every reply as calibration.** If the person corrects the values guess, that correction is now declared and carried forward through the conversation and any related briefs. If they add or challenge an observation, update "What we saw" and re-check whether "What we think it means" and "We're wrong if" still hold. Say what changed.

## Using It With a Team

When the brief is going to a group rather than one person, the draft can anchor people and turn a discussion into an edit. To keep the team forming its own view:
- Before sharing the brief, ask each person to write down, in a sentence or two, how they want users to feel when this product is at its best, and what they think the real problem is.
- Share the brief second and compare. Disagreements between the individual answers and the brief are the most useful output of the exercise.
- Treat "We're wrong if" as a shared tripwire: agree in advance who checks it and when.

## What Changed From the Full 3 C's Framework, and Why

- **No upfront values intake.** The full framework refuses to write Character without the builder answering questions first. This version writes an inferred version immediately and treats the human's reaction as the intake. Trade-off: faster and more shareable, at the cost of occasionally guessing wrong, which is why the flags and correction invitations are non-negotiable.
- **No framework vocabulary on the page.** "Clarity/Character/Craft" is the engine, not the interface. A stakeholder shouldn't need a glossary to read the brief.
- **Fixed two-page shape.** The constraint forces the cut. If it doesn't fit, it wasn't essential to the decision.
- **A memorable closing line is mandatory.** It's what makes people forward the brief. It must also be precise enough to settle a real disagreement; memorable alone isn't enough.
- **Evidence and self-doubt are on the page.** Observation is separated from inference, a rival explanation is named, and a "we're wrong if" is stated. Without these, a fluent draft can lock a team into a confident but unverified reading.

Reach for the full 3cs-framework skill instead when: the decision is genuinely foundational (new product, company-level strategy doc), the person explicitly wants the multi-question intake, or a first inferred brief generated real disagreement and the group needs to work through it properly rather than get another guess.

## Quality Check Before Sending Page 1

- [ ] Could a stakeholder who's never heard of this project understand every sentence?
- [ ] Zero uses of "Clarity," "Character," "Craft," or "3 C's"
- [ ] "What we saw" contains only things actually present in the provided context
- [ ] "What we think it means" is not just the request restated
- [ ] A rival explanation is named under "Ruled out"
- [ ] Both "The Real Problem" and "What Success Looks Like" carry the inferred-and-invite-correction flag
- [ ] "This over that" names something genuinely given up
- [ ] Product Strategy describes a pattern, not a feature or a technical detail, and names real constraints
- [ ] "How We'll Know" includes a signal for the intended feeling and a specific "we're wrong if"
- [ ] Mission / Vision would survive being screenshotted with no other context, and would settle a real disagreement between two reasonable designers
- [ ] The whole page is one screen or one page. If not, cut; don't shrink