Nearly Everyone Can Ship Now

I’ve rewritten what I screen for in product managers.

Not because the old screen was broken. Because it was answering questions that stopped being hard.

The loop most of us run — product sense, a prioritization exercise, a metrics case — was built for a world where execution was the expensive part, and the scarce person was the one who could hold a team on a single heading long enough to ship. Neither of those is reliably true anymore.

What’s left is a lot shorter. Three things: the spec, the bar, and the shape. I’ve stopped pretending the rest predicts much

.

The Spec — Can They Specify?

Not “do they write good PRDs.” Almost everyone writes an adequate PRD, and the good ones are usually good in ways that don’t matter.

I mean something narrower: can they describe a thing precisely enough that it survives being built by someone faster than them?

This used to be forgiving work. You’d hand over a spec with soft edges and an engineer would fill the gaps with judgment, taste, and a Slack message asking what you actually meant. The ambiguity got resolved by a person who cared about the outcome and had context you’d forgotten to write down.

That safety net is thinning. Specifications now get executed at a speed that outruns the clarifying conversation. Every ambiguity you leave will get resolved. Just not by you.

I learned this at home. This summer I built and shipped a consumer product for my own family — real users, real installs, real support burden, no team. It was the first time in years that a bad specification had nowhere to go but into the product. Nobody caught the requirement I hadn’t thought through. Every gap I left got filled immediately and confidently by something that didn’t know it was guessing.

Here’s what surprised me: how much of my spec had always been written by other people.

So the screen is simple. Hand them something genuinely underspecified and watch what happens before they propose anything. Weak candidates propose. They’re pattern-matching to the nearest familiar solution — a real skill, just not this one. Strong candidates narrow. They ask what decision this is meant to enable, who’s on the other end of it, what happens at the edges, what we’re deliberately choosing not to build.

The tell is the questions, not the answer.

The Bar — Do They Know What Done Means?

When output is expensive, “done” gets negotiated by exhaustion. You ship when the sprint ends and the team is tired. The constraint does the deciding for you.

When output is cheap, nothing stops you. You can keep going indefinitely, and plenty of people do — polishing, expanding, adding one more thing, mistaking motion for progress. Velocity stopped being the scarce resource. Knowing when to stop became the scarce resource.

So I ask people to describe their quality bar in a way that someone else could apply without them in the room.

Most can’t. Not because they lack one — usually they have a very good one — but because it lives entirely as taste. They know it when they see it. Nobody ever made them externalize it.

That’s fine as an individual contributor. It’s a hard ceiling at any scale above one. A bar that only exists in your head can’t be delegated, and a bar that can’t be delegated routes every quality decision back through you. You become the bottleneck on the thing you were hired to remove.

A quality bar you can’t hand to somebody else isn’t a standard. It’s a preference.

The best answers are unglamorous and specific. What has to be true before this goes out. What we accept as broken on purpose. What would make us pull it back.

The Shape — Can They Hold the Whole Thing?

This is the one I weigh most, and the hardest to interview for.

When a team ships fast in parallel, the failure mode isn’t bad features. Everyone’s work is defensible in isolation. The failure is that six months of good decisions add up to something incoherent — a product that does many reasonable things and doesn’t feel like one thing.

Somebody has to hold the whole shape. Not the roadmap. The shape: how the pieces relate, which decisions are load-bearing, what breaks if this part changes.

Almost everything else in this job got cheaper in the last two years. Coherence didn’t. It’s still one person’s head, and it doesn’t parallelize.

The screen I trust most is asking what they killed. People who hold the shape can tell you what they said no to and why it would have broken something else — the reasoning is structural. That would have forced us into X, and X closes off Y. People who don’t hold it list what they shipped instead.

Both answers sound fine in the room. Only one of them tells you anything.

The Strongest Argument Against All of This

Let me make the case against myself, because it’s a good one.

None of this is new. Specification, judgment, coherence — these were always what separated good product managers from adequate ones. I haven’t discovered anything. I’ve gotten pickier and dressed it up as a trend.

That’s fair. And I think it’s half right.

These were always the right things to screen for. What changed is that you used to be able to hire without them and still ship a decent product, because the system absorbed the deficit. A vague spec got repaired downstream. An unexamined quality bar got enforced by the calendar. Incoherence accumulated slowly enough that somebody could clean it up later.

Execution cost was the buffer. And the buffer hid a lot of weak decision-making.

The buffer is gone. Same skills, no slack.

Where this is genuinely weak: it biases hard against people whose roles never let them practice any of it. If you’ve spent three years somewhere that hands you the spec and defines done on your behalf, you may have all three instincts and no way to show me. I don’t have that solved. I’m fairly confident the bar is right and much less confident the screen is fair.

So if you’re on the other side of the table — write your quality bar down and give it to someone else to apply. The gap between what they do and what you’d have done is the part you never externalized, and it’s the part capping you. Keep a record of what you argued against and why; in two years that record is the only evidence you were holding the shape rather than working the queue. And build something end to end where nobody catches your mistakes.

It is the fastest available correction to your own opinion of yourself.

The Part That Isn’t About Hiring

Hiring bars get treated as an HR artifact. They’re not. They’re the most durable thing a product leader builds.

Roadmaps get rewritten every two quarters. Reorgs come and go. Strategy documents age badly. But the bar you set for who gets in shapes what the team is capable of long after you’ve stopped being the one setting it — and unlike almost everything else on your plate, nobody will ever tell you it’s wrong.

A bad bar doesn’t fail loudly. It quietly produces a team that can execute anything and decide nothing.

That’s the risk worth naming. The cost of building collapsed. The cost of building the wrong thing didn’t move at all. It just arrives faster now, and with better polish on it.

Nearly everyone can ship now. Screening for it tells you almost nothing.

The spec, the bar, and the shape. That’s what’s left.

What’s the one thing you still screen for that you’d never give up? Reply or comment — I’ll pull the best answers into a follow-up.

Thanks for reading The Data Product Agent. Subscribe for free to get new posts and support the work.