product development Archives - Scrum Master Toolbox Podcast

Sheik Meeajaun: Product Owners Need the Justified No to Protect Customer Value

In this episode, we refer to Vasco’s Product Owner episodes, where Product Owners share their own lessons from the role.

The Great Product Owner: Owning the Product and Practicing the Justified No

“No, you cannot have this, but this is why.” – Sheik Meeajaun

Sheik’s model for a great Product Owner came from a mentor he worked with early in his career. That PO owned his slice of the product, delivered consistently, and taught Sheik the power of the “justified no.” A strong PO does not simply reject stakeholder requests.

They explain the trade-off, ask what should be removed from the sprint, and make business value visible. If a stakeholder wants urgent work, the PO can ask them to get agreement from the person whose work would be displaced. That shifts the conversation from pressure to prioritization. For Sheik, great Product Owners understand that their job is to bring value to the business and delight customers.

They care deeply enough about the product to protect it from random requests, HiPPO decisions, and backlog noise. They know success is not only delivery. It is the visible appreciation that comes when people recognize a product decision created real value.

Self-reflection Question: Does your Product Owner have a practical way to say no that protects value without turning every request into conflict?

The Bad Product Owner: The Executor Who Cannot Say No

“A Product Owner’s primary job is to bring value.” – Sheik Meeajaun

The anti-pattern Sheik warns about is the Product Owner as executor. This PO does not own the product, does not know the customers deeply enough, and does not push back when leadership changes direction. They become a project manager with a backlog, accepting whatever the highest-paid person in the room asks for next. The team then loses coherence, the product loses a clear direction, and the Scrum Master is left helping the team manage the consequences of weak ownership. Sheik is careful not to blame only the individual.

Many POs are placed in the role without mentoring, without a clear understanding of product ownership, and without the organizational support to say no. The result is predictable: a mountain of requests, no clear value conversation, and a team delivering work without a strong product story behind it.

Self-reflection Question: Where is your Product Owner being treated as an order taker instead of the person accountable for product value?

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 Sheik Meeajaun

Sheik is a seasoned product and Agile leader with over 20 years of experience scaling innovative, customer-centric digital solutions. A certified Scrum and Agile expert, he bridges strategy and execution, driving high-performance teams at enterprises like Rabobank and citizenM. As a hands-on builder, Sheik created Scrumling—a free, interactive Agile training platform—and ScrumJobs.net, a niche job board for Agile professionals. His passion lies in transforming theory into impactful, real-world results.

You can link with Sheik Meeajaun on LinkedIn.

You can also explore Scrumling, ScrumJobs.net, and Simatech.

BONUS: How Scrum Masters Turn AI Into a Thinking Partner, Not a Magic Answer Box With Dave Westgarth

Everybody talks about AI in theory. In this BONUS episode, Dave Westgarth talks about it in practice — the boring, everyday ways a Scrum Master and Agile Coach actually puts AI to work. From t-shirt sizing to sprint reports to a self-coded Monte Carlo forecaster, Dave shares what works, what doesn’t, and the one mindset shift that separates people who get value from AI from those who just generate more noise.

From “Magic Answer Box” to Personalised Partner

“Instead of taking it as a magic answer box, using it as a personalised partner to work through problems, look at your ideas, and really hold them in the cold light of day before proposing things.”

Dave came into agile from a development background, moved through project delivery, and had already worked at AI and ML companies long before ChatGPT made the technology personal and accessible. Like most people, he first met these tools as a “magic answer box” — ask a question, get an answer, run with it.

The real shift came when he stopped optimizing for output and started using AI to drive better outcomes: ping the model, get a response, then interrogate it, refine the thinking, and go around again. The value isn’t the first answer. It’s the conversation that sharpens your own reasoning.

These Tools Aren’t Neutral — So Corner Them Into Being a Critic

“If you ask it to be punishing, negative, and brutal, it gives you a lot more relevant feedback.”

One of Dave’s sharpest points: AI tools are not neutral guides. Because of their system prompts and the incentives baked in by the providers, they’re relentlessly positive — they want to affirm you and keep you around, a little like social media.

That makes them weak for anything where you need honest pushback: personas, user stories, feedback on ideas. Dave’s fix is to flip it on its head. Rather than asking “is this any good?” (which reliably earns an “8 out of 10, but to make it a 10…”), he tells the model to be as harsh and brutal as it can and really try to punish the idea. You don’t want a partner that always agrees with you — you want one that pinpoints the areas you haven’t thought about.

The First Real Time-Saver: Reports, and the Themes You Missed

“Are there any themes that have emerged over the last 4 weeks that I might have missed in this latest deck?”

The first thing that stopped feeling like a party trick was the one we all know: project documentation and reporting — sprint reports, status updates, review decks. Instead of letting AI invent the structure, Dave feeds it his own structure plus Teams recordings, notes, and existing docs, and lets it populate the format he already uses.

