By Gregory Garner
GregGarner.net • RequirementSpec.com
For years, companies have been trying to “go product-led.”
That’s not a bad idea on its own — but the way many organizations implement it is.
A growing trend, especially in large IT and software organizations, is to force the Product Owner (PO) role into IT… even when the company isn’t actually practicing Scrum, doesn’t follow Agile the way it was designed, and hasn’t aligned its structure to support true product ownership.
And the result?
Misalignment.
Confusion.
Frustrated teams.
Delayed delivery.
And Business Analysts — some of the most valuable tactical contributors in the software lifecycle — being judged against a role that doesn’t belong in IT in the first place.
In my view, and consistently across industry patterns, forcing the PO role into IT when an organization isn’t truly running Scrum often makes things worse, not better.
Here’s why — and what to do instead.
1. Scrum Gives Us a PO Role… But Only If You’re Actually Doing Scrum
The Product Owner role originated inside Scrum, which is a very specific implementation of Agile.
Jeff Sutherland, co-creator of Scrum, famously says:
“Are you doing it exactly the way we told you?”
Companies always say no.
And that’s where the dysfunction starts.”
Most companies do some version of Agile:
- Standups
- Jira boards
- Sprints (in name)
- Backlogs (in theory)
But if you’re not doing true Scrum, then a “Product Owner” inside IT becomes a misfit role — disconnected from the methodology it was designed for.
The function collapses into something that is neither strategic nor tactical.
And the BA becomes the landing spot for the leftover expectations.
In other words:
If you’re not doing Scrum, don’t borrow Scrum’s job titles.
It creates confusion and organizational friction every time.
2. In Most Successful Companies, the Product Owner Lives in the Business — Not in IT
Across industries — retail, healthcare, finance, manufacturing, government — the pattern is the same:
IT cannot own the product vision. The business must.
Why?
Because true product ownership requires:
- Deep domain knowledge
- Authority to make business decisions
- Accountability for outcomes
- Alignment with revenue, risk, and customer strategy
IT can enable those things — but it can’t own them.
Interview after interview, survey after survey, and research across the industry show the same story:
When IT is forced to act as the PO, two things happen:
- Business feels disconnected from the product.
- IT gets blamed for “owning” decisions it never had authority to make.
This is not theoretical.
Organizations have tried this repeatedly over the last 15 years — and it consistently leads to delivery issues.
That’s why many companies have corrected course by re-moving the PO role back to the business and re-establishing strong BA frameworks inside IT.
It simply works better.
3. The BA Role Is Fragile — and Organizations Break It When They Force PO Behavior
The best BAs have:
- Tactical clarity
- Deep requirement elicitation skill
- Strong modeling and visualization ability
- Technical understanding
- Business empathy
- The ability to bridge communication gaps
- The ability to prevent defects before they happen
- Discipline in scope and detail
These skills prevent project failure more than almost anything else.
And yet — many companies judge BAs against “Product Owner behavior” such as:
- Thinking strategically at the expense of clarity
- Interjecting constantly
- Making decisions on behalf of the business
- Driving business vision
- Prioritizing the backlog
- Acting as a proxy business owner
But when a BA covers these duties without business authority, they get pulled away from the detailed tactical work the project actually depends on.
The BA ends up in a no-win situation:
Responsible for outcomes but without strategic authority.
That isn’t product ownership.
That’s misalignment.
4. A Strong BA Beats a Weak PO Every Time
If I had to choose between:
- A highly strategic product owner who is weak as a business analyst
OR - A highly skilled business analyst who is marginal as a product owner
I would choose the strong BA every time.
Why?
Because the biggest reasons projects fail are almost never strategic.
They fail because:
- Requirements lacked clarity
- Scenarios weren’t fully explored
- Edge cases were missed
- Developers misunderstood intent
- User flows weren’t validated
- Systems behavior wasn’t fully mapped
- The business logic wasn’t visually represented
- Stakeholders didn’t have shared understanding
A BA can prevent all of these.
A PO — especially an IT PO — usually cannot.
Good POs help shape vision.
Great BAs make the vision real.
And in a world where IT delivery is always constrained, the BA’s tactical value is enormous.
5. The Better Model: The BA as the Bridge (The ECHO Framework)
Rather than forcing BAs to become POs, a better approach is:
BA = Bridge Between Business Vision and Technical Implementation
That means:
- Business owns the “What” and “Why.”
- BA interprets, visualizes, and translates the “What/Why” into actionable detail.
- UX/IxD supports user experience direction.
- Dev owns the “How.”
- IT leadership ensures alignment and feasibility.
I call this ECHO, a methodology that integrates:
- Experience Design (UxD)
- Interaction Design (IxD)
- Business Analysis (BA)
- Product Ownership (PO)
ECHO shows how these roles can coexist without forcing one discipline to replace another.
It is methodology-agnostic — Agile, Waterfall, hybrid — because it’s based on how teams actually work, not on how textbooks say they should work.
If you want to see the visuals, I’ve published them on:
👉 RequirementSpec.com
(Visual requirements, models, frameworks, book resources)
6. Why Adding a Product Owner Layer to IT Often Makes Things Worse
From what I’ve seen — and what many leaders have confirmed — implementing a “Product Owner Group inside IT” tends to:
- Create duplicate roles
- Add process overhead
- Slow decision making
- Cause confusion about authority
- Misalign IT and business priorities
- Turn BAs into pseudo-PMs or pseudo-strategists
- Make developers wait longer for clarity
- Unintentionally weaken UX and architecture flow
- Shift accountability downward to the wrong place
This is why even senior leaders who have lived through these reorganizations admit:
“Every company I’ve seen try to force the PO role into IT ends up regretting it.”
The structure simply does not support product thinking if the business isn’t the one driving it.
7. The Better Path Forward (And the One That Actually Works)
A healthier, more sustainable, high-performance model is:
Business:
- Owns strategy and product vision
- Provides the true Product Owner
- Prioritizes outcomes
IT:
- Strengthens BA discipline
- Provides analysis, visualization, requirements, and translation
- Maintains technical stewardship
BA:
- Serves as the communication bridge
- Ensures clarity
- Makes the work implementable
- Visualizes flows
- Ensures alignment
UX + Dev:
- Designs and builds
- Collaborates with the BA and business
- Validates experience and technical feasibility
This is how organizations reduce rework, speed up delivery, and increase trust across teams.
8. Where to Learn More
If you want deeper frameworks, visual models, and applied examples, you can explore:
(My formal methodology, models, and visualization work)
👉 GregGarner.net (Podcasts, thought leadership, future articles)