Product Archives - Scrum Master Toolbox Podcast

Wasim Osman: The Agile Product Owner Who Runs Two Quarters Ahead of the Team

The Great Product Owner: The Absolute User Who Works Two Quarters Ahead

“The Product Owner needs to be the absolute user of the software—the user’s journey so well defined in their mind that every engineer’s question already has an answer, with context.” – Wasim Osman

Wasim’s best Product Owner works ahead of the team without doing the team’s work. Their product roadmap is well-defined at least two quarters ahead of the development cycle, so nobody is panicking against tomorrow’s deadline. Designers and product people work on concepts months before development starts, which gives them room to show early ideas to engineers and gather feedback while there’s still time to change course.

Crucially, this PO is the absolute user of the software—so completely inside the user’s journey that when an engineer asks “how does this connect to that module?”, the answer is ready, with context. Wasim connects this to how his team uses AI today: the PO can run ahead, spin up prototypes, and iterate on the ideas without burdening the team with building throwaway work—while staying the voice of the customer.

Self-reflection Question: How far ahead of your team is your Product Owner really working—and could they answer an engineer’s design question today without going back to the drawing board?

The Bad Product Owner: When Optimism Overrides the Data

“They were optimistic without any data. We had the data—they were just being wishful.” – Wasim Osman

The worst anti-pattern Wasim has seen is the Product Owner whose optimism overrides the evidence. In one company, a customer asked for a delivery estimate, and the product team promised an aggressive date—”optimistic without any data,” even though the data existed. When the engineering team sat down with the numbers, it was obvious the date was impossible, but that gap never reached the customer.

The product team stayed disconnected from both the engineers and the customer, so expectations kept drifting from reality. Wasim, who held the data, finally bridged the two and told the product team the real timeline was several months later. They “lost their minds”—but by then it was too late to renegotiate gracefully.

The deeper anti-pattern: features handed down without enough depth, so the moment engineering hits real questions mid-development, the PO panics and rushes back to the drawing board while development is already in motion. As Wasim says, “optimism just took over too much.”

Self-reflection Question: When was the last time optimism—not evidence—set a delivery date on your team, and who had the data that should have been in the room?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches – Scrum Master edition audiobook includes hours of audio interviews with SM’s that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!

About Wasim Osman

Wasim Osman is a seasoned Agile Coach and a Product Owner at Orkestra SCS. He launched his agile career at a Silicon Valley startup based in New York, then spent years coaching teams across Canada, helping organizations transform how they deliver value. Wasim brings a rare blend of agile discipline and product thinking. He’s passionate about building technology that drives real business impact.

You can link with Wasim Osman on LinkedIn.

Havva Sevay: From “Scrum Master Is the Secretary” to True Co-Leadership

The Great Product Owner: The Co-Leader Who Mastered the PO Stances

“Co-leadership means both sharing leadership in a lateral way, not a disciplinary way—the PO owns the technical part, the Scrum Master the organizational part.” – Havva Sevay

Havva’s best Product Owner already understood co-leadership—and went further. He used the Product Owner stances from Scrum.org as a feedback tool, asking the team to rate him on each stance (customer representative, company representative, and so on) with a percentage, then using that input to improve his skills deliberately.

It’s the same mindset Scrum Masters can adopt with their own stances: be aware of the options, get honest feedback, and adapt to the context, because the right stance changes over time. A great PO, in Havva’s experience, treats their role as a skill set to be developed in partnership—not a title to defend.

Self-reflection Question: Could the PO stances become a feedback tool in your team—and would you be willing to be rated on your own Scrum Master stances?

The Bad Product Owner: “The Scrum Master Is My Secretary”

“The worst is the PO who believes he’s the product manager and the Scrum Master is the secretary. I said: I’m not your assistant, I don’t bring your coffee.” – Havva Sevay

The worst anti-pattern Havva has lived through is the Product Owner who treats the Scrum Master as a secretary—there to share the screen, organize the meeting, and take orders. Havva confronted it directly in a one-on-one: this is upside down. My job is to teach self-organization, not to be your assistant. But she didn’t stop at the boundary—she helped the PO understand her role and walked in his shoes too, even sending him to a Scrum Master training while she experienced his responsibilities.