The trick that goes a level deeper: after several sprints, feed all the AI-assisted reports back in and ask what themes have emerged across the last four weeks that this latest deck might have missed. Again, it stops being an answer box and becomes a partner and critic.

AI Is Part of the Job Now — Like Spreadsheets Once Were

“The way to get ahead now is figure out how to use it as effectively as you can in your role.”

Dave sees the early resistance movement against AI as a false economy. For delivery professionals — project managers, Scrum Masters, agile coaches — knowing how to use these tools well is fast becoming a core expectation, not a nice-to-have.

Vasco draws the parallel to spreadsheets: once dismissed as too complicated and “not my kind of thing,” until people started building real forecasting and capacity models with them and the work changed. AI is on the same arc — still a little mystical today, genuinely useful tomorrow, and eventually just another tool in the box.

A Week With AI in the Loop

“The power that these prompt-to-product tools give you to create these hyper-personalized tools that make you more effective is, in a lot of ways, magic.”

Dave walked through what his week actually looks like with AI in the loop:

- Monday primer: a scheduled ChatGPT task emails him a scene-set every Monday — last week’s plan and top priorities — so he isn’t spending the first half hour reconstructing where things stood.
- Priority calls: which items are the toughest, where the quick wins are, where he can get early traction, and where risks might be emerging that he can squash early.
- Everyday comms: drafting the bones of emails, pings, and project updates so he spends almost no time formatting.
- Prompt-to-product tools: using Base44, Lovable, and Replit to build his own tools — including a Monte Carlo forecaster that takes his team’s sprint throughput and projects the remaining backlog, replacing an ugly spreadsheet with a clean web app. He also builds AI-powered widgets in Miro for retrospectives, mood check-ins, and planning poker.

The theme running through all of it: hyper-personalized tooling, shaped by your team and your own skills, rather than one-size-fits-all software.

The Myth That AI Makes Scrum Masters Worse

“I can’t see any role of a knowledge worker where having an LLM at your disposal makes you less capable, less knowledgeable, less skilled than someone that doesn’t.”

Dave sees the same adoption spectrum among developers and Scrum Masters — from “I’ll never touch it” to “I’ll never write code by hand again.” And he pushes back hard on an emerging prejudice that echoes the old “technical Scrum Masters are worse” debate: the idea that Scrum Masters who use AI are somehow weaker.

Used well, AI lets you elevate your strengths and cover your gaps — a people-centered Scrum Master can become far more technical, and a technical one far more people-centered, each with a trusted teaching guide right there. The key competency isn’t avoidance; it’s discernment about when to reach for the tool and when not to.

From More Output to Better Outcomes

“The bottleneck has never really been typing code. The bottleneck has been understanding the problems and the customers well enough to define a solution that fixes them.”

Dave’s clearest reframe: AI is driving the price of output down. When volume is easy — more features, more emails, more documents on demand — churning out more of it stops being a differentiator, because everyone can do it. What matters is deciding which problems are worth solving and finding the most effective solution.

Experienced agile professionals have always known the real bottleneck was understanding the customer well enough to define the right solution, not the typing. AI just exposes that in a much starker way: there’s nowhere left to hide behind sheer volume.

What to Pay Attention To — and a Monday Experiment

“It can do a lot of that manual, low-thinking, high-effort work to free you up to do more of the really impactful stuff.”

For Scrum Masters being told to “adopt AI,” Dave’s advice is to let it take the joyless work — the end-of-sprint collateral, the Jira monitoring, the reports and charts — so you can spend your time on the coaching, the strategic thinking, and the organizational-level impact that’s harder to reach when you’re buried in tactical chores.

His concrete Monday-morning experiment: take the two or three prioritized actions from your next retrospective, bring them to ChatGPT or Claude, and ask, “which of these could you really help me with, and how could you help me move the needle?” Start a conversation. You don’t have to accept its answers — the point is to sharpen your own thinking about where you can add the most value next sprint.

Developing “Taste” With AI

“One element of taste is being able to judge it fairly harshly — getting through the beige as quickly as you can to find the little nuggets and gems.”

Both Dave and Vasco land on the same skill for the year ahead: taste. These tools produce a lot of text, and not all of it is useful. Vasco shares his own aha moment — asking for ideas, getting the obvious ones, then repeating “give me more, don’t repeat any” until the model finally surfaced something genuinely unexpected. That simple move turns AI into an engine for exploring the solution space until something clicks. The competency to build is the ability to move through the beige quickly and recognize the gems that materially change what you do next.

Recommended Resources

In this episode, Dave has the following recommendations for those wanting to learn, and take advantage of AI at work:

