Do tech-first organisations still need Product in the AI era?
If AI makes delivery cheap and roles keep overlapping, does Product decide what matters, or has it become the bottleneck everyone routes around?
Original illustration for The Hard Thing.
Tech-first companies optimise for what is possible. Give talented engineers room and ideas appear. Shipping them feels like progress, but a stream of features is not a strategy. Somebody still has to decide what deserves company time.
The real question
When building becomes the strategy
Many technical organisations eventually confuse momentum with direction. The architecture improves, the backlog grows, demos get sharper, and engineers propose automations, AI features, integrations, and platform improvements.
Most ideas sound reasonable on their own. The problem is selection.
What should be built first? Which customer problem is worth solving? Which feature moves the business? Which request is noise? Which technical investment is strategic rather than just enjoyable engineering?
This is where the old argument returns: do tech-first organisations still need Product in the AI era? If the CTO is strong, the tech leads are senior, and AI can generate prototypes in a weekend, maybe Product becomes unnecessary.
I think the opposite is true. The faster we can build, the more important it becomes to decide what is worth building.
Product is not project decoration
Product is sometimes reduced to backlog grooming, roadmap slides, stakeholder updates, or user stories written after the decision. In that version, Product is administration with nicer vocabulary.
The useful product function connects customer value with business outcome. It asks whether a problem is real, painful, strategic, and worth the cost.
Engineering, Sales, Customer Success, Finance, and leadership each expose part of the truth: what is possible, requested, painful, profitable, and strategic.
Product turns those signals into coherent choices. That does not make Product more important than Technology. It makes it different. A good CPO should not pretend to be a CTO. A good CTO should not have to reconstruct strategy from scattered customer requests.
Role gravity
The role map
Two dimensions make the roles easier to discuss:
- Tactical versus strategic: are we focused on the next delivery step or on long-term direction?
- Technical versus business: is the main gravity technical depth or business ownership?
The borders are fuzzy, but the centre of gravity matters. This is a gravity map, not an org chart.
Distance from the centre shows the role’s strongest pull; overlap shows where collaboration must be explicit.
Real people do not live in neat squares. Strong leaders cross borders: tech leads think strategically, CPOs understand architecture, CTOs read the market, and TPOs translate between product intent and technical feasibility. Still, if everyone claims the same space, the organisation becomes noisy. If nobody claims a space, it becomes blind.
CTO: technology strategy and leverage
The CTO owns technology as a strategic asset: architecture, platform direction, technical risk, engineering culture, security, scalability, build-versus-buy decisions, and change cost.
In a tech-first company, the CTO often becomes the default product strategist because the company starts with a technical insight. That may be necessary early on, but it does not scale. When every prioritisation choice needs the CTO, the organisation has created a bottleneck and called it leadership.
The CTO should define what the company can uniquely do with technology, but not be the only person choosing customer problems.
CPO: product strategy and market truth
The CPO owns product direction as a business discipline: customer understanding, positioning, packaging, pricing signals, problem selection, roadmap logic, and product-market fit.
A good CPO does not ask engineering to build everything customers request. Customers reveal pain, but they are not always good designers of solutions. A roadmap built only from the loudest deal becomes a custom development queue.
The CPO protects the product from fragmentation: which market are we serving, which customers should we disappoint, which requests signal deeper problems, and which bets only make the next quarter easier?
In a tech-first organisation, the CPO also has to earn credibility with engineering. If Product cannot explain why a choice matters, it should expect pushback.
PO: product ownership close to the work
The Product Owner sits closer to delivery than the CPO and turns product direction into backlog choices, acceptance criteria, release decisions, and daily trade-offs.
That does not make the PO a ticket processor. A good PO protects the team from noise, keeps the user problem visible, and settles small prioritisation questions before they become steering committee topics.
The PO’s gravity is business ownership with tactical execution: customer context, product surface, commercial impact, and the cost of saying yes. In practice, the PO often decides whether a sprint is full of valuable work or just full.
Tech Lead: engineering execution with local judgement
The tech lead lives close to the code. They understand the system, delivery risks, and compromises hidden inside apparently simple requests.
Their job is not just to assign tickets or review pull requests. A good tech lead translates intent into implementation choices, spots complexity, and challenges quick fixes that become recurring tax.
Tech leads are often first to notice that a product idea is underdefined. They should surface the ambiguity early:
“We can build this, but I do not yet understand why this version is the right one.”
That question saves months.
TPO: technical product ownership
The TPO, meaning Technical Product Owner, is useful when the product surface and technical system are tightly coupled. Platforms, APIs, integrations, data products, developer tools, commerce engines, and AI-heavy workflows often need this bridge.
The TPO has product ownership gravity, but stronger technical pull than a typical PO. They should understand customer value, backlog trade-offs, architecture, constraints, dependencies, and non-functional needs.
This is especially valuable when the product is not mainly a screen. If the “product” is a pricing engine, integration layer, workflow, or internal platform, the customer problem and technical shape are hard to separate.
The danger is turning the TPO into a mini-CTO or proxy tech lead. The point is to keep product intent and technical reality in the same conversation.
PO and TPO: should you have both?
Sometimes yes, but not by default.
You may need both roles when the product has two centres of gravity. One is business-facing: workflows, adoption, pricing, packaging, and releases. The other is technical: APIs, platform capabilities, data contracts, integrations, AI orchestration, performance, security, or compliance.
In that case, the PO keeps the business problem sharp. The TPO keeps the technical product shape honest. They are protecting different failure surfaces.
This split works when:
- The product area is too large for one person to cover both contexts responsibly.
- The TPO owns a platform, API, data, or AI-heavy capability used by multiple product surfaces.
- The PO and TPO have explicit decision rights, not just shared meetings.
- The team knows which questions are business trade-offs and which are technical.
It is a bad idea when the split avoids hiring a stronger product person, when the TPO becomes a translation layer, or when both roles fight over the same backlog.
The difference matters. The PO should ask, “Is this the right customer and business problem?” The TPO should ask, “Can this capability be designed, integrated, and operated responsibly?” If both ask only the first, technical debt grows. If both ask only the second, the product becomes coherent but commercially confused.
Where roles break
The failure modes
Most role conflicts come from unspoken ownership. One role gets pulled into another role’s gravity until nobody can see where the decision should live.
When Product is weak, engineering fills the gap. That does not mean engineers are trying to take over. It means somebody has to decide. If Product does not provide direction, it will come from architecture, sales escalation, executive preference, or whoever speaks last.
AI changes the operating model
AI moves the line
AI makes the question more urgent, not less.
When prototypes become cheap, the backlog grows quickly. Every department can imagine an assistant, agent, automation, or reporting layer. Some ideas will be valuable. Many will only look useful in a demo.
Organisations can now produce functional-looking software with much less engineering involvement. A product manager, founder, consultant, or operations team can use generative AI coding tools to create an internal tool, portal, automation flow, or full prototype.
In the past, engineering capacity was a natural constraint. If no engineers were available, many ideas waited. Now the first version may appear anyway. That can reduce learning cost, but it can also turn a demo into a system with real users and no owner for reliability, security, data quality, maintainability, or integration debt.
AI does not remove the need for engineering. It changes when engineering has to engage. Engineers may spend less time typing first lines of code and more time defining boundaries, reviewing generated implementations, setting platform guardrails, exposing safe APIs, choosing reusable patterns, and deciding which experiments may reach production.
Product also becomes more accountable. If a non-technical team can create ten prototypes in a month, Product must be clearer about which problems matter. Otherwise, the organisation gets many tools that look useful but solve little.
So Product does not disappear in an AI-heavy organisation. It becomes more important. It must separate capability from value:
- Just because AI can generate code does not mean the solution should exist.
- Just because a prototype works once does not mean it is operationally safe.
- Just because a workflow can be automated does not mean the workflow is worth preserving.
- Just because a product manager can create a demo does not mean the company can skip technical ownership.
- Just because competitors announce something does not mean customers need your version.
AI increases execution capacity. Product judgement decides where that capacity should go. Engineering judgement decides which generated solutions can work in real conditions.
Product must keep the pace
Development speed can now be very high. A strong engineering team using AI-assisted development can explore options, generate prototypes, write tests, refactor code, and connect services faster than many organisations make product decisions.
Product cannot answer this with slower rituals. If engineering works with AI-native tools while Product depends only on long documents, manual analysis, and delayed steering meetings, Product becomes the bottleneck it was meant to remove.
This does not mean replacing judgement with AI. It means using the same class of tools to keep decision quality and speed close to delivery. Research synthesis, interview summaries, competitive scans, option framing, draft PRDs, data exploration, prototype flows, and experiment design can all move faster with GenAI support.
The standard goes up, not down. Faster product work should make decisions clearer, not more careless. This deserves its own post one day, because AI is changing how software is built and how product thinking has to operate.
The operating contract
A practical split
The exact titles matter less than the explicit contract. In a healthy tech-first organisation:
- The CPO owns which markets, problems, and product bets deserve investment.
- The CTO owns how technology can solve them sustainably and create leverage.
- POs own tactical product decisions, backlog clarity, and delivery-level value trade-offs.
- TPOs own technically complex product areas where customer value and system design are tightly coupled.
- Tech leads own local engineering decisions and execution quality.
Overlap is good when people know who is accountable for the final call.
The unhealthy version is overlap without accountability. Everyone comments, nobody decides, and the team keeps building because it is the least awkward way to avoid conflict.
So, do tech-first organisations still need Product in the AI era?
Yes, unless they are comfortable mistaking output for progress.
A tech-first company does not need Product as ceremony. It needs product judgement: the discipline of choosing valuable problems, connecting them to strategy, and saying no to attractive distractions.
The stronger and faster the engineering organisation, the more Product has to raise its level. Weak Product slows engineers down. Strong Product gives them a sharper target and keeps decision speed close to development speed.
Generative AI raises the stakes because it lets organisations build before they have fully decided. Without product judgement, AI produces more output. Without engineering judgement, that output can be difficult to operate.
Technology creates possibility. Product turns possibility into a business choice. Delivery roles make that choice real.
If you remove any of those forces, the system does not become simpler. It just hides the missing work inside somebody else’s job title.