Do We Need a Great Product Owner—Or Just a Great Team?

In past articles, we’ve questioned the sacred role of the Product Owner. We’ve asked whether AI could replace parts of the role, and explored how roadmaps and strategic clarity can shape meaningful planning. But we haven’t yet asked the question from the place where it all begins—the team.

From the developers, designers, testers, and problem-solvers who show up every day to deliver: what’s their view? Do they need a Product Owner to succeed? And if so—what kind? What does “great” even look like from the inside of the team room (or Zoom room)?

This article flips the lens. It’s not about roles or frameworks. It’s about what really helps teams build great products, solve real problems, and deliver with pride. Let’s dive into the messy, nuanced, and sometimes unspoken truth of what teams need (and don’t need) from the PO.

What Makes a Product Owner Great—From the Team's Perspective?

From a framework point of view, the Product Owner is accountable for maximizing value. But if you’ve spent time embedded in a team, you quickly learn that "value" is not an abstract concept—it’s felt in every conversation, ticket, and iteration. Teams know when value is being delivered. They feel it. And they also feel it when it's not.

A great PO, from a team’s point of view, is not just someone who “owns the backlog.” It’s someone who:

• Brings clarity where there’s fog
• Prioritizes ruthlessly so the team can focus
• Understands business goals but speaks in the team’s language
• Knows when to say no—and when to fight for yes
• Is available, prepared, and present

A great PO doesn’t “delegate” ownership of product decisions, but also doesn’t dictate. They guide, challenge, and listen.

The flip side? Teams also know when they’re working with an absentee PO, a yes-person, or a glorified backlog typist. These roles often create more noise than clarity. The team fills the gaps, makes assumptions, or worse—slows down while waiting for decisions that never come.

So no, teams don’t need a person with the PO title. But they absolutely need someone—or several someones—to carry the responsibility for product clarity, prioritization, and decision-making.

PO as Role vs PO as Responsibility

Let’s draw a distinction: there’s a difference between the role of a Product Owner and the responsibility for owning the product.

The role is a construct—a seat at the Agile table. The responsibility is real work: aligning intent, making calls, engaging with customers, slicing value, and keeping the product alive and focused.

In some teams, especially mature or cross-functional ones, this responsibility is shared. The designer owns part of it. The tech lead owns part of it. The tester challenges assumptions. The developer asks the hard questions. In these teams, the PO might feel less like a gatekeeper and more like a facilitator of learning and focus.

But in most teams—especially growing ones—not having a clear PO is a risk. Decisions get deferred. Priorities wobble. Stakeholders scatter. It becomes tempting to “just build stuff” and hope it lands.

So how do you build alignment without creating a bottleneck?

Behavior-Driven Development: A Team Owning the Product—Together

If you’ve ever worked in a team that really practices Behavior-Driven Development (BDD), you know: it’s something different.

Not a checklist. Not a ceremony. Not just “Given, When, Then” syntax.
It’s a mindset—and a method—that brings the PO, the developers, and the testers together in a shared conversation about behavior before implementation.

• The Product Owner brings the business perspective: What problem are we solving? What outcome are we after?
• The Testers bring the quality lens: What are the edge cases? What will we regret not asking?
• The Developers bring the technical clarity: What’s feasible? What assumptions are we making?

They don’t just exchange documents. They sit together (virtually or physically) and co-create examples that clarify intent. They describe system behavior in plain language. They challenge each other’s understanding. They explore what success—and failure—looks like before a single line of production code is written.

These conversations are then encoded in Gherkin syntax, yes. But that’s the artifact. The real value is in the conversation.

A dream? Maybe. But it happens.

When done well, BDD isn’t just a test technique. It’s a design practice, a communication protocol, and a shared mental model. It creates alignment that documentation can’t.

And here’s the key: it distributes product thinking. It makes the product everyone’s business. The PO is no longer the only one “thinking about the user.” That mindset is now embedded in how the team works.

And the payoff?

• Fewer misunderstood requirements
• Reduced rework and context-switching
• More stable code
• Better morale
• Faster iteration from idea to deployment

So why is this practice still rare?

Because it requires:

• A PO willing to co-create, not just hand over
• A team willing to challenge and engage, not just build
• Time, space, and trust to talk before doing
• Skills in facilitation, listening, and example writing

And perhaps most importantly—it requires team maturity.

Not all teams are ready to "think like product owners." That’s okay. This kind of shared ownership grows over time. It emerges in environments with psychological safety, real collaboration, and a PO who invites conversation rather than guarding context.

Given the user is logged into the system  
When the customer buys an item  
Then the stock should be updated

So—Do Teams Need a Product Owner?

Let’s be honest: most teams still do.

Not because they can’t think for themselves, but because product ownership is hard, exhausting, and nuanced work. Someone has to:

• Say no more than they say yes
• Keep context alive across dozens of moving parts
• Field stakeholder noise and distill it into clarity
• Balance value, risk, feasibility, and sequencing

And do it all while building trust with the team.

But maybe the future isn’t less PO. Maybe it’s not about replacing the Product Owner with AI, or dissolving the role into the team entirely.

Maybe the future is a more active PO—working together in the team, >with the team, guiding the team to solve the right business problems.

Not a gatekeeper. Not a mini-CEO. But a focused, present, collaborative voice of the customer. Someone who joins conversations, shapes direction, and helps the team think—not just deliver.

And maybe, in the best teams, everyone starts thinking like a Product Owner.

Where to Start (If You’re Leading Several Teams)

If you’re leading multiple teams and curious to try this:

• Start with one team.
• Choose an upcoming feature—not too small, not too strategic.
• Invite the PO, testers, and developers to co-create a few BDD scenarios.
• Don’t start with a tool. Start with a shared document or Miro board.
• Focus on the conversation first. Gherkin second. Automation last.

That’s how real BDD starts. Not with tooling—but with talking.

Want to share your story?

Have you worked in a team where BDD worked? Or where the PO role evolved—or disappeared—and the team thrived?

What made it work? What surprised you?

Send me a note. I’d love to hear your story—and maybe feature it in a future piece.

Extra: How This Gherkin Becomes a Real Test (Python + Behave)

In tools like Behave, Gherkin scenarios aren’t just ideas—they become automated, living documentation. Below a short example that maybe gives you an idea how it can work in real test code.

@given("the user is logged into the system")
def step_impl_user_logged_in(context):
    context.user = login_user()

@when("the customer buys an item")
def step_impl_buy_item(context):
    context.order = context.user.buy("item-123")

@then("the stock should be updated")
def step_impl_stock_updated(context):
    assert stock_level("item-123") == expected_value

Last updated May 13, 2025