Output Owners vs Activators — Two Product Owners Who Defined Aimé's Career | Aimé Flemm

Summary

Scrum Master Toolbox Podcast

Episode: Output Owners vs Activators — Two Product Owners Who Defined Aimé's Career

Guest: Aimé Flemm

Host: Vasco Duarte

Date: June 19, 2026

---

Episode Overview

This episode explores the profound impact that Product Owners (POs) have on team dynamics and product outcomes. Vasco Duarte welcomes Aimé Flemm to discuss pivotal experiences with both poor and exceptional POs, illustrating how these roles can either inhibit or mobilize teams. The conversation revolves around two archetypes: the "Output Owner" (task-focused, managerial) versus the "Activator" (visionary, inspiring leader). Aimé shares real-world stories and practical insights for Scrum Masters, Agile Coaches, and teams working with Product Owners.

---

Key Discussion Points & Insights

1. The "Team Manager in Disguise" Product Owner (Output Owner)

Aimé describes a significant anti-pattern: the Product Owner who acts as a team manager rather than a team peer.

• Management Overlap:

  • The PO had authority to hire, fire, approve promotions, and set pay raises ([01:49]).
  • Created fear and tension, making open communication and healthy challenge impossible.
  • “I was a bit scared to really work with him ... my job was dependent on his view of what I did.” – Aimé ([02:13])

• Absenteeism:

  • The PO was rarely present, only showing up for 15 minutes/week to deliver instructions ([02:54]).

• Team Dynamics Deteriorate:

  • Team motivation and collaboration declined.
  • People became highly individualistic, focusing only on their assigned tasks to “look good” rather than building value together ([04:23]).
  • “It became a collection of individuals all on their own island, just fixing their own work, just to make sure that they looked good.” – Aimé ([04:39])

• Impact on Product & Process:

  • Avoidance of new work and improvement initiatives.
  • Poor backlog refinement and limited feedback lead to stagnation.
  • Vasco notes: “If the team doesn't want to have long and intense discussions with the product owner, then the quality of the backlog items will suffer. And that may not be visible immediately, but over time it will destroy the product. It's just a question of time.” ([05:25])

• Proxy Product Owners & "Output Owners":

  • The PO was also a "proxy" – just shoving tasks from point A to B without true ownership or customer focus ([06:09]).
  • Aimé: “Most product owners are just kept by design and they are just shoving work around–they’re team-level Output Owners. That also doesn’t help.” ([06:28])
  • Vasco: "'Output owners,' not product owners." ([06:43])

---

2. The Activator/Visionary Product Owner

Aimé contrasts the poor PO with an exceptional one encountered after an organizational shift to LeSS (Large-Scale Scrum).

• Scaling & True Ownership:

  • The company moved from 7 teams and 7 POs to 1 PO for all ([07:07]).
  • The new PO rose to the challenge, demonstrating leadership, vision, and charisma.

• Key Skills of an Activator PO:

  • Able to persuade and inspire groups as large as 60 people.
  • Created a compelling product vision and mobilized teams to rally behind it.
  • “He was really able to persuade the larger group of 60 people and activate them. I think that was such an important skill ... motivating people to rally behind you and start working on it.” – Aimé ([07:32])

• Leadership over Micro-Management:

  • The PO delegated decisions and focused on direction, not micromanagement.
  • Vasco: "They don’t do the work themselves...they can only define the direction ... there's a million different decisions that need to be delegated to the people actually doing the work." ([08:25])

• Enabling Structure:

  • For such leadership to flourish, organizations must set up the right structures and tools.
  • “You need to have the right structure in place for the organization to enable the product owner to be able to do these things, to have the right tools and people at his or her disposal to be able to create this vision for real.” – Aimé ([09:03])

---

Notable Quotes & Memorable Moments

• Fear-Based Dynamic:
  • “I was a bit scared to really work with him ... my job was dependent on his view.” – Aimé ([02:13])
