Pressure-test a spec against your strategy before the team commits

A spec can be excellent and still be a mistake. Good evidence, clear outcomes, clean verification — and yet it serves a customer you decided not to serve, or pulls toward a market you chose not to chase. Engineering review catches the technical risk; design review catches the experience gaps. The founder review is different: it's the check that this work is on-strategy before the team spends a sprint on it. Pathmode gives strategy a place to live — the workspace constitution — so the check is concrete, not a gut feeling.

The input

A draft IntentSpec the team is ready to commit to, and a workspace constitution where you've encoded the strategy: who you serve, what you don't build, the bets you've made and the ones you've ruled out.

The flow

1. Read the spec's objective against the constitution. Does this advance a bet you've actually placed? The constitution holds your non-negotiables — if the spec quietly violates one ("we don't build for enterprise yet"), this is where it shows.

2. Check who it serves. Trace the linked evidence to the customer it represents. Is that your ICP, or a vocal edge you'd decided to deprioritize? A spec well-anchored to the wrong customer is still the wrong spec.

3. Name the opportunity cost. Every yes is a no to something else in the queue. Ask what this spec displaces and whether that trade is one you'd defend. Write the reasoning into the spec so the team inherits the why, not just the verdict.

4. Encode anything new back into the constitution. If the review surfaces a rule you'd never written down ("we say no to one-off integrations"), add it. Every agent and reviewer downstream — via get_constitution — then works inside it automatically.

The output

A go/no-go grounded in strategy, not vibes:

• On-strategy confirmed, or the misalignment named before a sprint is spent
• The right customer verified through the spec's evidence chain
• Opportunity cost made explicit, so the trade is deliberate
• Strategy captured as rules, so the next spec gets checked automatically, not just this one

Why this beats catching it at the demo

Catching a strategy mismatch at the sprint demo means the work is built, the team is invested, and the conversation is about sunk cost instead of fit. The founder review moves that judgment to before the commit, where "let's not" costs five minutes — and encoding it in the constitution means you don't have to be the one who catches it next time.

Try it yourself

1. Open a draft spec the team is about to commit to
2. Read its objective and linked evidence against your workspace constitution
3. Name out loud what this spec displaces in the queue
4. Add any unwritten rule the review surfaced to the constitution

Related

• Use case: Decide what the team builds next — without a roadmap meeting
• Use case: Review a spec for implementation risk before it enters the build queue
• Playbook: Product Constitution Rules