The four-mode product manager

A good week now looks like this. SQL against the warehouse before lunch to find out which accounts are actually expanding, a repositioning and pricing argument in the afternoon, a working prototype in TypeScript that night, and somewhere in the middle a session debugging why an LLM keeps inventing a field that isn’t in the schema. Four kinds of work the org chart treats as four different people.

That spread used to be a coordination problem. Now it’s one conversation.

The role was a coordination structure

The product manager job got assembled around a constraint. Working out what to build was split across people who each held one piece of it. A market analyst held demand and segmentation. A product strategist held the bet. A solution architect held what was technically possible and at what cost. Engineering held the build. The PM existed largely to carry meaning between them.

Every boundary was a handoff and every handoff was a tax. Intent gets written down, read, re-interpreted and rebuilt at each crossing. The analyst’s nuance about which segment was churning becomes a line in a brief. The strategist’s bet becomes a ticket. The architect’s “this is feasible, but only if we denormalise here” becomes a constraint nobody remembers by sprint planning. Nothing is lost all at once. It leaks. By the time an idea has crossed four boundaries it’s a worse version of itself, and correcting it takes weeks.

The split made sense because the alternative was worse. One person couldn’t hold demand modelling, pricing, architecture and a production codebase at any useful depth, so you specialised and paid the coordination cost.

What changed is the cost of holding all four

AI tooling collapsed the cost of operating outside your home discipline well enough to make a real decision. Nobody got smarter.

The analyst’s morning query no longer needs a data team in the loop. You write the SQL, and when you don’t know the window function you need, you find out in the same minute rather than filing a request. The architecture sketch no longer needs a week of an engineer’s time to pressure-test, because you can stand up a thin version and watch it break. The prototype that used to be a Figma file for someone else to interpret is now running code that answers the feasibility question directly. The four modes merged because the distance between having a question in a domain and having a usable answer dropped close to zero.

Once that friction drops, the handoff stops being mandatory. And once it’s optional, keeping it has to justify itself, because every boundary you preserve still costs the same translation tax it always did.

The four modes, held by one operator

The leverage sits with whoever can move between these without a relay:

• Product strategy. What bet are we making and why this one. The shape of the wedge, the sequencing, what we’re deliberately not doing.
• Market analysis. Who the buyer is, what they actually pay for, where demand is moving. This is empirical and it lives in the data rather than in a deck.
• Solution architecture. What’s buildable, at what cost, with what failure modes. Where the system bends and where it snaps.
• Implementation. Code that runs, which is the level where feasibility stops being an opinion.

The value is in the gap between them closing, rather than in being elite at all four. When the same person holds the bet and writes the query that tests it, the loop from “I think the mid-market is where the money is” to “here’s the cohort data and here’s a working flow priced for them” runs inside an afternoon instead of across a quarter and three teams.

I repositioned a content tool from a $29 consumer product to a $999/month contract floor, and revenue went from roughly $5k MRR to $1M ARR over 22 months. The pricing call, the segmentation that justified it, the architecture that made enterprise support viable, and a good deal of the build were one job that looks like four. The decision was better because the person making the pricing bet could see directly what it cost to serve the customer that price selected for. No brief transmits that as well as writing the query yourself.

What it changes about teams

The obvious worry is that this argues for heroics, or for one person hoarding the work. It’s neither.

Specialists don’t disappear, because the depth is still real and still needed. What changes is where the seams go. You no longer need a seam at every discipline boundary by default, because that’s not where the friction lives any more. You can run with fewer, larger surfaces held by people who span several modes, and save deep specialisation for the places where depth compounds: the gnarly distributed-systems problem, the regulated edge case, the research-grade model work. The team gets flatter because the translation layer between functions was only load-bearing while translation was expensive.

The failure mode is treating range as permission to be shallow everywhere. Range only counts if each mode is real. SQL that confidently returns the wrong number is worse than no SQL. A prototype that hides the hard part proves nothing. The standard is having made a decision in each of the four that held up, rather than having touched all four.

Why I went wide

Working out that the role was a coordination structure is what pushed me to learn the layers I’d been carrying messages between. If the job is holding the whole picture, I wanted more of it actually in my head, where it could change a decision. So I taught myself to write code, to pull and analyse my own data, to make designs in Figma that were clean if not inspired, and I worked my way into the rooms where pricing and strategy got argued rather than waiting for the output to reach me. The breadth is the part of the job I’d protect last.

Not every PM wants this, and that’s a fair choice. Coordinating the work well is real work and someone has to do it. It’s a fraction of what the role can hold, though, and most people settle for that fraction by default. “CEO of the product” gets mocked as a cliché and it shouldn’t be. A PM should be a change manager, a strategist, a designer, a programmer, and whatever else the moment asks for, because the only mandate that matters is maximising the value the product creates for the effort it takes. The role doesn’t cap you. How often you’re willing to go one more layer down decides how much of it you actually do.

Back to the week

The morning SQL matters because it changes the afternoon’s pricing argument, and the night’s prototype matters because it tells you whether that argument is buildable before you commit it to a roadmap nobody can walk back. The four modes are one feedback loop, and it used to run through four inboxes. Now it runs through one head.

The handoff was only ever the tax we paid for splitting the work up. Whether to keep paying it is a choice now.