Should Product Owners Come From Business or Tech?

Let me start with a question:

If you had to hire a Product Owner tomorrow, would you look for someone from the business… or someone from tech?

Most people have an immediate gut reaction.
And almost everyone believes their answer is the “right” one.

After 30+ years working across ten industries, from utilities to public sector, finance, pharma, and digital products, I’ve seen this debate turn into full-blown turf wars inside organisations.
Business says, “We know the customer!”
Tech says, “We understand how the system actually works!”

And somewhere in the middle stands the Product Owner… trying to keep everyone aligned while shipping something meaningful.

Let’s talk about this honestly.

What Does a Product Owner Really Do?

Forget the job title for a moment.

A great PO is someone who can:

• Understand customer needs and pain points
• Align the product vision with business and strategic goals
• Translate problems into outcomes, and outcomes into backlog items (something developers can build)
• Prioritise ruthlessly based on value…and effort
• Challenge stakeholders (politely!)
• Understand technical constraints
• Make tough calls quickly
• Keep the team focused on outcomes, not tasks
• Make quick decisions based on trade-offs, risks, and constraints
• Communicate clearly with stakeholders, leadership, customers, and developers
• And most importantly… stay obsessed with the customer

It sounds simple.
It’s not.

If you’ve ever been a PO, you know the emotional rollercoaster:
Decision fatigue, competing priorities, endless trade-offs, and days where everyone wants something “urgent” from you.

So… should this person come from Business or Tech?

This is not purely a business role.
This is not purely a technical role.
This is a hybrid, strategic, translation role.

Let’s unpack it with real examples.

 

The Case for Business-Origin Product Owners

I once worked with a PO who came from a customer service operations team.
She wasn’t technical at all.
Couldn’t read a sequence diagram if her life depended on it.

But she did understand her customers.

When developers asked, “Why do users do this?”
She’d give an answer and a story.

When stakeholders said, “We need feature X,”
she’d say, “Will this reduce call centre volume by at least 10%? If not, then no.”

That level of business clarity saved months of wasted effort.

Business-origin POs shine in:

✔ Customer empathy
✔ Understanding operational reality
✔ Making decisions that align with business value
✔ Managing stakeholders who trust them

But…

Sometimes business POs struggle with technical feasibility.
And you can’t prioritise what you don’t understand.

Ever seen a backlog full of items that were “one-day tasks” in the business mind… but turned out to be three-week integration nightmares?
Exactly.

 

The Case for Technical-Origin Product Owners

Now let me flip the script.

I worked with a tech-origin PO on a platform modernisation project.
This guy could glance at a user story and immediately know:

• the data implications
• the integration risks
• the hidden dependencies nobody mentioned
• the performance issues that would appear 6 months later

Developers loved him.
He spoke their language.

But here’s the emotional truth:
He struggled to let go of how things should be built.
He often designed before he defined the problem.
And sometimes, he’d unintentionally bulldoze over customer needs because the solution was “elegant.”

Technical-origin POs shine in:

✔ Understanding technical complexity
✔ Producing clear, realistic requirements
✔ Avoiding rework
✔ Building trust with engineers

But…

They can get too deep into the “HOW” and forget the “WHY.” This results in feature-rich but customer-poor products.

 

 

So Who Makes the Better Product Owner?

Here comes the twist:

Neither business nor tech produces great Product Owners by default.

The BEST Product Owners, the ones who deliver value consistently, are the ones who can bridge the gap between business, people and technology.

Think about the last great PO you worked with.

Were they:

• curious?
• calm under pressure?
• good at saying “no”?
• empathetic with customers?
• technically aware, even if not a coder?
• respected by both business and tech teams?

That’s the magic combination.

It’s not where they came from.
It’s who they are.

 

What Organisations Keep Getting Wrong

Here’s the part nobody likes to admit…

Mistake #1: Assigning a PO based on “who’s available”

One leader literally told me:

“Just give it to Mary. She has the lightest workload.”
Spoiler: That product never launched.

Mistake #2: Treating the PO as a business representative

This leads to endless escalation loops because the PO can’t make real decisions. They need to consult with the business.

Mistake #3: Assuming tech knowledge isn’t important

I don’t care how business-savvy you are, you must understand your product’s technical ecosystem enough to make informed trade-offs.

Mistake #4:  They misunderstand the role of product thinking.

Backlogs, stand-ups, and sprint reviews don’t make you a Product Owner.
Product thinking does. Great POs anchor every decision around outcomes and customer value, not project tasks, stakeholder demands, or architecture purity.

 

So How Do You Choose?

Here’s a simple rule:

Choose a Business-Origin PO when the product is customer-facing, commercial, or experience-driven.
Examples:

• onboarding journeys
• e-commerce
• CRM improvements
• claims processing

 

Choose a Technical-Origin PO when the product is deeply architectural or integration-heavy.

Examples:

• APIs
• platform migrations
• regulatory reporting systems
• data transformations

 

Choose a Hybrid PO with a Business Analysis background when the initiative is complex, cross-functional, or enterprise-wide.

This is usually the case in digital transformation programmes, greenfield platforms or enterprise-wide initiatives.

 

Final Thought

When I look back at the best Product Owners I’ve worked with, the ones who shipped real value, kept teams motivated, and navigated chaos with grace, they had one thing in common:

They were bridge builders.

They weren’t defined by their background.
They were defined by their mindset.

Curious.
Empathetic.
Decisive.
Business-aware.
Technically-literate.
Customer-obsessed.

So… should Product Owners come from Business or Tech?

They should come from people who can navigate both worlds and make sense of them.

Not everyone can.