As AI takes over more of the drafting, research synthesis and documentation that used to fill a PM’s week, the role is being pulled in two directions.
One is breadth across teams, the other is depth in one domain, and hiring a generalist to sit between the two is becoming a less useful bet than it used to be.
Why does this change who you should be hiring?
Because the parts of the PM job that used to make a generalist profile viable are the parts AI is absorbing first.
Writing specs, synthesising research and drafting documentation used to take up a meaningful share of a PM’s week, and doing all of it reasonably well was enough to justify a broad, all-purpose profile.
As AI picks up more of that output, what is left is judgement: deciding what matters, aligning people who do not report to you, or going deep enough in one domain that your call on it is hard to replace.
That is pulling the market towards two distinct profiles. The “integrator” connects product, engineering, design, data and commercial teams through influence and systems thinking, spending most of their time on alignment and prioritisation rather than production.
The specialist goes deep in one domain, whether that is a technical platform, a data problem or a specific vertical, and earns their seat through expertise a generalist cannot fake.
What is losing ground in the middle is the PM who is competent across the board but distinctive in nothing. That profile used to be a safe, flexible hire.
It is becoming a harder one to justify, especially as leaner teams expect each PM to cover more of the journey from intent through to release and operations.
That shift raises the cost of a mismatch between the role and the person in it.
We are seeing this show up directly in the profiles clients ask us for.
A brief that would once have asked for a broad, well-rounded PM is now more often asking specifically for someone who can hold a system together across functions, or someone who can own a hard domain problem end to end.
How do you act on this before you write the brief?
Act on this before the job ad is drafted, not after candidates start applying.
List the decisions your team needs made over the next couple of quarters. For each one, work out whether it needs someone who can pull people together across functions, or someone who can own one hard problem end to end.
Rewrite the brief to reflect one profile, not a combined list of every skill a generalist would need to cover the whole job. A brief that asks for roadmapping, SQL, stakeholder management and UX judgement in equal measure tends to attract candidates who are solid across the board rather than strong anywhere in particular.
Look at the spread of your existing team. If most of your PMs are already strong integrators, the gap you are missing is probably depth, and the reverse holds equally often.
Ask your engineering, design, data and commercial leads what is missing from their side of working with product. The integrator and specialist gap often shows up there before it shows up in a PM’s own self-assessment.
Treat this as a standing question for every hiring cycle, rather than defaulting to the same generic PM spec you have reused for the last few rounds.
What should you look for when hiring for this?
For an integrator, look for evidence of influence without formal authority: decisions they shaped across teams they did not manage, and stories about getting alignment between competing agendas.
For a specialist, look for depth: sustained time in one domain, and language that shows genuine fluency in a specific technical, data or vertical problem rather than a surface familiarity with many.
A few interview questions help tell the two apart, and reveal a generalist trying to pass as either.
Ask the candidate to describe a decision they influenced where they had no direct authority over the teams involved, and how they got people aligned.
Ask about the deepest domain problem they have owned, and what made their judgement on it hard to replace.
Ask how they decide who to pull in when they do not have the answer themselves, since integrators tend to have a clear, practised approach to this and specialists tend to have a narrower one.
Ask for an example of a time they chose breadth over depth, or depth over breadth, and why.
Where doesn’t this apply?
This framing assumes a team with enough people that specialisation is a real choice, and that is not every team.
In a small organisation or an early-stage product, there may be no one else to call on, and a flexible all-rounder who can cover a bit of everything is genuinely the right hire, not a compromise.
Forcing an integrator-or-specialist decision onto a team that only has room for one PM can create rigidity you do not need yet.
It is also worth remembering that domain expertise takes time to build, so a specialist hire only pays off where the domain itself is stable enough to reward depth.
Where the product or market is still changing fast, breadth and adaptability may serve you better than deep expertise in a problem that will look different in six months.
The honest test is whether your team has outgrown the generalist, not whether the market has. If it has not, say so in the brief, and hire the generalist with confidence rather than apologising for not asking for an integrator or a specialist.
Ready to talk about your next product hire? Get in touch.
Katie
Product, Data & Delivery Recruitment
Last updated: October 2026
