Product management gets cut, then rehired, every few years. Here is the cycle behind it, and why the roles being invented right now suggest shipping was never the hard part.
October 31, 2026
Contents
A few weeks ago I sat down with the CTO of a business that had just sold for close to a billion dollars. He runs an engineering team of around fifty.
His problem is not shipping. His team can build and release faster than it ever has.
His problem is that nobody downstream can keep up. Marketing cannot write the onboarding and the training fast enough. Sales cannot absorb each new thing into a value proposition quickly enough to sell it. And customers, who have their own jobs, cannot adopt what arrives at the rate it now arrives.
He is not slow. He is faster than the system around him, and that turns out to be its own problem.
I have been turning that over since, because it connects to something I have watched from the recruitment side for twenty years.
Companies hire product managers in numbers. A few years later they cut most of them. A few years after that they hire them again, sometimes the same people, usually at a higher price.
I have placed people on both sides of that swing. From the outside it reads as fashion, or cost cutting, or whichever management book was going around that year.
I think it is a cycle with a mechanism. This is a theory and I have no data for it, only a pattern I think I can see from where I sit.
A product manager arrives, properly outcomes focused. There is slack in the product and they find it. Metrics move, the work is visible, the hires are justified.
Then the easy distance gets covered.
The next move is harder to find. The ideas genuinely run out, or the data stops pointing anywhere in particular. And sometimes, the version nobody wants to say out loud, the customers are simply satisfied. The product does what they need and no amount of discovery turns up a problem worth solving.
That is a strange position for a discipline measured in metric movement. There is nothing wrong, and nothing to move.
Time passes. The roles start to look expensive. So they go.
Then a competitor ships something. It does not have to be better overall, it only has to be interesting enough to move one metric in the wrong direction. Churn ticks up. Customers start having conversations they were not having last year.
Suddenly there is a metric worth moving again, and the company goes looking for the people who move metrics.
That is the cycle. Not fashion. Demand for a particular kind of judgement, set by whether anything in the market is currently moving.
Here is what makes me think this is not just a hiring fashion.
Look at the roles companies have invented over the last fifteen years, and what they were invented to do.
Customer success exists because selling software turned out not to be the same as getting it used. Someone had to own the gap between the signature and the habit.
Forward deployed engineers exist for a sharper version of the same problem. The title comes from Palantir, whose 2020 filing describes engineers who "have travelled to bases in Afghanistan and factories in the industrial Midwest to deploy our platforms". The company's own shorthand is that a product engineer works on one capability for many customers, while a forward deployed engineer works on many capabilities for one customer.
That is an organisation admitting something expensive. The product being excellent was not enough. Somebody had to go and sit in the room.
And the companies hiring hardest for that title today are the AI labs and the platforms selling to enterprises, which are precisely the companies whose engineering output has accelerated the most.
We can build it. We cannot get it absorbed.
Both roles are the same admission in different clothes. Every org chart that contains one is a quiet statement that the constraint moved downstream and someone noticed.
Google's DORA research reached a related conclusion from the engineering side in its 2025 report. Its central finding is that AI's primary role is as an amplifier, "magnifying an organization's existing strengths and weaknesses". It does not repair the weakest link downstream of the code. It shows you where it is.
So if your engineering team has got dramatically faster and nothing else has, you have not removed a constraint. You have moved it, and made it more visible.
The obvious reading of all this is speed versus building the right thing. I do not think that is the choice, and I think treating it as one is how leaders get caught out.
Both matter. The failure is funding one and assuming the other takes care of itself.
The version I see most at the moment is trying to reach an outcome with AI while the slower practices quietly stop happening. User research. Customer interviews. Sitting with the people who sell the thing and finding out what they cannot explain to a buyer.
None of that is novel. It is the old way of doing business, and it is the first thing to fall off the list when a team is measured on throughput.
So if you have spent the last quarter tuning the code, get up and walk around the office. Talk to the people in marketing who have to explain the last three releases. Talk to the people in sales who have to put them in front of a buyer.
Then go and talk to some customers.
It is not a framework. It is the thing that keeps getting skipped, and it is cheap.
If you are inside this problem, I would like to hear how it looks from where you sit. anthony@hughman.io
Palantir Technologies, Form S-1, 2020, on forward deployed engineers. Google DORA, State of AI-assisted Software Development, 2025, on AI as an amplifier of existing strengths and weaknesses.
2026 © Hughman.io. All rights reserved.
Reach Out: anthony@hughman.io
