What hiring leaders need to understand about the new product manager and why most job descriptions are already out of date.
Every few years, the definition of a great product manager quietly shifts. The shift usually happens faster than companies notice, and slower than the people writing job descriptions would like to admit.
That shift is happening right now, and it is moving faster than anything Martyn Bassett has seen across two decades of recruiting product talent.
In conversations with founders, CPOs, and VPs of Product over the past year, a consistent pattern has surfaced: most hiring leaders can feel something changing. They are just not always sure exactly what. The job descriptions being written are pulling from mental models that made sense two or three years ago. Candidates are being evaluated against profiles that are already starting to age.
To get a sharper picture of what is actually changing on the operator side, Martyn sat down with Daniel Shapiro, former CPO at Workleap and PartnerStack, now building at the intersection of AI, healthcare, and pharma. What came out of that conversation was one of the clearest articulations of which PM profile is fading, what is replacing it, and what that means for anyone running a product search right now.
The Profile That’s Fading
The finding is direct and worth stating plainly: the purely non-technical product manager is in trouble.
This is not a new debate. The technical PM versus non-technical PM question has cycled through the industry for years, with reasonable people landing on both sides. What has changed is the direction the evidence is now pointing, and AI is accelerating that signal considerably.
Here is the underlying dynamic. For a long time, strong engineering teams created cover for PMs who did not fully understand the delivery lifecycle. Engineers handled QA, deployment, architecture, and compliance considerations. PMs handled requirements, roadmap, and customer conversations. The division of labor worked, roughly speaking, because it had to. That division is eroding.
As AI tools give PMs the ability to prototype at speed, iterate with customers in real time, and increasingly participate in the build process itself, the gap between what a PM produces and what actually ships is narrowing. Which means the gap in understanding between the PM who knows how software genuinely gets to production and the one who does not is becoming more expensive by the month.
Daniel put it this way: “I don’t think you can get away anymore with just assuming someone else is going to take care of getting software entirely to customers without you understanding at least how it gets there.”
That is not a call for PMs to become engineers. It is a call for a level of technical fluency that allows a PM to understand the full delivery lifecycle: what quality code actually requires, what CI/CD means for how fast a team can safely ship, and what compliance, monitoring and data architecture considerations exist once something is in production. The PM does not need to build it. They need to understand it well enough to ask the right questions.
The Vibe Coding Misconception
There is a related misconception worth naming directly, because it is showing up in conversations with founders who are genuinely excited about what their product teams can now do, and who do not yet see where the bottleneck is going to appear.
The excitement is real and understandable. PMs can now prototype interactive, high-fidelity tools at a pace that would have required a full engineering sprint two years ago. A PM can sit beside a customer, build something in real time, and get genuine feedback within a single conversation. That capability is real, and it is changing how good discovery gets done.
The misconception is that the distance between a vibe-coded prototype and production-ready software is smaller than it actually is.
For companies that have invested in truly modern infrastructure, automated QA, CI/CD pipelines, automated compliance checks, and robust monitoring, the path from prototype to production is genuinely shorter than it used to be. But Daniel was clear that a significant portion of the market is not there yet. Companies still deploying manually, still running manual QA processes, still without automated controls between a prototype and a live product, those companies are going to hit a throughput wall regardless of how fast their PMs can prototype.
The PM who understands this dynamic is an asset. The PM who does not will cause problems that nobody sees coming until the backlog has stalled and the release cycle has broken down.
What gets missed is not the user experience layer. It is everything that sits behind it. How does this fit into the existing data model? What are the audit controls? How is it monitored post-deployment? What does compliance require before this touches a customer in a regulated environment? These are not questions that require an engineering degree. They require a PM who understands that shipping software is not the same thing as building a prototype.
The Profile That’s Rising
So what does the PM that companies actually need right now look like?
Daniel used a phrase that has stayed with the team at Martyn Bassett Associates since the conversation: the builder mindset. Not builder as in coding ability, but builder as in orientation. A PM who leans into the construction of things. Who can show, not just describe. Who is not waiting for an engineer to translate their thinking into something tangible before getting it in front of a customer.
This shows up in specific, observable ways. The builder-mindset PM can point to real artifacts. Not just roadmaps and PRDs, but prototypes they have built, experiments they have run, and tools they have created to solve problems in their own workflow. There is a concreteness to how they describe their work that is distinct from someone who has primarily operated as a coordinator between customer feedback and engineering output.
They also tend to have a more grounded relationship with uncertainty. Because they have been closer to the actual build process, they carry a better intuitive sense of what is easy and what is hard, what can be tested quickly and what requires deeper investment. That calibration matters enormously when a team is deciding where to place its bets.
The strongest candidates for what the next two years require can move fluidly between customer conversations and technical conversations without losing the thread of either. They are not switching between two modes. They are operating from an integrated understanding of what customers need and how software actually delivers it.
What This Means for How You Run a Search
For anyone hiring a PM or a product leader in the next six months, the practical implications are clear.
Your job description is probably describing the wrong person. Most PM job descriptions are still built around the coordination model: gathering requirements, managing stakeholders, writing specs, and prioritizing backlogs. Those things still matter. But if the description does not reflect the expectation that this person will be close to the build, technically fluent, and capable of operating with increasing autonomy as AI tools continue to evolve, the result will be attracting the wrong candidate pool.
The interview process needs to surface the builder signal, not just the communication signal. PMs are, by professional training, skilled at talking about what they have done. The more important question is whether they can show it. What have they actually built? Not managed — built. What prototype did they put in front of a customer last month? What tool did they create to make their own work faster? These questions separate candidates who carry the builder orientation from those who have learned how to talk about it.
Technical fluency is not the same as technical depth, and the bar is not engineering.
When companies hear “more technical PM,” there is a risk of screening for the wrong things: LeetCode ability, SQL proficiency, and whether someone can read code. That is not the point. The point is whether this person understands how software ships, can have a substantive conversation with an engineering team about tradeoffs, and will not be caught flat-footed when a prototype meets the reality of production infrastructure. That is a different evaluation than a technical assessment, and it is worth being precise about what is actually being measured.
The non-technical PM is not unemployable, but the role is narrowing. There are still contexts where the coordination and communication strengths of a non-technical PM represent the primary value. But those contexts are fewer than they were three years ago, and the trajectory points further in the same direction. When hiring for a multi-year role, that trajectory is worth accounting for honestly.
The Bigger Picture
The consistent message Martyn brings to founders preparing for a VP Product search, or evaluating whether their current team is built for what is ahead, comes down to one point: the profile worth optimizing for should be built around the next two years, not the last two.
The last two years rewarded PMs who could operate in high-ambiguity environments, synthesize customer feedback at scale, and communicate strategy clearly across the organization. Those capabilities still matter.
The next two years will additionally reward PMs who can move between discovery and delivery without losing fidelity in either direction. Those who understand what the tools can do, and where the tools end, and human judgment has to start. Who can prototype fast and ship responsibly. Who are, in Daniel’s framing, genuine builders.
Finding that person takes more than a standard PM hiring process. It takes knowing what questions to ask, what artifacts to request, and how to distinguish the candidate who is building a new way of working from the one who has become very good at describing it.
That distinction is at the center of how Martyn Bassett Associates runs product leadership searches. If you are six months out from a product leadership hire and want to pressure-test whether your current brief reflects what you actually need, that conversation is worth having sooner rather than later.
If you’re planning a product leadership hire and want to make sure your brief reflects what the market actually requires, book a call with Martyn.
This piece draws on a recent conversation between Martyn Bassett, founder of Martyn Bassett Associates and The Product Recruiter, and Daniel Shapiro, former CPO at Workleap and PartnerStack. Martyn Bassett Associates is a North American executive search firm specializing in product, sales, and marketing leadership for venture-backed B2B SaaS companies.