Unicorns Don't Scale: Systems Do

I'm back from an epic couple weeks of surfing in Mexico, meaning you all get a blog post. Last month I talked about Spec-Anchored Development and I'm about a month into that journey. I'll get into that more in a future post, but it's got me thinking about the roles of PMs and developers in the engineering process.

The canary in the coal mine here is the FDE (Forward Deployed Engineer), the hottest job in AI. It’s just a new name though for someone who's a combination of a sales engineer (talks to customers) and product engineer (has an opinion about what they build), those weirdos who bridge the gap between product & execution. By all accounts they're still very much unicorns, because of the mix of skills required. That said — I’ve worked with a lot of these people in my career and I understand why everyone wants to work with them.

But let's take a step back — what are we actually solving for?

Context. That's honestly the long and short of it. One person who can talk to customers, understand their problems, and turn that into features — you can't be equally amazing at all of those things, and you can't reliably hire for it either. But when you collapse it into one person, you stop bleeding context on the way from customer to feature. Whoever sits closest to the customer loses the least between idea and implementation.

Previously this is what PMs and business analysts did. They'd gather the feature requirements, talk to customers, come up with potential solutions, and build the roadmap. Once they had a vision, they'd hand it over to the engineering teams to implement.

This worked okay. You'd have the constant friction of new features (grow the business) vs. maintenance and stability (run the business). And that friction is rooted in a lack of context & ownership — the engineering teams often didn't understand why a feature was needed, who the real customers were, or what the actual pain points were.

In this new world where engineers effectively take over the PM role, there's no friction. Just an engineer figuring out what to build straight from customers, and with AI doing the heavy lifting they've got all the time in the world to focus on features. Woohoo!

This works at the greenfield, small scale, for sure. It doesn't work when the codebase is growing, when the requirements outgrow what fits in one developer's head, and it definitely doesn't work when that unicorn quits and moves on to something else. We've consolidated the context, but we haven't actually built a system around it — or a system for building against it.

And with AI making the upfront development so much faster, understanding that context and making it available at the right moments becomes that much more valuable.

So how do you make that product experience scale once you're past the point where one person can hold it all in their head? For me it's been two things running at once.

First, I put the context into the specs. The decisions, the requirements, the personas — all the stuff that used to live in the unicorn's head now lives somewhere the agents can actually read it. The personas especially. They're not window dressing, they're what keeps development pointed the right way after I've stopped babysitting it.

Second, I build the harness the agents work inside: the devops, the deployment pipeline, the workflow engine, the scheduling. This is the part people skip. They want the agent writing features on day one. But the leverage isn't in the features, it's in the machine that produces them with the context already loaded.

Most of the real product thinking happens once, upfront. You define the personas, map the flows, own the requirements, and make the trade-offs you'd otherwise be making across a hundred little Slack threads over six months. Get that right and the rest is mostly plumbing.

Then comes the fun part. Here's an actual loop, running today.

A persona — call him Joe — opens the app and walks the key flows like a real user, filing GitHub issues for whatever's broken or annoying. A Spec PM triages them: throws out the noise, keeps the real ones, writes each up for implementation. A coding agent builds the fixes and pushes to a dev branch. A Review PM then records itself going through every fix, re-runs the flows to make sure nothing else broke, and bounces anything that did back to the coding agent. Whatever survives that hits me, the human gate. I get the recording, the PR, and a plain-English description of what changed. I merge, and the Review PM checks it one more time on staging.

But nobody ever handed Joe off. Who he is, what he's after, what counts as "working" — that got written down once, and every agent in the loop just picked it up. The context stopped leaking.

So if you're an engineer right now, that's the muscle to build. Not cranking out features; anyone with a Cursor tab can do that. Building the loops, living inside the product, setting up the context so the machine can run on it. The trap is becoming vibe-coding-as-a-service — go that route and you'll burn out under a heap of half-working apps before anyone even gets around to replacing you.

Which is the whole point of the FDE. You were never going to hire a building full of people who are all equally good at reading customers, making product calls, and shipping code. That person is rare on purpose. So stop trying to clone them, and build the thing that doesn't need them.