Soundings
Our Perspectives and Insights
Rise of the Technical Product Manager
For as long as I have built things, engineering took time, and everything else waited on it. The build sat on the critical path: the longest step, so it set the pace for everyone. AI just collapsed that step. And in collapsing it, AI surfaced where the real rate-limiting step lived all along: not in the engineering, but in the translation between what the business wanted and what got built.
With AI, engineering effort is accelerating. When the build that used to take six months takes an afternoon, the question stops being whether we can build it fast enough. It becomes whether we are building the right thing, in the right order, and whether anyone in the room can tell. That question has always had one owner: the technical product manager.
Years ago I had a product whose first version shipped as a strong MVP and earned real traction, then the business dictated a new version from the ground up with no collaboration from engineering, and that second version was the one that failed. On the third version I put the lead engineer and the two people who would actually use it in one room, stood at the whiteboard, and translated in real time: direction to mockup to breakpoints in a single morning. The speed was always possible. We just rarely did it, because the person who can stand in that gap and translate both directions is rare.
The Translation Layer Was Always the Critical and Scarce Part
The time duration obscured that the translation layer was always the hard, scarce skill. Shyam Sankar, who built his career in exactly this seam between the tool and the real-world problem, states the general rule bluntly:
“Every layer of process that stands between the frontline worker and their ability to do their job is deadweight to be destroyed.”
– Shyam Sankar
He is right, with one exception that proves the rule. There always needs to be a translation layer, but it has to be the thinnest, most permeable version of itself: a direct, high-bandwidth connection between the business and the build, not a committee, not a fresh stack of documents, not a game of telephone. That is what a technical product manager is. Standing in that seam well is its own discipline. It is not an engineering task and it is not a business task. It is the connection between the two, kept as thin and as fast as it can be.
A real technical product manager does several things at once, and has to do all of them well:
- Negotiator. The business and the engineers both want more than they can have, and someone has to broker the deal.
- Communicator. A requirement written badly is a system built badly. The words are the product before the product is.
- Prioritizer. There is always too much to do. Someone has to say out loud what is first and what waits.
- Champion. A good idea with no one fighting for it dies quietly in the backlog. The role carries the torch and enlists an army of supporters.
- Explorer. The best ones stay open to ideas they did not walk in with, from either side of the table, because the right build is often the one nobody had thought of yet.
- Validator. Fast execution of the wrong plan is just fast failure. Someone has to keep testing that the path chosen is actually the right one, and be willing to call it and re-aim when it is not.
Do all of those well and you are rare. Do them at the speed AI now moves and you are indispensable.
The rate-limiting step is no longer the build. It is the translation.
It Takes Fluency in Both Languages
A product manager who runs a tight process is stronger still with the technical read to know what a given choice actually costs. A brilliant engineer is stronger still with the business context to know which trade-off truly serves the customer. Most of us are deep on one side of that line, which is normal and valuable. The technical product manager is the rarer profile who can hold both at once, and that is exactly the profile this moment calls for. You can assemble it in a room, given enough time and enough trust to get everyone aligned. But that is slow, it is expensive, and it is the very time AI no longer gives you. It is better to have one person who can simply do it.
The Bottleneck Moved to You
So follow the logic. Engineering sat on the critical path: the business wanted fast, the build took the time it took, and the translator’s imperfection stayed hidden inside that wait. Take the wait away. Give the engineers AI, and the months become an afternoon. Now the business wants fast, engineering can go fast, and the only thing standing between an idea and production is whether someone pointed it in the right direction and in the right order. That someone is you. The rate-limiting step is no longer the build. It is the translation.
You are the bottleneck now, and that is the best news you have had in years.
A bottleneck is simply the place where value concentrates. And the role is not going away. It is being handed an acceleration engine. For your whole career the hard part was that you could see the right build and could not summon the hands to make it. That constraint is loosening. With AI you can harness a far quicker engineering force than you ever could before, and start turning the business ideas you have carried for years into real things. The skill was always the scarce part. You are the scarce part. Go build.
The Bottom Line
Think of a busy restaurant kitchen. The line can cook as fast as you let it, and AI just gave you a line that never tires and never slows. But a fast kitchen is not automatically a good one. Every plate still crosses one person at the pass: the chef who reads each ticket, holds the standard, and decides what goes out and what goes back. Speed the line up without that chef and you just send out the wrong dish faster, hot and plated and still wrong. The cooking was never the scarce part. The call at the pass was: is this right, and does it go? For years the technical product manager has stood at that pass between the business and the engineers. AI just sped up the line. That makes the pass matter more, not less. Own the pass.
A Pilot & Rutter principle.