What a CTPO is, and why your startup probably needs one

Most early-stage startups don't die because they build badly. They die because they build the wrong thing, beautifully.

A CTPO - Chief Technology and Product Officer - is one person doing both jobs. Not because it's a trendy acronym. Because splitting them in an early-stage company is usually where things break.

The gap nobody talks about

Most product people can't code. Most engineers don't think in revenue. In a 100-person company that's fine - you've got layers of managers translating between them. In a 10-person company, it's quietly fatal.

The roadmap says one thing. Engineering builds another. Marketing expected a third. Everyone's busy. Nothing moves revenue.

A CTPO closes that gap by being the gap. One brain, both sides.

The first job: figuring out what's actually broken

When a CTPO walks in, the symptoms usually look identical across teams: things slip, priorities feel fuzzy, nobody can explain the roadmap. The causes are rarely identical. Sometimes engineering is the problem. Sometimes it's product. Sometimes it's the collaboration between them - or the fact that nobody designed that collaboration in the first place.

The first few weeks of a good CTPO engagement are diagnostic, not executional. You don't ship faster by shipping harder. You ship faster by figuring out where the queues are.

And here's the thing about software: the queues are invisible. In a factory you can walk the floor and see a pile of parts waiting. In a startup everyone looks busy - fingers on keyboards, Slack lit up, calendars full. Meanwhile half the team is waiting on a decision, a spec, or an answer nobody owns. That waiting is the actual problem. A CTPO's job is to make it visible, then remove it.

What one actually does

Let me tell you what it looks like in practice, because "CTPO" can mean anything once a consultant gets hold of it.

A real CTPO:

• Questions the roadmap before building it
• Tells you when a feature is a distraction, even when you want to hear the opposite
• Writes code and writes specs
• Translates between marketers and engineers so you don't need a PM sitting between them
• Thinks in revenue first, architecture second - but knows you can't have the first without the second
• Calls out the half-finished projects sitting on the shelf, because shelved code is either a sunk cost you should accept or a decision you're avoiding

It's not advisory. It's not "strategic input." It's doing the work.

The honest conversation about timelines

Worth saying upfront, because nobody else will: most "fix it in 6 months" problems actually take 18. By the time you decide what to build, hire the right people, structure the team, ship something, and see whether it moves revenue - a year and a half has gone. Boards don't like hearing that. Founders don't either. But pretending otherwise is how you end up with a warehouse of half-built features nobody uses.

The same honesty applies to technical debt. I try to avoid the phrase - it means whatever anybody wants it to mean. The real question is simpler: is fixing this old thing worth more than building the new thing? Sometimes yes. Sometimes the library with the vulnerability just needs replacing. Sometimes what looks like debt is actually a scalability problem in disguise, and the fix is different. A CTPO's job is to make that call with numbers attached, not vibes.

When you need one

You probably need a CTPO if:

• You're pre-Series A, or early post-Series A
• Your technical cofounder is drowning in tickets and hasn't thought about product in months
• Your product cofounder can't tell whether what engineering is building is the right thing
• Your roadmap has 30 items and you can't remember why half of them are there
• Marketing and engineering seem to be building for two different companies

When you don't

Being honest here matters:

• If you're past 50 people, you need two specialists, not one generalist
• If you just need more hands shipping code, hire a senior engineer
• If you already know exactly what to build, hire a contractor and get it done

A CTPO is for the messy early-stage moment when you don't yet know what's worth building - and the cost of building the wrong thing is everything you have.

Why fractional

Full-time CTPOs exist. They're expensive and they're rare. Most early-stage teams don't need one full-time. They need one a few days a week, for a few months, until the roadmap is clean and the team ships without them.

That's the work I do. I built Promoty from zero to acquisition across 8 countries, so I know what it costs when you build the wrong thing. Now I work with startups like a senior teammate, for as long as you actually need me. When you don't, we stop.

If any of this sounds like your team, drop me a line. Worst case we figure out you don't need a CTPO. That's a fine outcome too.

- Leonardo