When Your Startup Needs a CPO Not a CTO

I've sat in three board meetings in the last six months where the conversation went like this….

"We need to hire a CTO."

"Why?"

"Because we're a tech company. We need someone senior on the tech side."

"What do you need them to do?"

"Own the product roadmap, talk to customers, work out what we should build next, make sure engineering is building the right thing."

That's not a CTO. That's a Chief Product Officer.

And the fact that so many founders and boards confuse these two roles is costing startups real time and money. You end up hiring the wrong person for the wrong problem at the wrong time, then wondering why it didn't work.

So let's fix that.

What a Chief Product Officer Does

A Chief Product Officer owns the answer to one question: What should we build, and for whom?

Everything else flows from that.

They own:

• Product strategy — the big bets and sequencing of what gets built when.
• Customer insight — talking to users to understand problems and translate needs into features.
• Go-to-market alignment — bridging product, sales, marketing and customer success so everyone works to the same goal.
• Team structure and process — determining how product managers, designers, researchers and engineers work together.
• Trade-offs — saying no to features, killing projects, protecting focus.

A good CPO spends most of their time outside the codebase. They're in customer calls, strategy sessions, roadmap reviews and cross-functional alignment meetings.

They're the person who can stand in front of the board and explain why you're not building the feature every competitor has — and why that's the right call.

They need to understand what's technically possible, what's commercially viable, and what users actually want — then make decisions that balance all three.

What a CTO Does (And Why It's Different)

A CTO owns the answer to a different question: How do we build this, and keep it running?

They own:

• Technology strategy — architecture, stack, build vs buy, technical debt.
• Engineering team — hiring and setting team structure.
• Infrastructure and operations — scaling, security, compliance.
• Technical feasibility — telling the CPO (and CEO) what's realistic and impossible.
• Developer experience — tooling, process, and making sure engineers can do their best work.

A good CTO spends time in the codebase, in architecture reviews, in incident post-mortems and in hiring pipeline meetings. They're the person who can tell you why the system went down at 3am, why the mobile app is slower than it should be, and why that feature the sales team wants will take three months not three weeks.

They need to build systems that don't fall over, hire engineers who ship quality work, and make sure the technical foundation supports where the business is going.

The Pattern I Keep Seeing And Why It Breaks

Here's what happens when you hire a CTO but actually need a CPO:

You hire someone brilliant. Strong engineering background, led teams at a scale-up, knows their way around a stack. The board is thrilled.

Six months later, you've got problems:

• Engineering is shipping features, but they're not the right features.
• The roadmap exists, but it's a list of customer requests and internal ideas with no clear strategy.
• Sales is frustrated because what got built doesn't match what they're trying to sell.
• Your new CTO is drowning in customer calls, roadmap meetings and go-to-market conversations, so the technical work is slipping.

It's not their fault. You hired them to do two jobs. One of them isn't their strength, and neither is getting done properly.

So When Do You Need a CPO?

You need a Chief Product Officer when:

You're past MVP and the next question is "what do we build next?" — You've got product-market fit (or you're close). Now you need someone to own the roadmap, prioritise ruthlessly, and make sure every quarter moves you towards a clear outcome.

Engineering keeps building things nobody uses — Your developers are talented and shipping regularly, but features aren't landing. That's not an engineering problem. That's a product problem.

You're scaling and cross-functional chaos is setting in — Product, sales, marketing and engineering are pulling in different directions. You need someone whose job is to align them around a single plan.

Customers are asking for everything and you're saying yes too much — A CPO's job is to say no. Protect focus. Kill projects. Make the hard calls about what not to do.

You need to articulate product strategy to a board or investors — If the question is "what's your product vision for the next 18 months?", you want a CPO in that room, not a CTO.

You probably don't need a CPO if you're pre-revenue, still figuring out your MVP, or if your founder is still the person driving product decisions day-to-day. You can get away with a strong Head of Product or a fractional CPO until you hit Series A or beyond.

Can One Person Do Both?

In very early-stage startups (pre-Series A), yes — sometimes. You might have a technical co-founder who can wear both hats. Or a strong Head of Product who partners closely with an engineering lead.

By the time you're 30–50 people, it falls apart. The two jobs require different skills and mindsets. A CPO needs to be out talking to people, whereas a CTO needs to be in the weeds with the engineering team. You can't do both well at scale.

If you're a founder trying to do both right now, I'd bet one of them is suffering. Usually the product side. Engineering is loud and immediate, and product work is slower and easier to defer.

The Honest Truth About Hiring (Or Not Hiring) Either

Most startups don't need a full-time CPO or CTO until Series A at the earliest. They need:

• Someone who can own product strategy and roadmap (that might be you, the founder, or a strong Head of Product).
• Someone who can own the technical foundation and lead engineering (again, might be a technical co-founder or a senior engineering lead).
• Clarity on which problem is bigger right now, and getting help on that one first.

If you’re trying to decide to to hire, ask yourself this:

What's failing more often: our ability to decide what to build, or our ability to build it well?

If it's the first, you need product leadership. If it's the second, you need technology leadership.

If the answer is "both", you're probably not ready to hire either at C-level yet. You need to get one side stable first, then bring in the other.

Don't hire a CTO when you need a CPO just because the title sounds more impressive. And if you're still figuring this out, a fractional leader on either side will give you six months to work out which hire you actually need to make permanent.

If you're stuck on this decision, or you need someone to own product strategy while you figure out your next permanent hire — that's exactly the kind of conversation I have with founders and boards. Book a clarity call and we'll work out what you actually need.