- https://scrum-master-toolbox.org/, The podcast that helps you learn faster! 😉
- Co-intelligence by Ethan Mollick
- Lenny’s podcast on YouTube: https://www.youtube.com/@LennysPodcast

About Dave Westgarth

Dave Westgarth is a product and Agile practitioner exploring how AI transforms product development, experimentation, and team workflows. He shares practical insights on leveraging tools to accelerate value delivery and innovation.

You can link with Dave Westgarth on LinkedIn and find him in the Miro community and on Miroverse.

Arun Parameswaran: Product Owners Who Create Better Product Conversations in Scrum

In this episode, we refer to Arun’s AI prompt library for Scrum Masters and project managers.

The Great Product Owner: Curiosity, Clear Direction, and Outcome Focus

“A great PO doesn’t only ask, did we deliver? They ask, do people communicate openly?” – Arun Parameswaran

Arun describes great Product Owners as collaborative, curious, and close enough to the team to understand how delivery really works. The best POs he worked with did more than check whether items were delivered. They asked whether knowledge was distributed, whether people communicated openly, and whether everyone had a chance to contribute.

They gave the team clear product direction, supported prioritization, managed stakeholders, and stayed available when the team needed context. Arun emphasizes outcome focus: value for the customer expressed in a way the team can understand. A strong PO becomes the bridge in both directions, helping stakeholders understand the team and helping the team understand the customer.

Self-reflection Question: Does your Product Owner help the team understand customer value, or only the next ticket?

The Bad Product Owner: Turning the Team Into a Ticket Factory

“The Scrum Master shouldn’t just help the PO write better tickets. We should help create better product conversations.” – Arun Parameswaran

The anti-pattern Arun warns about is the Product Owner as ticket distributor. Stakeholders ask for something, the PO turns it into a ticket, and the team delivers without understanding the problem, the outcome, or why the work matters. Over time, the team becomes a delivery factory, and Scrum starts to look like waterfall with smaller batches.

Arun’s coaching move is to shift the conversation away from “better tickets” and toward better product thinking. What problem are we solving for customers? What outcome do we expect? What should we prioritize? What can we say no to? For Scrum Masters, this means coaching the PO and the team to bring customer context, stakeholder feedback, and prioritization into the same conversation.

Self-reflection Question: What product conversation is your team avoiding by hiding behind ticket writing?

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

About Arun Parameswaran

Arun is an Agile delivery leader at Bosch Global Software Technologies who builds high-performing, data-driven ecosystems. He blends flow metrics, Jira analytics, Power BI, and applied AI to turn delivery into a transparent, predictable system.

You can link with Arun Parameswaran on LinkedIn.

You can also explore Arun’s AI prompt library for Scrum Masters and project managers.

Joshua McDonald: Product Owners Earn Team Loyalty By Showing Up, Learning, And Deciding

The Great Product Owner: Vulnerable Enough To Learn The Technical Details

“I’ve seen developers be fiercely loyal to their product owner who makes that type of effort.” – Joshua McDonald

Joshua describes the great Product Owner as someone who connects with the team even without a technical background. They do not pretend to know everything.

Instead, they get into refinement with curiosity, write stories with the developers, and say, “I think this is what needs to be done, but correct me if I’m wrong.” That vulnerability creates a strong partnership. Developers see the effort and often respond with loyalty, to the point where they may refuse to continue important discussions without the Product Owner in the room.

The lesson is useful for Scrum Masters coaching Product Owners: deep technical expertise is not the entry ticket. Presence, curiosity, and the willingness to learn with the team are what create trust.

Self-reflection Question: How does your Product Owner show the team they are willing to learn the product with them?

The Bad Product Owner: The Dependent Note Taker

“Sometimes you ask the product owner, you’re the bus driver, where do you want us to go? And they say, let me go talk with the product manager.” – Joshua McDonald

The Product Owner anti-pattern Joshua highlights is the dependent PO: the person who shows up as a note taker rather than a decision maker. This often happens when a Product Manager sits behind the PO and every decision has to be checked elsewhere.

The day-to-day symptoms are easy to spot: camera off, muted, disconnected, asking people to repeat questions, missing meetings they scheduled themselves, and leaving the team without timely answers. Joshua’s coaching response starts with one-on-ones, support, and curiosity.

He asks how they are doing, what support they need, and what signals would help the team see they are engaged. When the product feels too technical, he sits beside them, learns with them, and helps them build confidence instead of leaving them exposed.

Self-reflection Question: Where is your Product Owner dependent on someone else for decisions, and how is that affecting the team?

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

About Joshua McDonald

Joshua is endlessly curious about better ways of working. He helps teams grow by blending experimentation, creativity, and AI with practical coaching. When a meeting feels routine, he’s already testing a new approach to make it more valuable. Energetic and inventive, he turns everyday collaboration into opportunities for team growth.

You can link with Joshua McDonald on LinkedIn.

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

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.