Her strongest recommendation: from the very first meeting with a Product Owner, talk explicitly about who does what, surface expectations, and agree how you’ll work together. Don’t assume they know your job—or that you know theirs. The way out of the “secretary” trap is co-leadership: lateral, shared leadership built on time and trust.

Self-reflection Question: Have you ever explicitly agreed with your Product Owner on who is responsible for what—or are you both operating on untested assumptions?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Havva Sevay

Havva is a people-focused organizational development expert with a Master’s in Business Administration and certification as a Scrum Master. She empowers teams and leaders through agile methodologies, modern leadership, and a strong feedback culture, fostering psychological safety and collaboration. Passionate about HR initiatives, Havva shapes people strategies, enhances employee experience, and drives inclusive, high-performing workplaces built on trust and engagement.

You can link with Havva Sevay on LinkedIn.

Danil Chernyshev: The MIA Product Owner vs. The One Who Owned the Outcome

The Great Product Owner: Communicating Value, Inviting the Right People

“It’s basic Scrum—but it’s not basic.” – Danil Chernyshev

The best Product Owner Danil ever worked with was Jamie Spence, on a Master Data Management re-architecture at Canadian Tire. The goal wasn’t only to upgrade a system—it was to rethink how a major retailer with many different banners should work across all of them. Jamie didn’t write user stories; the BAs did that.

What he did was communicate, in a super-clear way, the value expected at every step. He didn’t attend every daily Scrum, but he was there whenever the team wanted him, allocating his time on demand. He cared about user experience and lived for the feedback loop—”this sprint I want to deliver this part and see how it goes.” And he invited the proper stakeholders to each sprint review: a small, deliberately varied group chosen by what had been delivered and whose feedback the team actually needed.

As Danil and Vasco agree, it sounds obvious—and that’s exactly why it’s worth celebrating. Obvious and common are not the same thing.

Self-reflection Question: Does your Product Owner communicate expected value at every step—or just hand over user stories and disappear?

The Bad Product Owner: Present on Paper, Missing in Action

“On paper, you have a Product Owner. But you don’t have a Product Owner.” – Danil Chernyshev

The most common—and worst—anti-pattern Danil sees is the MIA, or “missing in action,” Product Owner: a person with the title who doesn’t actually own the product. Sometimes it’s a BA or a tech lead wearing the label; sometimes it’s someone who simply can’t make decisions, or doesn’t understand what they’re responsible for because they’re busy doing another job.

The fix starts with clarity: first understand what the product even is, then put in place a Product Owner who makes decisions, owns the end-user experience, and maximizes value. Danil also flags a structural trap—one Product Owner per product, not one per team.

He stretches the idea with vivid examples: an Agile coach leading a transformation is effectively the Product Owner of the process, with Scrum Masters as the developers; and Steve Jobs was the Product Owner of the iPhone while also being a customer for other Product Owners building pieces of it. Ownership is about maximizing value for the customer—not about who writes the user stories.

Self-reflection Question: Is your Product Owner empowered to make decisions and own outcomes—or just a title on an org chart?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Danil Chernyshev

Danil is a results-driven Scrum Master and Delivery Manager passionate about optimizing SDLC processes and unlocking development teams’ potential. With a keen interest in AI, he empowers organizations to innovate and excel, bridging agile practices with cutting-edge technology for impactful results.

You can link with Danil Chernyshev on LinkedIn.

Alf Dobbert-Baums: The Too-Technical PO and the One Who Was Willing to Experiment

In this episode, we refer to Shift: From Product to People and the value of keeping the PO–developer conversation at the goal level.

The Great Product Owner: The PO Who Was Willing to Drop the Spec and Trust the Developers

“Let’s ditch the technical part, and let’s see what happens.” – Alf Dobbert-Baums

The Great PO, in Alf’s experience, is willing to experiment with letting go. She stopped writing detailed technical specifications and started writing plain user stories. Then — and this is the harder move — she stopped throwing them over the fence and walked into the developers’ space to have the conversation. Alf had coached her toward it, and he watched the trust compound.

Because she trusted the developers on the how, she had less work to do (the developers were closer to the system anyway) and the developers had room to make real decisions. The conversation stayed where it belonged: on the goal. Alf names the pattern this great PO embodied — open to experiments, willing to say “let’s see what happens,” and quietly resisting the seductive pull of getting technical because it feels safer. The Scrum Master’s job is partly to make that letting-go feel safe enough to try.