• Individualism Hurting Teams:
  • “It became a collection of individuals all on their own island, just fixing their own work just to make sure that they looked good.” – Aimé ([04:39])
• Long-term Product Impact:
  • “If the team doesn't want to have long and intense discussions with the product owner, then the quality of the backlog items will suffer … over time it will destroy the product.” – Vasco ([05:25])
• Feature Pusher/Proxy PO:
  • “Most product owners are just kept by design and they ... are just shoving work around—output owners. That also doesn’t help.” – Aimé ([06:28])
• True Leadership:
  • “He was really able to persuade the larger group of 60 people and activate them … motivating people to rally behind you and start working on it.” – Aimé ([07:32])
• Role of Organizational Structure:
  • “It always starts with having structure.” – Aimé ([09:03])

---

Important Segment Timestamps

• Intro & Episode Purpose: [01:11–01:49]
• "Team Manager in Disguise" Anti-pattern: [01:49–03:45]
• Consequences for Teams: [03:45–05:25]
• Output Owners & Proxy POs: [06:09–06:47]
• Great Product Owner Qualities (Activator/Leader): [07:07–08:25]
• Organizational Support & Structure: [09:03–09:29]

---

Conclusion

This episode powerfully contrasts two types of Product Owners: those who stifle teams with fear and control (“Output Owners”) and those who inspire action through vision and leadership (“Activators”). Aimé’s stories underline the vital role POs play in shaping team culture and delivering value, and the responsibility organizations have to enable those POs to succeed.

---

Find Aimé Flemm on LinkedIn:
“I post there some wild ideas and you can find more there.” – Aimé ([09:40])

---

For Scrum Masters, Agile Coaches, and tech leaders, this episode offers a clear-eyed look at the difference a great Product Owner can make—and the deep dysfunction that can result when the role is misunderstood or miscast.

Transcript

[A]

Hey there, Agile adventurer, just a quick question. What if, for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame warfree and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's the Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.

[B]

Hello everybody. Welcome to our TGIF product owner episode this week with Eme Flam. Hey, Eme, welcome back.

[C]

Hey.

[B]

So we're going to dive into the product owner role. Of course, it's such a critical role in Scrum and I guess these days in a lot of software companies out there, some of them might not even be using Scrum, but they still have the product owner role. So let's dive into that. We'll talk about great product owners in a minute. But before that, Emmy share with us. Potentially the worst product owner anti pattern you witnessed in your career.

[C]

Yeah. So I instantly had to think of the, the second product owner I've worked with and it's not an official anti pattern. So I made it my own. It's the team manager in disguise, product owner. Because what this product owner really did was just managing the team. He had the power to hire and fire, to decide on promotions, pay raises. And it created such a weird dynamic because, yeah, the same was for me. So I was a bit scared to really work with him and, and be like this, this, this mirror that you should be for the proton. I couldn't be at all because, yeah, also my job was dependent on his view of what I did. And the same went for all team members. So it created this weird dynamic that got us stuck. And that was even more complicated because the product owner was really not present in the team. He came by maybe 15 minutes of the whole work week just telling him, oh yeah, this is good. You sure you should do this and do this? And then he was gone the rest of the week and People were complaining to me, to each other, about the presence and the way things were handled. And I remember just feeling stuck in between, in a hard place, not being able to do anything because I also was a bit fearful of him because, yeah, you know what if I say something wrong? And you will just say, like, so what are you going to do? You know, it was really, really tough

[B]

when you think about the teams in general. So not necessarily of your position at that point, but of course it affected you, as you said. But if you think about the team in general, what are the most visible consequences when that dynamic happens? And sometimes it's just a direct report line that we are reporting to the product owner as a line manager. Other times it might be an indirect report line where actually we are not reporting to the product owner, but our manager is so weak that the product owner ends up making all of the decisions anyway. How does that impact the teams in practice? What have you seen?

[C]

