How Decision Journals Can Transform Product Owner Behavior | Florian Georgescu

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches
Episode: How Decision Journals Can Transform Product Owner Behavior | Florian Georgescu
Host: Vasco Duarte
Guest: Florian Georgescu
Release Date: August 8, 2025

---

Introduction

In this insightful episode of the Scrum Master Toolbox Podcast, host Vasco Duarte delves into the nuanced role of the Product Owner (PO) with guest Florian Georgescu. Florian shares his experiences and strategies for enhancing PO effectiveness, particularly focusing on mitigating common anti-patterns and fostering a collaborative team environment through the implementation of decision journals.

Identifying Product Owner Anti-Patterns

Florian discusses a prevalent anti-pattern: the command and control approach often exhibited by Product Owners transitioning from project management roles, especially in large organizations.

[01:47] Florian Georgescu: "The most often that I have witnessed was this command and control pattern of the product owner... he took technical decisions for the team without involving the team."

Key Points:

• Background: Florian recounts a scenario where a PO with extensive project management experience but limited PO training imposed technical decisions unilaterally.
• Impact on Team: This approach led to frustration among team members who felt their expertise and opinions were undervalued, resulting in delayed deliveries and increased technical debt.

Implementing the Decision Journal Experiment

To address the command and control anti-pattern, Florian introduced a Decision Journal experiment aimed at fostering transparency and collaborative decision-making.

[04:56] Florian Georgescu: "We wanted to document every decision that was taken regarding that product... what was the decision, at which date, who made the decision, whether we considered alternative solutions, and the expected outcome."

Experiment Structure:

1. Documentation: Every decision is recorded with details such as date, decision-maker, alternatives considered, and expected outcomes.
2. Classification: Decisions are categorized (e.g., business, technical) to provide clarity.
3. Review: During retrospective meetings, the team analyzes these decisions to assess their impact and effectiveness.

Outcomes:

• Enhanced Accountability: By documenting decisions, the PO became more aware of the consequences of unilateral decisions.
• Empowered Team: Team members felt more confident to voice their opinions, knowing decisions would be transparently reviewed.
• Improved Decision Quality: The team identified instances where decisions led to negative outcomes, prompting more thoughtful and collaborative approaches in future sprints.

