Together they form one loop: challenge the bet before committing, make the roadmap tangible enough to align around, then learn from what the team and the work record show. AI prepares the work. People make the calls.
Challenge the decision→Align on what changes→Learn from delivery
Outcome · from opinion to a decision with a test
Turns rough notes into a strategy document, then tests its weakest claims against positions retrieved from Lenny Rachitsky’s newsletter and podcast archive. The team sees the assumptions, the counterargument, and the evidence that would change the call.
AI preparesQuestions, a draft, and sourced counterarguments.
People decideThe bet, the evidence, and what would change the call.
How it works · six phases
The examples below zoom in on the two points where the workflow changes the decision: the questions before drafting and the challenge after.
Intake — rough notes, context, and the decision the document must make.
Clarify — four to six questions that could change the document.
Draft — choose a one-pager or narrative and explain the choice.
Challenge — ask again about the draft’s weakest claims.
Stress test — retrieve documented positions that defend and attack the decision.
Revise + deliver — change the call where needed and show what changed.
Before the draft — ask what could change it
Input · raw notes, thinking out loud
notes from the offsite + my own head. need to turn this into
a POV doc that sets our distribution strategy for next year.
- 3 platform integrations live, 2 more in build. each took ~5 months.
- BD keeps landing new platform logos. pipeline looks incredible on a slide.
- but attach is soft. ~11% of eligible businesses on Platform A actually
switch payments on. we modeled 30%+.
- every vertical wants something different — field services wants deposits
and progress billing, healthcare wants payment plans + eligibility,
restaurants want tips and fast payout
- eng lead: "we're building a different product per platform and
calling it one product"
- competitor went deep on ONE vertical, ~60% attach, now expanding out
- our whole exec narrative has been "distribution is everything,
get into every platform"
- I have been the loudest voice for breadth. genuinely not sure
I'm right anymore.
GOAL: a POV doc that sets distribution strategy for next year. I need to
decide, and I need to be able to defend the decision to my team.
It refuses to draft — and asks
What does this document commit us to: next year’s integration roadmap, the way the team is organized, or both?
Is the 11% a discovery problem, a workflow problem, or a segment problem? What evidence do we have?
What evidence would prove breadth right? Write that test into the document.
Who will read this: your team or leadership? The answer determines how much of your own doubt belongs on the page.
Is “a different product per platform” an engineering complaint, or evidence you have dismissed?
Optional depth · how the panel finds real disagreement
Evidence engine
The panel retrieves documented positions from a structured archive.
Ask a model to “pretend to be product experts” and it returns the usual advice in different voices. This pipeline retrieves specific positions and disagreements from source material.
Per-episode structured analysisClaude Sonnet reads all 624 posts and episodes and extracts frameworks, counterpoints, positions, and evidence as structured JSON. The Batch API costs about half as much, resumes cleanly, and runs for hours.
PASS 2 — DEPTH
Cross-corpus theme synthesisClaude Opus reads across the corpus and finds patterns no single source contains: 10 product-strategy themes, 10 framework families, 15 contrarian threads, and stage playbooks.
Sonnet handles volume. Opus handles judgment.
What comes out — 15,669 typed chunks
takeaway4,657
contrarian2,526
framework2,056
strategy1,654
leadership1,602
company_building1,277
growth1,261
design636
Typed chunks make retrieval precise. A challenge query searches contrarian and framework chunks instead of the whole archive.
Guest profiles345 operators, each with their frameworks, contrarian views and evidence quotes.
Topic indexTopic → people who have taken a documented position.
4,367 disagreements are already mapped. The pipeline pairs guests who take opposing positions on the same topic. It then chooses a panel for useful tension, so one person can defend the strategy while another attacks it.
At runtime
Choose one of five modes — Product Review, Academic Debate, Exec/Board Review, Dinner Party, or The Roast — and one of five heat levels, from Measured to Scorching. Together they determine how the argument runs and whether the output is a Decision Summary, Synthesis, Board Memo, or Damage Report. The example below uses Product Review at heat 4.
The full build retrieves with Voyage AI embeddings. The portable build uses static, grep-able indexes and runs offline on a work laptop.
After the draft — let the panel argue with it
The position · draft v1
“Distribution is the whole game — the provider integrated everywhere wins by default. Double the integration team, ship six new platform partners next year, and treat attach rate as a follow-on optimization problem once we have the footprint.”
↓
What the panel said
You've described multiple audiences with one use case each, not one audience with many. That's the hard version of a horizontal product, not the winnable one. And supporting customers outside your ICP feels like growth — it's the thing that most reliably prevents product-market fit.
— Jake Fuentes · ICP Specificity & Horizontal Product Success Criteria
I'll defend it partway: going broad early can be right when integration is genuinely the customer's problem. But if you're soft inside the platforms you've already launched, integration was never the constraint — the workflow was. Make it falsifiable and I'd back it.
— Dharmesh Shah · High Conviction, Low Consensus Bets
Strategy is an integrated set of choices. “Integrate with everyone” isn't a choice — it's the deferral of one. You're optimizing to be available rather than to be good.
— Annie Pearl · Playing to Win
Who is accountable for attach? BD is paid for signed platforms. Nobody owns whether businesses switch payments on. You'll get exactly what you staffed for: more logos, flat attach.
— Elena Verna · Growth Model Framework
↓
The position · draft v2
“Go deep on two verticals until we hit 40% attach in one — unless the 11% turns out to be a discovery problem rather than a workflow problem, in which case breadth is right and we should go faster. That conditional is the strategy. We can answer it in a quarter.”
The output is a different decision. v1 is a conviction with no test. v2 names the evidence that will settle it and commits to acting either way. Senior review can begin with the real assumption instead of finding it from scratch.
Outcome · from roadmap language to a shared picture of the product
Turns a stage outline into one clickable page. Strategy stays on the left and the product stays on the right. Advance a stage and both change, so product, design, engineering, and data partners respond to the same version.
AI preparesA clickable roadmap that connects each stage to the product.
People decideThe customer experience, capability order, controls, and measures.
Example — embedded business payments
Input · a stage outline
strategy: embedded payments for small businesses
stages:
crawl — accept a card payment inside the software
walk — saved methods, autopay, instant payout
run — balance, working capital, spend card
constant: the business never leaves the tool it
already runs its day in
Output · one self-contained page
Click Crawl, Walk, or Run. Watch the business move from mailed checks to
autopay to managing cash inside the platform. The capability stack grows
with each stage.
The room leaves with one shared picture: what the customer gets, what the team must build next, which controls cannot slip, and how each stage will be measured.
Safe to show at work: it is one HTML file with no server, publishing step, or external calls. Open it locally and share your screen.
Outcome · from delivery metrics to a diagnosis the team can act on
Team Pulse compares two sources: what people report in an anonymous team interview and what the work record shows. Agreement builds confidence. Gaps expose problems the team has learned to work around.
AI preparesThemes, evidence, and gaps across the two sources.
People decideWhich system problem to fix and how to measure recovery.
How it works
Ask the team — anonymously and in aggregate. Ask about pace, clarity, risk, lost time, failures, and outside dependencies.
Interview the leader — what decision this drives, and what you’re afraid it will show.
Read the record — points, cycle time, ticket descriptions, comments, reopen reasons, and board transfers.
Derive the themes — group what people wrote into problems no Jira field captures. Keep the evidence and estimate the cost.
Reconcile — mark each finding as an agreement or a gap. Lead with the gaps.
Deliver — rank the system fixes, attach the evidence, and set measures to check again.
What ticket fields miss
Counts show 58 reopened tickets. The text shows nine reopens from one retry contract, 34 tickets blocked by an unlabelled partner sandbox, and 22 bouncing across an unowned boundary. Those problems live in descriptions and comments, not Jira fields.
Output · the gap that matters
THE TEAM SAID ownership clarity 3.3/5 — their 4th concern
THE TICKETS SHOW boundary confusion is the 2nd biggest
cost on the board, ~14 days per 6 sprints
→ the team is under-reporting the thing costing it most
The sample dashboard shows the pulse and ticket record side by side. Open a theme to read the ticket text behind it.
The team can act on a cause, not a mood. The recommendation stays attached to the interview and ticket evidence that produced it.
This measures the team and the system. It never names, ranks, or scores individuals, and the pulse is reported only in aggregate. Use it to evaluate one person and the answers become less honest. The result becomes less useful.
Each example turns a useful AI interaction into an operating practice the team can teach, inspect, adapt, and improve.
Start with a decisionName the choice, audience, and consequence before asking the AI to produce anything.
Bring trusted contextUse source material, team input, and work data instead of relying on a model’s general memory.
Make the work inspectableShow the questions, evidence, assumptions, and tradeoffs behind the output.
Keep human ownership clearAI prepares and synthesizes. People validate the evidence, choose the tradeoff, and own the action.
Across the team: product frames the decision; design makes it tangible; engineering tests feasibility and controls; data defines the evidence; leaders own the tradeoff.
Take the whole set
Three reusable AI playbooks, the examples, and the brief. The brief explains how to present each workflow, when to run it live, and how to answer pushback.