Three points in the product cycle where AI does the work and you keep the judgment. Each has a worked example and a skill package you can download and run.
Rough notes → a strategy doc → stress-tested against Lenny’s archive
Turns messy notes into a strategy doc. Then it hands the draft to a panel of real operators — pulled from Lenny Rachitsky’s newsletter and podcast archive — to find the holes before you commit your team to anything.
The writing is the cheap part. The value is being interrogated before you draft, and argued with after.
How it works
Intake — your notes, your context, a one-line goal.
Clarify — the four to six questions that change the doc most, asked before it writes a word.
Draft — a one-pager or a narrative, and why it picked that one.
Clarify again — this time aimed at its own weakest claims.
Stress test — the panel, then a rewrite.
Step 2 — it interrogates before it writes
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 doc actually commit us to — next year's integration roadmap, or how the team is organized?
Is the 11% a discovery problem, a workflow problem, or a segment problem? Do we know, or are we assuming?
What would have to be true for breadth to be the right answer? I want to write the falsifier, not just the position.
Who reads this — your team or your leadership? It changes how much of your own doubt belongs on the page.
Is “a different product per platform” an engineering complaint, or a strategic fact you've been discounting?
Step 5 — what the panel changed
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.”
Same author, same evidence, one hour later. The panel didn’t polish the prose — it turned a slogan into a claim that can be proven wrong. v1 was a conviction with no test attached. v2 names the diagnosis that settles it, and commits to moving either way. And the panel didn’t simply overrule him: one member defended breadth, and the condition on that defense became the strategy.
Crawl / walk / run — with a working prototype beside each stage
Turns a strategy into one page people can click. Stages across the top; the strategy on the left, a working prototype on the right. Move to the next stage and both change together — the product gets richer, and you see exactly what it cost to build. People stop arguing about bullet points and start reacting to the thing itself.
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 through Crawl → Walk → Run and watch a business go from chasing a
check, to getting paid automatically, to running its money inside the
platform — with the capabilities it took stacking up as you go.
A checkup with two instruments — the interview and the panels
A doctor doesn’t diagnose from the patient’s account alone, or from the bloodwork alone. This does both: it interviews the team about how the work actually feels and runs, then reads their ticket history — including the free text nobody reports on. The diagnosis is where the two disagree.
How it works
Interview the team — anonymous and aggregate. How it feels: pace, clarity, whether they’d flag a risk early. How it runs: where time is lost, what breaks, which outside dependencies block them.
Interview the leader — what decision this drives, and what you’re afraid it will show.
Read the record — not just points and cycle time, but ticket descriptions, comments, reopen reasons, and where work bounced between boards.
Derive the themes — group what people actually wrote into problems no Jira field captures, each with its evidence and an estimated cost.
Reconcile — mark every finding agreed or gap, and lead with the gaps.
The part only a model can do
Counting tickets tells you a team reopened 58 of 412. Reading them tells you nine of those reopens are one unfixed retry contract, that 34 tickets are waiting on a partner sandbox nobody has a label for, and that 22 keep bouncing across an unowned boundary between two squads. None of that exists in a field. It only exists in what people typed at 6pm while blocked.
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
A full worked dashboard — vitals, both instruments side by side, four derived themes you can expand to the ticket text behind them, and the agreements and gaps.
Built for teams and systems, never individuals. No one is named, ranked, or scored, and the pulse is reported only in aggregate. The moment a tool like this is used to evaluate a person, teams stop answering honestly and the instrument stops working. That’s a measurement argument, not just an ethical one.
All three skills, the worked example, and the brief: how to frame each one, when to run it live versus show the output, and what to say when someone pushes back.