Every AI tool today makes you faster at building. CPO is the one that makes sure you're building the right thing.
/cpo structures the decision before the team commits time, headcount, or capital — with kill criteria, three concrete paths, and a persistent journal that gets smarter with every decision you log.
Standalone. No dependencies. Works in any Claude Code session. Optionally integrates with gstack for full lifecycle automation.
/cpo should we add a free tier?
[FRAME]
I'm reading this as: whether to add a free tier to accelerate top-of-funnel growth.
Inferring post-PMF SaaS — correct me if wrong.
Door type: one-way. Pricing architecture is hard to reverse once users anchor to it.
The Economic Truth is what this turns on: free tier changes your CAC math, support
load, and conversion denominator simultaneously. [judgment]
Market scan: Notion, Linear, and Vercel all run freemium — but each anchors free to
a hard limit (pages, seats, bandwidth) that creates natural upgrade pressure. [fact]
Premise checks:
· Right problem? Top-of-funnel or activation? Free tier solves discovery, not
engagement. If churn is the problem, a free tier won't fix it.
· Who benefits? Early-stage teams who won't pay upfront but convert if they see value.
· Prove it: What's your current free-trial-to-paid conversion rate, and have you
measured it by acquisition channel?
· Delay test: High. Competitors are already freemium. Every month you're not is
a month of compounding CAC disadvantage.
↳ Gate 1 — CPO stops. You confirm the frame, correct it, or reframe entirely.
[PATHS]
Given the one-way door and competitive timing, the question is how to structure
free so it pulls toward paid rather than replacing it.
We recommend B: hard-limit free tier with team-invite expansion loop.
A) Viral free tier (no limits) — maximises top-of-funnel, minimises conversion
pressure. Risks anchoring users to $0 permanently.
B) Hard-limit free tier + team-invite loop — seats cap at 3, upgrade triggered
by collaboration. Freemium as a sales motion, not a product line. ← recommended
C) Extended free trial (30 days, full access) — preserves pricing integrity,
reduces support load, but doesn't compound virally.
Before committing: stress test all three, or pick a path.
↳ Gate 2 — you pick a path, or pressure-test first. CPO holds until you reply.
[VERDICT]
Verdict: Hard-limit free tier with team-invite expansion loop (Path B).
Confidence: Medium
The conversion rate data is estimated, not measured. Validate before scaling
paid acquisition against this model.
Stop if:
1. Free-to-paid conversion stays below 8% at 30 days
2. Paid ARR growth stays below 15% QoQ after 2 quarters
3. Support ticket volume increases more than 40% within 90 days
Truth fingerprint: Dominant — Economic · Grounded — User, Strategic
Inferred — Execution [validate eng cost of seat enforcement]
What next?
D) Stress test E) Deep dive F) Reality check K) Eng brief L) Hand off
↳ Logged to ~/.cpo/decisions/free-tier-add.yaml. Kill criteria tracked. Next time
you open a pricing question, CPO opens with what's changed since this call.
git clone https://github.com/0x2kNJ/cpo.git ~/.claude/skills/cpoAdd to your CLAUDE.md:
## cpo
Available skill: /cpo
Invoke when the user is making a product or strategic decision — what to build,
whether to build it, when to kill it, or how to sequence competing priorities.No build step. No dependencies. Works immediately.
/cpo --save-context # one-time: saves your stage, model, constraints
/cpo should we launch a collaboration feature this quarter?
/cpo --go should we add a free tier? # fast path, no gates
/cpo --quick should we use Postgres or Mongo? # ≤300 words, one criterioncd ~/.claude/skills/cpo && git pull # upgradeClaude gives you an answer. CPO makes you face the real question.
Claude will tell you whether a free tier is a good idea. CPO will ask what your current conversion rate is, classify this as a one-way door, run a market scan, surface four premise checks, present three structurally distinct paths, and refuse to give a verdict without three kill criteria with specific thresholds and timeframes. Then it logs everything — so the next time you revisit pricing, you open with what changed, not from scratch.
The value isn't the answer. It's the structure that forces better questions, and the journal that turns decisions into compounding assets instead of forgotten conversations.
The example above shows the output. Here's what's running underneath it.
Every decision is assessed across five independent dimensions. CPO identifies the dominant Truth — what this decision actually turns on — before exploring paths. No decision is just a product question or just an economics question.
| Truth | What it asks |
|---|---|
| User | What does the user actually want, fear, and do? (behavior > stated preference) |
| Strategic | Where does this move us on the competitive board? |
| Economic | Does the unit economics work? CAC, LTV, payback, margin at scale? |
| Macro-Political | What regulatory, geopolitical, or ecosystem forces could override good execution? |
| Execution | Can we actually build this with our current team, runway, and tech stack? |
Every claim is tagged: [fact / assumption / inference / judgment]. You always know what's known vs. inferred.
Every decision is classified on entry — before a single path is explored.
- Two-way door — reversible. Low-magnitude two-way doors auto-suggest
--quick. - One-way door — not reversible. Auto-suggests
--deepand triggers a live market reality check: two web searches for competitors and market trends, surfaced as a one-line finding in the Frame.
Bezos framework, applied mechanically — not as decoration.
No recommendation without kill criteria. Every verdict includes three, each with a named metric, a specific threshold, and a timeframe.
This is non-negotiable by design. A recommendation without kill criteria isn't a recommendation — it's a preference.
Every session starts with a scan of recent decisions. If keywords match a prior call:
"Related prior decision: #free-tier — Gated expansion path (2026-01-15). Revisiting or new question?"
Tag any decision with #name to make it addressable. When you return to a named decision, CPO skips the fresh frame entirely and opens with a delta frame: what's changed since the last call, and whether the kill criteria have been triggered.
The journal is the thing that makes CPO a system instead of a tool. Every other AI advice interaction is stateless. This one isn't.
Every verdict is automatically written to ~/.cpo/decisions/:
decision_id: free-tier-add
date: 2026-03-22
decision: Whether to add a free tier to the SaaS product
verdict: Gated free tier with team-invite expansion loop
confidence: M
kill_criteria:
- Free-to-paid conversion below 8% at 30 days
- Paid ARR growth below 15% QoQ after 2 quarters
- Support ticket volume up more than 40% in 90 days
status: activeCPO scans the last 5 decisions at session start. Every session starts smarter than the last.
The most important feature nobody talks about: closing the loop on a decision after the fact.
/cpo --outcome #free-tier
CPO reconstructs the information state at decision time — what Truths were dominant, what was flagged as assumption vs. fact, what blind spots were identified. Then it walks through each kill criterion and asks for current data.
Three close modes:
- Walk through — criterion by criterion, recommended for one-way doors
- Quick close — one-line summary of what happened
- Decision was wrong — full decision replay to understand why
After closing, CPO surfaces the pattern across everything you've logged:
"This is your 8th closed decision. 5 succeeded, 2 pivoted, 1 failed. Most common failure mode: underestimating execution time."
That's not a feature. That's institutional memory. No team has this without CPO.
Active decisions older than 30 days are surfaced automatically at session start: "You have 2 decisions that haven't been closed — run /cpo --outcome #[id]."
| Flag | What it does |
|---|---|
| (no flag) | Standard flow: [FRAME] → [PATHS] → [VERDICT] with gates |
--go |
All three phases in one response. No gates, no premise checks. Use when you've already thought through the frame. |
--quick |
≤300 words, one kill criterion. For low-stakes decisions. |
--deep |
Full 10-section expansion: Problem → Five Truths → Options → Recommendation → Sequencing → Risks → GTM → Org → Open Questions → Decision Memo. Auto-triggered for one-way doors. |
--journal |
Shows the 10 most recent decisions. Read-only. |
--review |
Surfaces all active decisions and asks for current data against each kill criterion. Use weekly or before major check-ins. |
--outcome #name |
Close the loop on a past decision. See The journal. |
--save-context |
Bootstrap ~/.cpo/context.md — stage, model, constraint, priorities, open question. Loads automatically every session. |
--decide |
Inbound handoff from other tools. Routes a decision fork to CPO mid-workflow. See references/handoff-contract.md. |
#name |
Tag any decision for addressability. Returns a delta frame on revisit. |
CPO auto-detects your stage from context. Without context, it infers and flags every inference.
| Stage | Doctrine |
|---|---|
| Pre-PMF / seed | Do things that don't scale. First 10 users. 90/10 product. |
| Post-PMF / growth | NRR, expansion motion, compounding loops. |
| Series B+ | Rule of 40, CAC payback, path to exit. |
Solo founders — deciding what to build, whether to pivot, and when to kill a bet before it bleeds the runway.
PMs and Heads of Product — building the case upward and laterally with structured reasoning instead of slide decks.
Product-minded execs — pressure-testing strategy before it becomes roadmap, headcount, or board narrative.
Teams before high-stakes conversations — investor meetings, board reviews, strategic offsites, roadmap planning.
- Strategy dependent on a competitor making a mistake
- Roadmap with no kill criteria
- GTM with no clear ICP
- Unit economics that only work at 10x current scale
- "We have no choice" (there is always a choice)
- Technical debt rationalized as "we'll fix it after launch"
CPO works standalone. If you also use gstack, it becomes the decision gate for the full dev lifecycle.
THINKING DECIDING EXECUTING FEEDBACK
───────── ───────── ───────── ─────────
/office-hours ──► /cpo ──► /plan-eng-review ──► /retro
/plan-ceo-review ──► (the only skill ──► /build ──► /review
/retro ──► that can say ──► /ship ──► /qa
don't build) ──► /land-and-deploy ──► /canary
Every skill before CPO generates options. Every skill after it commits resources. CPO is the gate.
After [VERDICT], option L) Hand off routes to the right next skill:
| Situation | Routes to |
|---|---|
| Architecture / implementation | /plan-eng-review |
| Scope expansion | /plan-ceo-review |
| New idea, unvalidated premise | /office-hours |
| Design direction | /plan-design-review |
| Ready to build | /build |
| Ready to ship | /ship or /land-and-deploy |
| Post-launch monitoring | /canary |
| Historical pattern check | /retro |
K) Eng brief saves a structured brief to ~/.cpo/briefs/ and routes directly to /plan-eng-review.
Any gstack skill can route a decision fork to CPO via the --decide flag and a handoff block. CPO handles the decision and routes back. See references/handoff-contract.md.
CPO reads red-flag signals from other skills at session start. If severity: red, the signal surfaces in [FRAME] before the decision is framed.
| Signal | Written by | CPO surfaces when |
|---|---|---|
qa-latest.yaml |
/qa |
QA found critical failures |
review-latest.yaml |
/review |
Code review flagged blockers |
retro-latest.yaml |
/retro |
Recurring team failure pattern |
canary-latest.yaml |
/canary |
Production regressions detected |
After every verdict, CPO writes ~/.cpo/signals/cpo-latest.yaml — decision summary, door type, confidence, kill criteria count. Downstream skills read this to verify a decision exists before committing work.
Note: Signal integration requires skills to write to
~/.cpo/signals/. CPO degrades gracefully when no signals are present.
CPO discovery triggers in gstack skill files are local modifications that gstack-upgrade overwrites. After upgrading gstack, re-apply triggers manually or contribute CPO discovery upstream.
docs/gstack-skills.md — all 25+ gstack skills and their relationship to CPO.
| Path | Contents |
|---|---|
~/.cpo/context.md |
Company context saved via --save-context |
~/.cpo/decisions/*.yaml |
Decision journal entries |
~/.cpo/briefs/*.md |
Eng briefs saved via K) option |
~/.cpo/signals/*-latest.yaml |
Signals from other skills |
| File | Contents |
|---|---|
references/examples.md |
Worked examples: pricing flow, --go mobile/web decision |
references/frameworks.md |
Five Truths detail, kill criteria patterns, stage frameworks |
references/handoff-contract.md |
CPO Handoff Contract for skill authors |
When execution becomes abundant, judgment becomes scarce. Every AI tool today accelerates shipping — but bad strategy plus great execution is still failure.
The hardest problems I've encountered were never about execution. They were upstream: which opportunity is worth pursuing, which assumptions will kill you, what is the right path for this stage, and how do you know when to stop.
CPO encodes that way of working — think clearly, test tradeoffs honestly, pressure-test bets before they become expensive, and build a record that makes every future decision better informed than the last.
If more people now have the power to build, they also need better tools for deciding what deserves to be built.
CPO is not a prompt. It's a system: structured reasoning, mechanical gates, persistent memory, and a compounding decision log — working together across every major product decision.