Three moments in the product lifecycle where AI does real work — and in every one, it sharpens judgment instead of replacing it. Pick one below: each has a worked example and a skill package you can download and run.
Rough thinking → a strategy doc → stress-tested against Lenny's Podcast archive
Turns messy notes and a half-formed conviction into a strategy document — then runs it past a panel of real product thinkers, drawn from Lenny Rachitsky's newsletter and podcast archive, to find the holes before you commit your team to a direction. The value isn't the writing. It's the interrogation up front and the stress test at the end.
How it works
Intake — reads your notes, context, and one-line goal.
Clarify — asks the 4–6 questions that most change the doc, before writing a word.
Draft — one-pager or narrative, and says which it chose and why.
Clarify again — targets its own weakest claims.
Stress test — runs the draft past the panel, then revises.
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 — the stress test, and what it actually did
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.”
That's the whole value. 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 decides it, and commits to changing course in either direction. Note that the panel didn't simply overrule him: one panelist defended breadth, and the condition attached to that defense became the strategy.
Crawl / walk / run — with a working prototype beside each stage
Turns a strategy into one interactive page. A stage selector on top; below it, the strategy on the left and a clickable prototype on the right. Advance the stage and both evolve together — the experience gets richer, the platform capabilities stack up, the value compounds. A room stops debating bullet points and aligns on the actual product.
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 required capabilities stacking as you go.
Is our effort actually going where we said our priorities are?
Pulls historical Jira data and answers two questions leaders lose sleep over: is our time aligned to our stated priorities, and where are the early-warning hotspots. It interviews you before and after seeing the data, so the dashboard serves a decision instead of dumping charts.
How it works
Interview first — what decision, which priorities, what counts as a hotspot.
Pull — epics, points, labels, cycle time, reopens, WIP by team.
Interview again — comes back with what's measurable and what's surprising.
Dashboard — effort vs. intent, hotspots, and a “so what” narrative.
Example
Output · dashboard excerpt
EFFORT vs INTENT (story points)
fraud ........... 41%
mobile parity ... 22%
onboarding ...... 9% ← priority #2, effort #4
unmapped ........ 28%
HOTSPOT
Team Atlas · reopen rate 3.1× median · WIP up 4 wks
So what: either onboarding isn't really priority #2, or it's under-resourced — and there's 28% of unmapped work to reallocate from. The Atlas trend is a signal worth a look, not a verdict.
Deliberate design choice: team- and system-level only, never individuals. It's an early-warning tool to protect delivery and people — not a way to rank anyone.
All three skill packages, the worked example, and the full brief — naming, live-vs-pre-made tradeoffs, talking points, and answers for when senior leaders push back.