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 that the org chart treats as four different people.

That spread used to be a coordination problem. It is now a single conversation.

The role was a coordination structure, not a skill set

The product manager job was assembled around a constraint: the work of figuring out what to build was split across people who each held one piece. 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.

Each boundary was a handoff, and each handoff was a tax. Intent gets written down, read, re-interpreted, and rebuilt at every 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 at once; it leaks. By the time an idea has crossed four boundaries it is a worse version of itself, and the round trip to correct it is measured in weeks.

The split made sense because the alternative was worse. One person could not hold demand modelling, pricing, architecture, and a production codebase at a useful depth. So you specialised, and you paid the coordination cost, because paying it beat the alternative of everyone doing everything badly.

What changed is the cost of holding all four at once

AI tooling did not make people smarter. It collapsed the cost of operating outside your home discipline well enough to make a real decision.

The analyst’s morning query no longer needs a data team in the loop; you write the SQL, and when you do not 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; you can stand up a thin version and watch it break. The prototype that used to be a Figma file someone else would have to interpret is now running code that answers the feasibility question directly. The four modes did not merge because the person got more capable in the abstract. They merged because the friction between “I have a question in this domain” and “I have a usable answer” dropped close to zero.

When that friction drops, the handoff stops being mandatory. And once a handoff is 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 now 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 are deliberately not doing.
• Market analysis. Who is the buyer, what do they actually pay for, where is demand moving. This is empirical, not a deck; it lives in the data.
• Solution architecture. What is buildable, at what cost, with what failure modes. Where the system bends and where it snaps.
• Implementation. Code that runs. The level where feasibility stops being an opinion.

The value is not in being elite at all four. It is in the absence of the gap between them. 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 is the cohort data, and here is a working flow priced for them” runs inside an afternoon, not across a quarter and three teams.

I repositioned a content tool from a $29 consumer product to a $999/month contract floor; 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 it selected for. No brief in the world transmits that as well as writing the query yourself.

What it changes about teams

The obvious worry is that this is an argument for heroics, or for one person hoarding the work. It is neither.

Specialists do not disappear; the depth is still real and still needed. What changes is the shape of the team and where the seams go. You no longer need a seam at every discipline boundary by default, because the boundary is no longer where the friction lives. You can run with fewer, larger surfaces held by people who span several modes, and reserve genuine specialisation for the places where depth actually compounds: the gnarly distributed-systems problem, the regulated edge case, the research-grade model work. The team gets flatter not because anyone is doing less, but because the translation layer between functions was load-bearing only while translation was expensive.

The failure mode is mistaking range for a licence to be shallow everywhere. Range is only worth anything if each mode is real. SQL that returns the wrong number confidently is worse than no SQL. A prototype that hides the hard part proves nothing. The standard is not “touched four domains”; it is “made a decision in each that held up.”

Why I went wide

Realising the role was a coordination structure and not a skill set is what pushed me to learn the layers I’d been carrying messages between. If the job is to hold 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 business strategy got argued rather than waiting for the output to reach me. It has paid off; the breadth and variety are the part of the job I would protect last.

Not every PM wants this, and that’s a fair choice; coordinating the work well is real, and someone has to do it. But it’s a fraction of what the role can hold. Most 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 to maximise the value the product creates for the effort it takes. The role doesn’t cap you; the drive to go one more layer down, again and again, decides how much of it you actually do.

The texture, again

Back to the week. The reason the morning SQL matters is that it changes the afternoon’s pricing argument, and the reason the night’s prototype matters is that it tells you whether the afternoon’s argument is buildable before you commit it to a roadmap nobody can walk back. The four modes are not a list of skills to collect. They are one feedback loop that used to run through four inboxes and now runs through one head.

The handoff was never the work. It was the tax we paid because the work was split. The split is now a choice, and most of the time it is the wrong one.