[07:13] Host (Vasco Duarte: "The mirror isn't just to help the product owner. It was also to help the team to have courage to voice their opinions."

The Dual Benefits of Decision Journals

The Decision Journal served as a "mirror" not only for the Product Owner but also for the entire team, fostering a culture of openness and continuous improvement.

Host's Insight:

• Team Empowerment: When POs make numerous decisions independently, it often leads to team members stepping back. The Decision Journal mitigates this by encouraging active participation.
• Balanced Responsibility: Facilitates shared ownership of decisions, ensuring that the PO and team collaborate effectively.

Celebrating Exemplary Product Ownership

Moving beyond anti-patterns, Florian highlights the traits of an exceptional Product Owner he has worked with, emphasizing the importance of communication, humility, and continuous learning.

Traits of an Outstanding PO:

1. Transparent Communication:
   • Utilized an open product canvas to display all product-related information, fostering transparency.
   • Maintained Feature Learning Cards to reflect on the impact and outcomes of each feature.

[09:00] Florian Georgescu: "He was familiar with the team and with the business... his communication style was super transparent and engaging."

2. Relationship Building:

   • Organized informal sessions like "Story Time Tuesdays" to discuss upcoming user stories and explore different problem-solving approaches.
   • Built strong relationships with both stakeholders and engineers, encouraging open dialogue and feedback.

3. Continuous Learning:

   • Demonstrated humility by acknowledging areas for improvement and actively seeking input from the team.
   • Employed reflection tools to assess the success of features and initiatives, promoting a culture of learning and adaptation.

[13:50] Florian Georgescu: "We created this feature learning card where we discussed... what was the outcome or the hypothesis, and then the outcome."

Impact of These Practices:

• Enhanced Team Collaboration: Engineers felt comfortable voicing concerns and proposing alternatives.
• Data-Driven Decisions: Feature Learning Cards provided tangible metrics to evaluate the effectiveness of implemented features.
• Sustained Improvement: Regular reflection facilitated continuous enhancement of both product and team practices.

Conclusion

Florian Georgescu's experiences underscore the transformative potential of structured decision-making and transparent communication in the Product Owner role. By implementing tools like Decision Journals and fostering an environment of continuous learning and collaboration, POs can significantly enhance team dynamics and product outcomes.

Connect with Florian Georgescu:

• LinkedIn: Florian Georgescu

Host's Final Thoughts:

[14:39] Host (Vasco Duarte): "Why not ask a few follow-up questions, talk about a specific tool or idea that you like from this week and get a conversation going. We learn as a community as well."

Florian's insights provide valuable lessons for Scrum Masters and Agile Coaches aiming to refine their practices and cultivate more effective and harmonious teams.

---

Join the Scrum Master Toolbox Community:
For more in-depth agile content, live workshops, and a supportive practitioner community, visit scrummastertoolbox.org/membership.

Transcript

[Vasko]

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 war free 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 this 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.

[Host]

Hello everybody. Welcome to one more episode about the product owner, this time with Florian Giorgesku. Hey Florian, welcome back.

[Florian Giorgesku]

Hi everyone.

[Host]

So Friday is product owner, of course, and on Fridays we talk about how great product owners do what they do. But before we dive into that, we also want to know how anti patterns emerge in the product owner role. So share with us Florian, what might have been potentially the worst product owner antipattern you've witnessed in your career?

[Florian Giorgesku]

Maybe not the worst. The most often that I have witnessed was this command and control and the pattern of the product owner. And I've experienced this mainly in big organizations. And the story that I'm going to tell is from one of these big organizations, it was a product owner that transitioned from a formerly project manager role and it had this command and control anti pattern style. This was shown when he took decisions, technical decisions for the team. So in short, a little bit of context. The team was quite small, very good from a technical perspective. We had this project, former project manager has been in this role for 20, 30 years and then overnight, or maybe not overnight, but then he transitioned to the product owner role. He had very good business knowledge, so product knowledge, but also very good technical knowledge. What he did was actually he took decisions, he took technical decisions for the team without involving most of the time the team and the team on one side. What's also important, the team was spread. So he was in one location, the team was here in Romania. The team appreciated him and his technical skills. But you could see when you have this is what I've seen when I had the conversations with Them I saw this frustration, the fact that they were not allowed to voice their opinion. And sometimes the technical decisions that were taken by the product owner proved to actually delay the delivery and induce even more technical debt. And obviously I was thinking, okay, what is the best way that I can mirror this behavior and how to address this with the po? I had first a conversation with him, explained him a little bit about what is the purpose of the PO and the role and so on and so forth. It was mainly a theoretical conversation, and I didn't expect too much to change out of this conversation. But what I proposed to him was to make an experiment about decisions. We called it the Decision Journal experiment. And we did this experiment, I think, for three or four sprints.

[Host]

What was the experiment like? So you called it Decision Journal, but what were you asking the PO to do?

[Florian Giorgesku]

We wanted to document every decision that was taken regarding that product. So it was the structure of the journal. So we documented it in conference, but it was a decision record. So what was the decision, at which date, who made the decision, whether we considered alternative solutions for that decision, and also what was the expected outcome for the decision? Decision. And then we also classified the decision, whether it was a business one, technical one, and so on and so forth. And what we did. So basically, we documented every decision for three hours or sprint, and in every retrospective meeting, we analyzed the decisions and their impact and what was important. And I think it had also big impact on the PO was the fact that those technical decisions that he took without considering the options of the team, their outcome was actually worse than if we would have chosen a different path. And we understood that sometimes we need to introduce technical depth to get something done faster. But on the other side, there were also decisions, and it was black on white. There were also decisions that were taken without considering alternative solutions, which in the end took longer to implement. And also the outcome was not the expected one. And I think this was having this mirror. I think this was super important for that product owner and also very important for the team, because this gave them courage to speak up and voice their opinion.

[Host]

That's actually a very good point. The mirror isn't just to help the product owner. It was also to help the team to have courage to voice their opinions. Even if in the end the decision would be different, but at least they would bring it up. Because when we voice our opinions, we have the chance of coming up with a different solution that is better than what's being discussed at that point. So I think that was a great insight that it's not a mirror only to the po, it's a mirror to the team. And one thing that I want to emphasize here is that when you have a P.O. or anyone that is making a lot of decisions, that means that the other team members are stepping back. And this is the important realization is that the PO would not take those decisions if the team had taken the initiative to bring up other potential considerations in the decision making. But when teams step back, the POs lean in, especially if they have a project management background. So it's for both. It's a mirror for both. That's a great insight. But of course there aren't only bad product owners, there are also some amazing product owners out there, Florian. So let's celebrate one of those. Share with us potentially the best product owner that you've ever worked with. How did they work?

[Florian Giorgesku]

So it was really a privilege to work with that person. What's interesting and nice at the same time was that when we started to work together, the product owner started from scratch, this role. So he had.

[Host]

You mean by, by starting from scratch you mean that this product owner was not familiar with the technology or the team.

[Florian Giorgesku]

He was familiar with the team and with the business. So he had very good. He came from the, from, from the business, but he didn't know about, about, about the, the responsibilities and the role of product owners. And for him it was also a learning period. But I think what was exceptional at this product owner was this combination of skills and approaches. First, it was this communication style which was super transparent and engaging and, and second was his desire to continuously learn. And he was also super humble to accept that there are things that he doesn't know and there are things that he knows, but still he wants to hear also other opinions about it. So it was not difficult for him to take a decision, but he's open to take also other opinions. And I remember the tools that he used to communicate effectively. And one of them is we were, back then in the office, we had an open product canvas. So next to him he used a wall where he documented basically everything related to his product. Obviously it started small with a roadmap and such, but then slowly it evolved really in a, in a, in a very nice information radiator about, about the product. And it was, it was very helpful also for the engineers because every time they went to discuss with, with him, they saw it, they saw it there and they, they had discussions around it. Then what I appreciated, another thing that I appreciated is the relationship building not only with his stakeholders, but also with the engineers. Engineers came very easily to talk to him. He organized. I remember we had this story time Tuesdays, which were some informal formal refinement sessions. Although we had refinement sessions, these were more informal ones, optional ones, where he and the developers discussed about upcoming user stories they were exploring, also different approaches on how to solve different problems. He also shared with them information about the users and the needs. And I think this informality aspect made it very attractive to the developers and helped also have these relationships with developers, which were very helpful because the developers felt very easy to give him input. They were also not shying away when something couldn't be done, or when something took longer to be done, or when they were proposing alternative solutions. But also he was very respectful and he was also very open to listen to their opinions. And another tool that we used back then, which was also very helpful, was sort of a reflection tool for every feature, sort of a feature learning card, we realized. So we had our roadmaps split in quarters and obviously if we delivered a feature at the end of the quarter, we just moved to the other one and we realized that we are not learning at all about what we did when it comes to numbers, when it comes to impact. So what we did is at the end of the development of every feature, we created this feature learning card where we discussed about the name of the feature, what was the outcome or the hypothesis, and then the outcome. And we also had some numbers attached to it. So we had the point of departure and point of arrival. This also helped a lot reflect on what we were doing and also helped a lot. The engineers reflect also on their practices, also on more technical or enablement features that they have implemented. It was really nice to have this feature learning cards.

[Host]

Yeah, that's a great, great tool. Feature learning cards, where you learn about the impact of the features that you've delivered together with the team. That's a great tool. Thank you for sharing that, Florian. Now we're getting close to the end, but before we go, if people want to get in touch with you and know more about the work that you're doing, where should they go?

[Florian Giorgesku]

They can find me on LinkedIn. I'm quite active on LinkedIn, so they can find me there.

[Host]

Absolutely. So everybody check out Florian's LinkedIn page. It's on the show. Notes. And why not ask a few follow up questions, talk about a specific tool or idea that you like from this week and get a conversation going. We learn as a community as well. Florian, it's been a pleasure. Thank you very much for being here and sharing all of that wisdom and knowledge with us.

[Florian Giorgesku]

Thank you Vasco. Thank you for having me. It was really nice to be here.

[Vasko]

Alright, 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, 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 we really hope you liked our show.

[Host]

And if you did, why not rate.

[Vasko]

This podcast on Stitcher or itunes?

[Host]

Share this podcast and let other Scrum masters know about this valuable resource for their work.

[Vasko]

Remember that sharing is caring.