A startup CTO cannot hide in the technology department.
You do not need to become the product manager, but you do need to understand the product, the customers, and the business well enough to make good technical decisions. Architecture built without that context is usually just expensive guessing.
The interesting work happens where product and engineering meet.
Product management is not the roadmap
Product management is the work of understanding which problems are worth solving, for whom, and why now. The roadmap is one way of communicating the current answer. It is not the work itself, and it is definitely not a promise carved in stone.
For me, product management has three connected parts:
- Direction: Which customers and problems are we choosing to focus on?
- Discovery: What do we need to learn before committing more time and money?
- Delivery: How do we turn what we learn into a useful product without losing the reason we started?
Engineering belongs in all three. If engineers only enter when a specification is “ready”, the company loses technical insight during discovery and product context during delivery.
The CTO and product manager alliance
The CTO and product manager should disagree sometimes. If they never do, one of them is probably not bringing enough information into the room.
The product manager brings customer, market, and product context. The CTO brings engineering possibilities, constraints, risks, and the long-term cost of decisions. Neither perspective wins by default.
A good working relationship needs:
- a shared understanding of the business direction;
- regular conversations before decisions become presentations;
- enough trust to challenge each other’s assumptions; and
- joint ownership of outcomes, not separate ownership of “features” and “technology”.
The difficult part is avoiding the two common extremes. Engineering should not become an internal agency waiting for requirements. Product should not become a decorative layer around decisions already made by engineering.
Connect the three strategies
Business, product, and engineering strategy should describe the same company from different angles.
If the business wants to enter a regulated market, the product strategy may focus on the workflows and trust needed in that market. The engineering strategy may then prioritise auditability, security, and predictable delivery. Buying a fashionable database has very little strategic value unless it helps with those choices.
I use a few simple questions to test the connection:
- Which business outcome are we trying to change?
- Which customer problem is connected to it?
- What must the product do better?
- Which engineering capabilities make that possible?
- What are we deliberately not doing?
That last question is important. A strategy without choices is just a collection of ambitions.
Roadmaps should show intent
Roadmaps are useful when they communicate direction and sequence. They become dangerous when dates and features create a false sense of certainty.
For early work, I prefer roadmaps organised around problems, outcomes, or bets. “Reduce the time it takes a customer to publish their first video” gives a team room to learn. “Build onboarding wizard by 14 June” may be a valid delivery commitment, but it has already selected the solution.
There will still be deadlines. Startups have customers, contracts, and cash constraints. The point is not to avoid commitment; it is to be honest about where uncertainty exists and avoid turning every idea into a promise too early.
Build product teams, not handovers
The strongest setup is a small cross-functional team that can understand a problem, explore options, build a solution, and see what happened afterwards.
Give the team a clear outcome and useful constraints. Then give them enough authority to make decisions inside those boundaries. This is what empowerment looks like in practice. It is not “do whatever you want”, and it is not a manager approving every step.
Team structure matters here. A stream-aligned product team should be able to deliver value without coordinating with half the company. Platform and enabling teams can reduce the cognitive load, but only if they help product teams move. A platform that mainly creates tickets has missed the point.
Discovery needs engineers
Engineers should see customers use the product. They do not all need to become researchers, but they should have access to the problem in its original form.
Customer calls, support conversations, prototypes, and usage data all help. The aim is to replace assumptions with evidence before the expensive part of development.
This also improves technical decisions. An engineer who understands why speed matters to a customer can make better trade-offs than one who receives a requirement saying “must be fast”.
Discovery is not a phase that finishes before delivery. Learning continues after release. Otherwise the company becomes very good at shipping and strangely uncertain about whether any of it helped.
A simple way to start
If product management is weak or new in the organisation, do not begin by importing a large framework. Start with a weekly conversation between product, design, engineering, and the relevant business people.
For each important initiative, write down:
- the problem and who has it;
- the evidence that it matters;
- the outcome you expect;
- the biggest assumptions;
- the smallest useful thing you can learn or deliver; and
- how you will know whether it worked.
Keep the list short enough that people actually read it. Review it when new evidence arrives.
The CTO’s part
The CTO’s job is not to win technical arguments. It is to help the company make good decisions about where technology can create value and where it can create risk.
Stay close to customers. Build a real partnership with product. Give engineers the context to think, not just the requirements to type. Keep engineering strategy connected to the choices the business is making.
That is the useful part of product management for a CTO. The rest is mostly templates.