Hiring for the Unified Role — There Is No Template

Every CPTO search I’ve been involved in starts the same way. Someone opens a shared doc and begins drafting a job description by essentially stapling a CTO job description to a CPO job description. The resulting document is a list of everything that anyone in either role has ever been expected to do, which produces a spec that no real human being could satisfy and that signals to candidates who read it carefully that the company hasn’t thought hard about what they actually need.

The fundamental error is treating the combined role as additive. It isn’t. A CPTO is not a CTO who can also do product, or a CPO who can also do engineering. The job is structurally different from both, because the primary skill it requires — holding both perspectives simultaneously in high-stakes decisions — is a distinct capability that doesn’t automatically follow from excellence in either discipline alone.

There are senior engineers who deeply understand product strategy. There are senior product leaders who deeply understand engineering constraints. Very few people can shift between those perspectives fluidly within the same decision, without defaulting to their home discipline when the call gets hard. That defaulting tendency — the CTO who runs a joint product-engineering team but consistently resolves conflicts in engineering’s favor, or the CPO who consistently routes around technical concerns when there’s schedule pressure — is the most common failure mode in the CPTO role and the hardest to assess in a hiring process.

What to look for

The best interviews I’ve run for this role are built around decisions rather than capabilities. Not “tell me about a time you managed a technical roadmap” but “walk me through the most expensive technical debt decision you’ve made — one where you decided to ship the product feature rather than address the underlying architectural problem — and tell me what you knew at the time and what you learned after.”

That question surfaces a few things simultaneously. Whether the person has actually made hard calls at the seam between product and engineering. Whether they can describe the tradeoff honestly rather than retroactively justifying the decision as obviously correct. Whether their retrospective assessment is sophisticated enough to recognize the second and third-order effects of the choice. And whether they have enough genuine technical understanding to explain the architectural problem without lapsing into generalities.

The other question I always ask is about a time the candidate had to tell a product team that something they committed to wasn’t going to ship on time because of a technical problem they hadn’t surfaced early enough. How they describe that conversation tells you a lot about whether they hold the technical side accountable with the same rigor they hold the product side, or whether they have a soft spot for engineering that insulates it from the same expectation-setting and consequence culture that product typically operates under.

The reference problem

CPTO references are particularly difficult because the pool of people who have seen the candidate operate in a combined role is small. Most references are from contexts where the person ran one side or the other, which means you’re asking them to project from partial evidence. That’s fine, but you should be explicit about what you’re asking.

The most useful reference questions for this role are about how the person handles the moments where product and engineering are pulling in opposite directions. Does the reference remember specific decisions where the candidate called something that wasn’t popular with either side? Can they describe how the candidate communicated that call to both audiences? Did the decision hold up over time?

The reference you most want to talk to is someone who reported to the candidate from the side they didn’t come from originally. If your candidate is primarily a product background person, talk to a senior engineer who worked for them. Ask that engineer whether they felt the candidate genuinely understood the technical tradeoffs they were making, or whether they felt like they were managing up to someone who was learning on the job. That assessment from someone who had something at stake in the answer is worth more than any amount of structured interviewing.

The combined role is hard to hire for precisely because it’s hard to do. The search process should reflect that difficulty, not paper over it with a comprehensive job description that nobody can actually match.