Why Startups Don't Need Product Owners
Why Startups Don’t Need Product Owners
Why Startups Don’t Need Product Owners
I’ve spent most of my career working hands-on, building products from the ground up — coding, working with designers, talking to stakeholders and customers, and even managing projects myself.
And in the few occasions I’ve worked with Product Owners (POs) or Product Managers (PMs) at that early stage, my impression has always been the same:
👉 They don’t actually know how to build a product.
Designers, developers, and architects are the ones collaborating, solving problems, and learning by actually building. POs and PMs, on the other hand, too often spend their time moving cards around in Trello — yet somehow they’re positioned as “responsible for the product.”
And then you see companies — sometimes on the advice of consultants — hiring a PO to lead a new tech department or a startup team of just a few people.
It’s a strange concept, and usually a costly mistake.
Product Owner vs. Tech Lead
A Product Owner (PO) and a Tech Lead/CTO play very different roles at scale.
| Product Owner | Tech Lead / CTO |
|---|---|
| Defines what should be built and why | Defines how to build it — and contributes to the what through technical vision and feasibility |
| Focuses on user needs, business value, and priorities | Focuses on architecture, scalability, and long-term direction |
| Talks to stakeholders, customers, and designers | Builds the engineering team, writes job descriptions, and makes hiring decisions |
| Measures success in features delivered and user impact | Measures success in stability, performance, and team effectiveness |
But here’s the thing: in the early stages of a startup or new tech department, the what isn’t owned by a single role. It’s a team effort.
The Tech Lead is not just “the how guy.” They’re usually a senior fullstack engineer who codes hands-on while also contributing heavily to the product vision and roadmap. Technical feasibility is part of defining the what.
That’s why hiring a PO too early doesn’t add value. The whole team is already shaping the product direction, and the Tech Lead is naturally bridging both vision and execution.
A Real Example
I once saw a company put their PO in charge of hiring their first designer.
For six months they searched for a “UI/UX Designer.”
But what they really needed was a generalist designer who could handle:
Branding and logo
Product visuals
UI/UX
Full web design
Instead, they interviewed specialists who only did wireframes and prototypes.
Every candidate got rejected. Half a year later—still no designer.
The PO wasn’t incompetent. They were just in the wrong role.
The House Analogy
It’s like building a house.
The architect (Tech Lead/CTO) makes sure the structure stands — and also helps shape the vision of what’s possible.
The interior designer (Product Owner) decides how the rooms should feel.
The builders (engineers & designers) make it all real.
But if you put the interior designer in charge of construction?
They’ll happily give input on cables and wall materials, but without structural expertise, the house will fall apart before it’s finished.
Generalists First, Specialists Later
Another trap for new departments and young startups is hiring specialists too early.
Big companies can afford a UI/UX researcher who only runs usability tests, or a backend engineer who never touches the frontend. In a fresh team, that doesn’t work.
At the start, you need generalists:
A Tech Lead/CTO who is hands-on — a fullstack engineer who can both build and define the architecture.
A generalist designer who can cover branding, UI/UX, and product visuals.
(Optionally) another fullstack/generalist engineer to speed up development.
Generalists create momentum. They get things shipped.
Later, as the product grows, you can add specialists—QA testers, infrastructure engineers, brand designers.
And if you’re thinking about management roles:
A Project Manager (PM) might make sense once your team grows to around 10 people.
A Product Owner (PO)? Realistically, not until much, much later — often closer to 100 people, when product complexity and competing priorities truly demand it.
Hiring these roles too early leaves gaps everywhere, slows progress, and piles on unnecessary overhead.
When Do You Actually Need a Product Owner?
Short answer: not in the beginning.
In the early days of a startup or new tech department, a PO is overhead. Your Tech Lead (who is also a fullstack builder), your designer, and your engineers can talk directly to stakeholders and iterate much faster without someone in between.
If anything, bring in a Project Manager earlier — around a team size of 10. But a Product Owner? In most cases, you don’t need one until you’re closer to 100 people, when product complexity, multiple teams, and stakeholders truly demand it.
Until then, let the real builders build.
Bottom Line
In a startup, the what isn’t owned by a Product Owner. It’s shaped by the whole team — the Tech Lead, the designer, the engineers, and the founders — together.
The Tech Lead isn’t just “the how guy.” They’re a hands-on builder who also bridges into vision and product direction, because feasibility is part of defining the what.
That’s why hiring a PO too early doesn’t add value. Until you’ve scaled to dozens of engineers and multiple stakeholders, the what and the how are better decided collaboratively by the people actually building.
A Product Owner can be valuable later, once the complexity justifies it. But at the early stage, they’re more overhead than help.