Self-reflection Question: Where is your PO still writing the “how” — and what would it take for them to trust the developers enough to write only the “why” and the “what”?

The Bad Product Owner: The PO Who Thinks They Know More Than the Developers

“He said: ‘developers can retrieve the information from the archive database.’ The developer said: ‘the information is not in the archive database.'” – Alf Dobbert-Baums

The anti-pattern is the PO who is too technical — the one who writes specs full of implementation detail and treats the developers as executors. Alf calls him John. John wrote a user story that told the developers exactly where to fetch the data from: the archive database. Then he tried to hand the story to Alf to present, the way a memo gets handed across a desk.

Alf refused.

He insisted John present it to the developers himself. John did.

The first developer to speak said the information wasn’t in the archive database. Alf hopes that moment humbled John a little. The point isn’t whether John was right about the database — the point is the dynamic. When the PO writes the technical answer into the story, the developers stop being collaborators and become receivers. The translation work that creates real value — between user goal and technical option — never happens. The PO ends up with more work, less ownership from the team, and worse outcomes.

In this segment, we refer to Shift: From Product to People and the idea that great POs facilitate the conversation between user goal and team, rather than dictating it.

Self-reflection Question: When was the last time your PO wrote a technical detail into a story and the developers had to walk it back — and what would change if the PO trusted them to design the “how”?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Alf Dobbert-Baums

Alf lives in Berlin. He studied Theater/Religion at the Freie University Berlin. He is a Systemic Organizational Consultant, a Scrum Master and Agile Coach. He has also been a freelancer for Usability and Requirements Engineering for car manufacturers. At “Verti” he led the agile transformation.

You can link with Alf Dobbert-Baums on LinkedIn.

Mirco Gerling: The Hydra Product Owner and the PO Who Made Trust Possible

The Great Product Owner: Precision That Builds Team Trust

“He always had an answer, or if he didn’t have the answer, he tried to ask the clients, the users, the stakeholders.” – Mirco Gerling

In pharmaceutical software, the wrong dose can kill someone. So when Mirco worked with a PO in that domain, precision wasn’t a virtue — it was a survival requirement. The PO wrote meticulous user stories in classic “As a user, I want… so that…” format with very good acceptance criteria.

The developers always knew what done meant. And when, mid-sprint, the team spotted a gap — “Is 80% tolerance of 100% or 80% of all?” — the PO was there, asking the right people, refining or splitting the story, never letting ambiguity ship. Even when half the team was out sick in winter, the remaining developers could deliver because the user stories were clear enough to stand on their own. Stories linked to automated tests.

Each acceptance criterion traceable to the test that proved it. The result: a team that trusted their PO. As Mirco puts it, that trust came from one thing — the PO had already done the work needed to help the team understand what to do and how they’d know it was done.

Self-reflection Question: What’s the level of precision in your team’s user stories signaling to your developers about how much you trust them — and how much you’ve prepared for them?

The Bad Product Owner: The Hydra PO with Seven Heads

“If the developers had questions, the people said: ‘it’s not my ticket, it’s not my story.'” – Mirco Gerling

Five Scrum teams. One Product Owner. Seven requirements engineers writing user stories alongside. Eight people doing the work of product ownership — and nobody owning any of it. Developers learned quickly that asking a question meant being bounced from one requirements engineer to another. “It’s not my ticket.” The eight-person PO group split into two sub-teams who, when they spoke about each other, used “you” and “they” instead of “we.”

Decisions made in week one collided with decisions made in week three. Mirco’s intervention: treat the PO group like a Scrum team. Eight people is a team-sized group. Run retrospectives with them. Get them communicating as a unit instead of as parallel individuals.

The one anchor that kept things from completely falling apart was the single PO at the top, who could still say “this feature we need at the end of the year, the other can wait.” Without unified prioritization, the hydra has no direction — just seven heads pulling in seven ways.

Self-reflection Question: Where in your product organization are decision-makers proliferating without a shared mandate — and what’s the cost in clarity for the teams downstream?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Mirco Gerling

Mirco is an experienced Scrum Master in the public sector. With a strong IT background, he has spent 25 years developing software and driving agile transformations. Passionate about innovation and teamwork, Mirco brings expertise and dedication to every project.

You can link with Mirco Gerling on LinkedIn.