The sentence shows up with suspicious regularity.
In trainings.
In job descriptions.
In confident statements delivered with the calm authority of something that is obviously true.
The Product Owner should come from business.
It sounds reasonable.
It sounds clean.
And like many reasonable, clean statements, it collapses the moment it touches reality.
How the Myth Shows Up
During the years I gave Scrum Product Owner and Scrum Master trainings — mostly in large corporations — one question kept resurfacing:
“Should the Product Owner come from business or from IT?”
People expected a rule.
A guideline.
A best practice.
Not an answer — a confirmation.
My answer was always disappointing.
Find the right person.
Someone willing to take decisions — and carry their consequences — without hiding behind boards, committees, or process.
Someone capable of slicing a bloated requirements document into something a development team can actually work with.
Someone who can translate between two languages that use the same words, but mean entirely different things.
Finding that person is already hard enough in a large organization — even without the business-vs-IT debate.
And just to be precise: when I say “IT” in the rest of this post, I mean people who have actually built software — developers, architects, QA engineers.
Not project managers who once sat close to a server room.
And not people who watched a two‑hour online course and now introduce themselves as data engineers.
An Inconvenient Observation
After more than 30 years in software development, I’ve noticed something that tends to irritate people:
It is usually easier for a developer to understand the business
than for someone from business to understand software development.
I have never worked on a software project where I didn’t understand most of the supposedly “extremely complicated domain” within a few weeks — more than what a Product Owner actually needs at the beginning.
The other direction is harder.
People without any affinity for software development often never reach the level of understanding required to communicate effectively with a development team. Not because they’re stupid — but because abstraction only goes so far before it breaks down.
According to the Scrum Guide, the Product Owner doesn’t need to discuss technical details with developers.
That is a beautiful theory.
This is what happened when I had to live with its consequences.
A Story From the Impact Zone
I joined a project that had already been running for a few months.
My task was to replace the existing project manager — another freelancer.
The project goal was to extend an existing in‑house application so it could replace a third‑party system — and eventually become more than the sum of both.
And as both systems shared a lot of data, from a business perspective, that decision made perfect sense.
The reason for replacing the project manager was simple:
“There’s no progress.”
In the same breath, they told me the domain was completely different from anything I had seen before.
Not comparable.
Much more complicated.
I agree with not comparable.
I disagree with much more complicated.
What I Ran Into
- An existing Application with uneven usability across user groups
- A Backlog written by a Product Owner from business, assisted by a business consultant, and Jira “user stories” consisting mainly of annotated screenshots of the existing application
- A Product Owner who had to do this job on top of his actual job, with no guidance, no training, and unfortunately chosen priorities
- A Project Manager acting as a pure pass‑through, with a strong focus on processes and workflows, and without understanding of the business
- A near‑shore Development Team expected to implement features based on images, barely knowing what they were building, and blamed for being slow
A familiar constellation.
Stepping Into the Product Owner Role
I started working closely with the Product Owner, learning the business as fast as possible.
He was a great teacher.
At some point I asked him to hand over responsibility for the backlog to me — informally at first. “Let me act as Product Owner. Keep your fingers off.”
Reluctantly, he agreed.
Only twelve months later did I become the official PO.
And he supported me throughout.
When “Obvious” Isn’t Automatic
Being in that role put me in a position I had seen before — as Product Owner and in other roles.
What was obvious to people from the business side was not automatically obvious to developers.
And it wasn’t automatically obvious to me either.
One of the reasons is simple: when something is obvious to you, you tend to skip steps when explaining it.
Context disappears.
Assumptions stay implicit.
Details are left out because “everyone knows that”.
For developers, those skipped steps are the missing links that make understanding possible.
And for me, still learning the domain, they were exactly the parts that needed to be made explicit.
That made translation possible — not because I understood the business better than others, but because I was close enough to the developers’ perspective to notice what hadn’t been said.
The Part Nobody Checked
After rewriting and re‑prioritizing the backlog, I thought we were finally ready to move.
I was wrong.
Progress didn’t stop — it became expensive.
When the company decided to extend the existing application, they failed to ask a question that should have been asked first.
Is the application actually extensible?
The answer was no.
- Almost no automated tests
- Spaghetti code — worse than Mikado code, because nobody knew why things moved
- Code scattered all over the place, even duplicated across repositories
- No documentation
- A data model that made no sense
Taken together, this made every attempt to move forward start with cleaning up the past.
How This Happened
The first version of the application had been built in just six months — by another team.
That time frame already explains a lot.
Speed had been the dominant concern.
Visible functionality mattered more than what could not be seen on a screen.
The Product Owner at that time came straight from the business.
He passed requirements to the development team and validated what came back against those requirements.
And he did that part well.
What was largely absent were non‑functional requirements.
I never found any. Nobody could point me to any.
Performance beyond vague response times.
Maintainability.
Testability.
Structural sustainability.
Those things rarely show up in screenshots.
And if you don’t look for them explicitly, they tend to stay invisible.
At that stage, this could have been addressed.
Regular technical assessment by an external party would at least have made the limitations visible.
So would a stakeholder capable of defining and validating non‑functional requirements.
Neither happened.
So the application worked.
It did what it was required to do.
And it was implemented quickly.
But it was built to ship, not to sustain.
When the company later decided to build on top of it — a perfectly reasonable business decision — they inherited all the consequences of that initial focus.
From that point on, progress was no longer a question of effort.
It was a question of friction.
Did We Still Deliver?
Yes.
Thanks to:
- the original Product Owner of Version 2
- supportive stakeholders
- the help of a fast‑learning intern
- and a development team that consciously took ownership
We released Version 2.
A few sprints later than planned.
With full scope.
That was the goal.
Q&A (Because This Topic Attracts Absolutes)
Q: What are the advantages of having a Product Owner from IT?
An IT‑native Product Owner brings a few things that are often missing otherwise:
- A fresh perspective on business assumptions — including the ones nobody questions anymore
- A willingness to challenge what stakeholders take for granted
- More resistance to hierarchical pressure from business
- Better translation between intent and implementation
Q: Does it automatically fail if the Product Owner comes from business?
No. I’ve worked with excellent business‑side POs.
They succeeded because they:
- were aware of their lack of technical knowledge
...and acted accordingly - worked with teams that took ownership
- didn’t optimize for personal safety when the work required otherwise
- encouraged questions instead of hiding behind roles
Q: Does it always work if the Product Owner comes from IT?
No. But the good ones:
- discuss technical issues without hijacking decisions — and accept when developers choose a different solution
- don’t touch the code — even when they could — except maybe a small hot‑fix, and only by agreement
- know when their technical expertise is no longer helpful
- and can talk “business”
So… Should the Product Owner Come From Business?
That question is part of the problem.
It reduces a complex role to an organizational origin story.
It replaces thinking with classification.
The real question is simpler — and harder:
Can this person bridge reality?
Between business intent and technical consequence.
Between wishful thinking and constraints.
Between “this should be easy” and “this will hurt”.
Where they started matters far less than whether they can stand in the middle — and stay there when it gets uncomfortable.
Everything else is a convenient lie.