They became really avoidant of pulling in new work, you know, really focused on, okay, how can we get just the stuff that is being asked from us to get it done? And anything outside of that scope was no go. So they avoided initiatives to have workshops to work on other things, but also just this atmosphere of not really wanting to help each other because everyone had their own thing that they were working on. So they were this really actually a collection of. It became a collection of individuals all on their own island, just fixing their own work just to make sure that they looked good. But on a team level, you know, nothing was really happening or being built or actually any customer value. And I think that was. Yeah, it's unfortunate.

[B]

Absolutely. And as you described, this can have a lot more ramifications. Right, because certain behaviors then, like for example, if the team doesn't want to have long and intense discussions with the product owner, then the quality of the backlog items will suffer. And that may not be visible immediately, but over time it will destroy the product. It's just a question of time. We all need sparring partners, and that's why it's so important, and Scrum defines it, that the product owner is a separate entity from the role of the developer tester. The product owner is inside the team, so they are part of the team, but as a peer, not as a manager of the team.

[C]

And then to make it even worse, you know, this, this, this, the product owner was a proxy she would call them. And that didn't help as well because they were just shoving the work from point A to point B. And you know, this was another problem if you have to manage as a scrub master to fix. Because I think most product owners are just kept by design and they. They are just shoving work around their team level. Output owners. That also doesn't help.

[B]

Yeah, output owners, not product owners.

[C]

Yeah, absolutely.

[B]

All right. But not all product owners are like this. Some are incredibly good at the job that they do. These are the great product owners we want to celebrate here on the podcast as well. So share with us potentially the best product owner you've ever worked with. How did they work?

[C]

Yeah. So because we flipped from less in this company, we flipped to less in this company. We moved from seven teams to one, which also from seven product owners to one product owner. It also meant that you just all of a sudden had this one product owner who need to step up his game to become of this leader who's visionary, who has some kind of charisma. And I remember that our product owner was really able to persuade the larger group of 60 people and activate them. And I think that was such an important skill to really work with larger groups and have this vision, being truly visionary with your product and motivating to people to rally behind you and start working on it. And I think that was really cool to see because it doesn't happen too often that you get this opportunity to really have the product owner in the company and just do on. Yeah. And I think then it's really important, you know that these people, that this person can lead these larger groups.

[B]

Yeah. The ability to lead, to inspire, to clarify, those are all incredible important skills for product owners also, because it is the nature of their work, as it is ours as Scrum masters, that they don't do the work themselves. The work is done by other people. They can only define the direction. They, of course they can write user stories, which they shouldn't be. But even if they do, that's still not the implementation. There's a million different decisions that need to be delegated to the people actually doing the work. Design, architecture, testing, all of that.

[C]

Yeah. And then it ties back to, you need to have the right structure in place for the organization to enable the product owner to be able to do these things, to have the right tools and people at his or disposal to be able to create this vision for real. And I think that's. Yeah, again, it always starts with having structure.

[B]

Well, it's been a great week here on the podcast, Amy, thank you very much for sharing all of those stories. Before we go, where can people find out more about you and the work that you're doing.

[C]

Yeah, LinkedIn is always the place to go. So I think Ma Flam there's only one in existence, I'm quite sure. So if you type in my name on LinkedIn, you'll find me. I post there some wild ideas and you can find more there?

[B]

Absolutely. I will put the link to Emma's LinkedIn page to make sure that people can find Emma easily. And why not follow up, ask a few questions, share, learn together. Because that's how we need to learn as a community of product software developers. And these days Scrum is being used elsewhere as well. So just practitioners Eme, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.

[C]

Thank you so much. Vasco. It was awesome.

[A]

All right, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you. The members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing Agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep dive interviews, books, and if you're into no estimates, we got the pioneers of no estimates in those Deep Dive interviews as well. Agile, Business Intelligence, Creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course, without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the [e-mail] membership because listening is great. It's important. But doing it together, that's next level. I'll see you in the community. Slack.

[B]

We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes. Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.