The Draft, Not the Question

The hardest part of being a PM, for me, was never knowing what we needed. It was getting there. I’d know what had to happen and roughly how, but I didn’t always have the technical skill, the domain expertise, or the bandwidth to do it myself. So I did what PMs do: I became a knowledge carrier. A spider web of ten meetings with twenty people to gather what I needed, then a second round of approvals to confirm I’d read every constraint, opportunity, and preference correctly, all while trying to keep the actual strategy from slipping out of focus.

We all say we want fewer meetings. Most of us can’t picture how, because in the traditional model, being a good PM is coordinating everyone else’s expertise and decoding it into the right investment. The meetings aren’t the bug. They’re the job. That’s the part that changed.

Making yourself average

Before this, I’d have told you I couldn’t build three GTM strategies with credible gross-margin trajectories, design a customer support function from scratch, and write evaluations for clinical AI outputs. Not without months of meetings, buy-in sessions, and paired work with each expert.

AI made me average at all three. And I want to be precise about what “AI” means here, because it wasn’t a chatbot and a clever prompt. If you’ve been following along, you’ve already met a piece of my agent system (my AI PM coaching agent), and you’ve read Gerald Trainer’s piece on the framework I built it on. Mine is a set of specialist agents with independent perspectives and shared memory, built on his published framework and then trained on my own standards: my quality bar, my sources, my definitions of done. The averageness didn’t come free with a subscription. It came out of a system I built for it.

That system made me average at GTM tradeoffs with my research and GTM agents. Average at knowing when a customer needs a human instead of an AI deflection with my customer support strategist agent. Average at quantifying what counts as a critical AI failure with my research and AI engineer agents. And average turned out to be enough. Enough to build something real and grounded before I walked into the room, to show up with a draft instead of a question, to make the expert’s job judgment instead of orientation.

The bigger shift is that you stop being paralyzed. You don’t need the meeting to get the information. You don’t need to read a fifty-page doc yourself; your agents digest it and you can work through options together. You keep moving, and you still arrive with something an expert can react to. That bias for action is half the unlock. The other half is what it does to the strategy.

Elena Verna calls this “average intelligence powered by AI,” the idea that AI drops you at a competent starting point in almost any domain, automatically. She frames it through the High-Impact Individual Contributor: the person who, with a stack of agents, ships end-to-end what used to take a team. (IC work is the new career flex, Elena Verna.)

Here’s the part I didn’t expect. When you hand an expert a finished artifact, your product strategy stays at the center; they sharpen it. In the old model, the strategy was the thing most at risk: every handoff, every meeting, every re-interpretation pulled it a few degrees off course, and by the time it came back I was defending a version of the idea I didn’t quite recognize. A draft holds the line. A telephone game doesn’t. Becoming average isn’t really about doing more yourself. It’s about being the one who keeps the strategy intact while the experts make it better.

One thing this is not: a license to skip the expert. Average gets you to a credible draft. It does not get you to final. In every example below, the expert was the difference between a good-looking artifact and a decision I’d stake the launch on. The point isn’t to replace them. It’s to stop spending their time on orientation and spend all of it on judgment.

Example 1: GTM and pricing

Building a new product meant we needed a pricing model grounded in real unit economics. Not a number lifted from competitor research, but one with a defensible gross-margin trajectory and commercial logic that held up. Old version: weeks of alignment meetings, sequential drafts from finance and GTM, me in the middle translating.

What happened instead: I worked with my agents to research comparable SaaS and pioneer AI-native product models, build the gross-margin math, stress-test it against our business model, and draft a complete proposal with a clear trajectory. I brought it to our GTM lead already grounded. He gave critical direction, and he shaped the final model, but he was hands-off on the build. Two meetings, two weeks, aligned.

His expertise wasn’t bypassed; it was elevated. Because I came in with something real, every minute went to the hard part. There was no context to establish. We started where the judgment was.

Example 2: Customer support

Launching a new AI product needs a support function built for that product, not adapted from what already exists. I needed to map every place a user might need help, find where AI could eventually deflect it, and design the team and the first role to hire.

I had no CS background. Normally that means looping in CS leadership at the start and co-designing for months. Instead I built a CS-strategy agent with full product context. It indexed the support moments across the system, mapped where deflection was viable, and produced a real proposal: structure, rationale, and the hiring profile we needed. I brought that to CS leadership for review.

They agreed with the direction, and then did the part I couldn’t: pressure-tested it against how support actually behaves under load, and took ownership of standing it up. I could get us to a credible starting point. I couldn’t certify it, and I’m not the one who runs it. Their review wasn’t a rubber stamp; it was the difference between a plausible plan and one we’d launch on.

Example 3: AI evaluations

The product’s AI outputs land in clinical records. A wrong diagnosis code or an unsafe summary isn’t a quality nit; it’s a patient-safety problem. Someone had to define what “good” and “wrong” meant before a line of it shipped. That’s a product job, but it lives in technical territory I’d never worked in.

Old version: wait for engineering to set the bar, or spend weeks in paired sessions learning enough to take part. Instead I did paired sessions with my agents. With them, I built the eval framework: red lines grounded in the actual prompt language, a severity model separating soft quality signals from zero-tolerance failures, and a hard bar for what could never reach a patient’s chart. I brought it to engineering already built. We aligned in a working session; they owned the technical implementation. The quality bar came from product. The engineering came from them.

The lesson generalizes past healthcare: any AI output with real consequences needs someone to define failure before it’s built, and that someone is usually the PM. Using well-built agents to learn eval design is what let me meet engineering at the boundary, with a framework to react to instead of a blank page.

This is the shape of the work now

Notice what those three have in common. One was commercial, one operational, one deeply technical. Three different corners of the company, none of them my home turf. That’s the point. This isn’t a story about getting lucky in one lane. It’s what the work looks like now, across every function a PM touches: you build the first version yourself, then bring the expert in to make it right.

There’s one more thing they have in common, and it’s the part people skip when they tell this story. The drafts were only as good as the system that produced them, and I held that system to a bar before I trusted it with anything. I defined quality for my agents the same way I define evals for the product: red lines they cannot cross, instructions to flag uncertainty instead of guessing through it, and a requirement to show their sources so I could check the load-bearing claims myself. Training and guardrails aren’t the glamorous part. They’re the reason the outputs were worth an expert’s time.

What this means for your work

The spider web doesn’t disappear, and the experts matter more than ever, because now the conversation starts at something real instead of a blank calendar invite. Time together is spent on decisions, not orientation.

What changes is the first leg of every piece of work. You’re not waiting for the right person to be free before you can move. You’re the first practitioner, and then you bring in the expert to make it right, and to keep you honest about the difference between average and right.

That’s the identity shift. The rest of this series is what it looks like applied to specific parts of the job.

Cait