Coach. — Senior PM review for your product docs.

Why now.

AI has made it trivially easy to ship product. What hasn't gotten easier is knowing what to ship.

Taste and judgment — what to build, why now, where it goes wrong — are the bottlenecks on most product teams.

Coach brings three decades of that judgment to your docs, so you sharpen your thinking before you start building the wrong thing.

Who this is for.

The biggest misconception is that Coach is only for PMs.

PMs will absolutely find it helpful, but AI has made it possible for everyone across the org — Engineer, Designer, Finance leader — to build products. Before building a product, you need a crisp product strategy and requirements doc to align the team around what to build and why. That's what Coach enables.

My hope is that anyone who's building a product can get value from Coach.

Who this is not for.

Coach isn't for founders or investors who want a business plan or investor memo reviewed.

It's also not for engineers who need a review of an engineering spec, or marketers looking for feedback on a marketing plan.

It's focused on the product itself — PRDs, strategy docs, roadmaps, OKRs, and one-pagers. The docs that align a team on what to build and why.

Here's how a real review reads.

Tap a tab to see the draft + the actual review.

The draft

# Smart Inbox Triage (PRD draft)

## Problem
Our users are drowning in email. We want to use AI to triage.

## Solution
Build a feature that auto-labels emails by importance.

## Metrics
- Increase DAU
- Reduce inbox time

## Risks
Model could be wrong sometimes.

The review

Problem framing

"Our users are drowning in email."

This is a verbalized headache, not a problem statement. Who is the user — a Gmail power user with 200 emails/day, or an exec with 30 high-stakes threads? Their pain looks completely different. The PRD never says.

Reframe: "Mid-career managers with 80+ daily emails miss the 3-5 messages that matter, on average twice a week, by their own self-report." Now you have something you can measure.

Success metrics

"Increase DAU. Reduce inbox time."

Activity disguised as ambition. DAU goes up if the feature is annoying enough that people keep checking. Inbox time goes down if users abandon the app. Neither is the outcome you want.

Pick a metric that only moves if the feature is actually serving the user. Try: "median time-to-first-action on high-importance threads, measured at the user level." That goes down only if your model is right AND surfacing it well.

AI-specific gaps

You don't say:

What's your eval set, and who labels truth? ("Important to whom" is the whole game.)
What's the user moment when the model is wrong? Quiet failure (mislabel) or loud failure (the user notices)?
What's the recovery? A "this wasn't important" button? An undo?

For an AI triage product, your eval plan IS your product plan. Spend a week on it before writing the second draft of this PRD.

Bottom line

Right instinct, wrong altitude. Rewrite the Problem section so an angry user can recognize themselves. Replace the metrics with one outcome metric you can move only by being right. Add an Eval section — that's where this PRD will live or die.

How it works.

1
Paste your draft. PRD, strategy, OKRs, roadmap, or one-pager.
2
I may ask 1–2 quick questions — only when context is thin.
3
Get a structured critique with quotes from your text, or a full rewrite in the canonical structure.

What I believe.

If your problem statement doesn't make the reader angry on behalf of the user, you haven't found the problem yet.

Specificity, with stakes — not category names.

Activity metrics are a confession that you don't know what success looks like.

Output metrics measure your team. Outcome metrics measure your strategy.

An AI product without an eval plan is a hallucination waiting to ship.

Define your truth set before you define your launch criteria.

Roadmaps with dates more than 8 weeks out are fiction.

Themes and milestones survive contact with reality; dates don't.

A one-pager that needs you in the room to land isn't a one-pager.

It should make the decision on its own, at speed, while you're on vacation.

OKRs that read like a project list are activity disguised as ambition.

Each key result must be independently true or false at the customer.

Why this matters here.

I led the Google AdSense and Facebook Ads product teams. I ran Product Engineering and Design at Square, and the Premium Business at DoorDash. Today I serve on the boards of Coinbase and Pinterest. I've also invested in 1,000+ companies, many of them AI-natives.

Across all these roles — PM, executive, board member, investor — I've written, rewritten and reviewed more product docs along the way than I'd care to count.

What you're reading from Coach is the playbook I'd give you in an office hour, distilled.

For AI products specifically

What I'll push on if your product is AI-native.

Model risk

What happens when the model's wrong by 5%? By 50%? Who absorbs the cost — your team, your support queue, or your user?

Eval plan

How do you know your AI is actually working — before launch, during ramp, and three months in when your distribution has drifted?

Hallucination tolerance

Which user moments accept it (drafting), which don't (sending), and what's the seam between them?

Capability creep

Are you betting on features the model can't reliably deliver yet — and what's the off-ramp if it doesn't?

FAQ.

What happens to my doc after the review?

Private, encrypted at rest. You can delete any review at any time from your Library.

Is Gokul actually writing the reviews?

No — but the playbook the model uses is built from his three decades of product leadership. Think of it as the senior-PM voice he'd use in an office hour.

Can my team use this together?

Team tier coming. For now, individual logins.