Someone on r/ProductManagement ran an experiment a lot of founders only think about. Their PM of four years left. Around the same time, all twenty-odd of their engineers went all-in on Claude Code and suddenly had bandwidth to spare. So the OP figured they could spread the PM's job across engineering until they found someone good.
Four months later they wrote it up, and it's one of the more spot-on accounts I've read of what that seat actually does.
Some of it worked. Engineers who used to receive tickets now understood the user problems themselves and had their own ideas about what to fix. The OP doesn't want to give that up: "The team got used to owning parts of this themselves, and I'm not sure we should undo that."
The ordering is what fell apart:
"Four people with good judgment create four good lists, not one ordered list."
Or, as the OP put it a few lines later: "Everyone can identify bugs and new features. But someone still has to decide."
Too Many Cooks, No Expediter
I've been writing about the Founder Bottleneck for the past few weeks, and mostly about getting the judgment out of the founder's head. This time I wanted to get more concrete about what happens next: once the judgment is out, what does the person who catches it actually do all day? This thread is a pretty good place to start, because it shows you what happens when nobody catches it.
Look at what spread out fine. Reading feedback, reviewing sessions, knowing the user. AI made all of that cheaper, and more people doing it made the team better at it. Those are tasks, and tasks distribute.
What didn't spread was putting the four lists in one line and saying "this one first." Each list was right on its own. The gap was between them, in the space no single person owned, and that space is the Operator Vacuum. The OP even named the hidden cost, really nailing it on the head:
"I underestimated how much time a good PM spends just absorbing context and working out what matters." AI handed everyone more context. Nobody got the job of weighing it.
So my answer to their open question is: don't undo it. The team keeps every call it learned to make. The Operator Seat doesn't take those back. It owns the one thing four good lists can't do on their own, which is turn into one. A restaurant kitchen figured this out a long time ago: every cook can be great at their station, and you still need an expediter calling which plate goes out first. That's the first thing the person in the seat does all day: decide the order.
Two Releases a Day and a Very Hungry Machine
The second thing shows up once the work starts moving fast, and I watched it happen at a company I work with. One engineer there went heavily agentic and started shipping more than the rest of the team combined, and their pipeline now pushes two releases a day. The founder called it "mythical for my entire career." It's the unicorn of software development. Everybody chases it and almost nobody catches it.
Then he said the part that matters: "now our bottlenecks exist in product specification, and QA/UAT." My reply was basically, yes, feed the machine. When code can ship twice a day, the slow parts are deciding what to build and confirming it's right. Both of those sit on seams: the business handing work to engineering on the way in, and engineering handing it to the people who use it on the way out.
Their fix was to move a developer into a half-coding, half-product role whose whole job is to bookend the pipeline, owning the spec going in and the acceptance coming out.
The way-out end is where I saw the clearest change. After a big replatform, their users were frustrated, some about real bugs and some about things the old system never did either. The team tried everything you'd try. In the founder's words: "We did office hours. Nobody came. We have training articles. Nobody reads them." They ran mandatory training sessions, and people showed up and didn't ask a single question.
Then he changed one rule. Any feature flagged for a warm handoff now needs the developer who built it to sit on a call with an actual user and use it together before launch. The user either signs off or hands back a list. Satisfaction went up, and the users who do those sessions have become the people everyone else goes to with questions, which no training article ever managed.
Nobody got hired for any of this. The seams on either side of the machine, between "what should we build" and "it's built," and between "it's built" and "someone can actually use it," each got a named owner. The bottleneck is still there, for the record. It's just sitting somewhere a person's job is to look at it, which is about the best you can ask of a bottleneck.
That's the second thing the seat does: own the handoffs in and out, so the machine gets fed the right work and what comes out actually lands.
Builder by Day, Operator by... Also Day
The third thing is the hardest, and it's the reason that half-coding, half-product role is tougher than it looks. I know because I'm wearing the same two hats right now.
On a client project I'm the builder, doing the whole thing agentically. It's the first time in a long time I've sat in that seat professionally. I've never had a problem being strategic lead and developer at the same time on my own internal tools. Building for a client turns out to be a different animal.
Building is mostly reactive, like most individual contributor work. You get a list and you work the list. The Operator Seat is proactive: looking ahead, spotting the seam before something falls into it, deciding what goes on the list in the first place. That proactive work is what feeds the machine. Reactive thinking feeds it a lot worse, however fast the machine runs.
The building itself is fine. The hard part is holding both mindsets at once, so that I'm building the right things, in the right way, in the right order. Even with AI doing the coding, it's really hard to wield both at the same time. The pull is always toward the list in front of you, and every hour you spend heads-down is an hour nobody's looking at the seams.
That's by design, for what it's worth. This build is a proof of concept, and it's more cost effective to have one person who can hold both views at once get it to the point where it's proven. Once it is, you start building out the team. All going well, that means a dedicated developer takes over the build, probably early next year, and I step into the Operator Seat. It's still a bit of an experiment. I suspect there's a cousin of the Agentic Fog in here, and a few tactics I've been working out the hard way. That's its own post.
So that's the third thing: the person in the seat keeps their head up. Somebody has to be looking ahead while everyone else works the list.
Number One Might Already Be on Your Bridge
Decide the order, own the handoffs, keep your head up. You may already have someone doing that. Last week I wrote about putting someone with real flight hours in the first officer's seat. Here's the part that costs me business to say. On a podcast recording a few weeks ago, I told the host: "You may very well, as a founder, already have somebody on your team who's incredibly capable of stepping into the Operator Seat. They just need to kind of be blessed with the title."
I meant it. In a lot of companies, someone is already ordering the four lists, unofficially, on their own time, without the authority to make it stick. Maybe it's the developer who started walking features over to customers, or the lead who keeps asking which of two priorities wins. Make it official, and tell the whole team you did. (This still isn't a junior job. The person I'm describing usually has the flight hours already. What they don't have is the title.)
Here's a test you can run this week. Find the last time two good priorities collided: two teams, both right, room for only one. Who decided? If the answer is "whoever pushed hardest" or "me, on a Sunday night," that seam doesn't have an owner yet. And if someone has been making that call for months without the title, you may have just found your first officer.
The part that's on you comes after you name them. Don't go around them. Every request you hand straight to an engineer puts you back in the middle, and the team will notice faster than you do.
That's also my answer to where the OP's line sits now:
The team owns what it learned to own. One person owns the order. The founder owns the handful of calls that were always theirs.
If you've lived through this, either losing the person who held the seams or giving them to someone new: what was the first thing you noticed change?