POPULARITY
25 episodes with product ownership
22 episodes with product ownership
5 episodes with product ownership
4 episodes with product ownership
6 episodes with product ownership
3 episodes with product ownership
3 episodes with product ownership
3 episodes with product ownership
2 episodes with product ownership
Superpowers School Podcast - Productivity Future Of Work, Motivation, Entrepreneurs, Agile, Creative
Henrik Kniberg shares insights from his recent video and book 'Generative AI in a Nutshell,' which went viral. The discussion explores how AI can reduce the need for large teams, allowing for more efficient, smaller teams. Henrik explains his current project on building an AI agent platform and its implications for the future of work. We also delve into the evolving role of product discovery and how AI is transforming traditional agile practices. The conversation wraps up with thoughts on how to stay ahead in the rapidly evolving tech landscape and what elements of traditional work practices, like time sheets, might be rendered obsolete by new AI capabilities.00:00 Introduction 01:20 Guest Introduction: Henrik Kniberg02:46 Henrik's Current Projects and AI Insights03:57 The Evolution of Agile Teams05:57 Impact of AI on Work and Society07:21 Writing and Promoting the Book11:16 Future of Work with AI23:01 Designing for AI Stakeholders26:35 Building and Managing AI Agents27:40 Real-World Applications of AI Agents31:58 The Future of Product Development33:50 Effective Product Discovery38:28 Integrating AI in Product Development40:20 Learning and Staying Ahead in AI43:54 The Importance of Eliminating Time Sheets46:45 Conclusion and Final Thoughts⚡️ In each episode, Paddy Dhanda deep dives into a new human Superpower to help you thrive in the age of AI.Host: Paddy DhandaPaddy works at the largest Tech training organisation in the UK and is passionate about helping tech professionals build human skills to thrive in the age of AI.Contact Paddy: paddy@superpowers.schoolSubscribe to my newsletter:
Deniz Ari: Why Great Product Owners Listen—Communication Lessons from Product Ownership Extremes The Great Product Owner: The Power of Clear Communication Deniz describes a truly exemplary Product Owner who excelled through outstanding communication skills. This PO was an exceptional listener who maintained openness throughout all interactions. They ensured the team thoroughly understood requirements and priorities, always clearly articulating the rationale behind decisions. With a well-defined product vision and transparent prioritization process, this PO successfully bridged the gap between the development team and clients. Deniz emphasizes how this clear communication style naturally fostered team motivation, as everyone understood not just what they were building, but why it mattered. The Bad Product Owner: The Tyrant PO Deniz shares a challenging experience with a problematic Product Owner during what initially appeared to be a straightforward public sector migration project with adequate budget and timeline. Despite these favorable conditions, the situation deteriorated when the PO began pushing the team to work overtime, overstepping boundaries by questioning architectural decisions, and inappropriately assuming Scrum Master responsibilities. Described as a "tyrant" or "despot," this PO exhibited extremely poor communication skills and preferred dictating rather than collaborating. When Deniz attempted to address these issues, the situation became so toxic that it affected Deniz's health, ultimately leading to their decision to leave the project. The PO subsequently claimed no Scrum Master was needed. Deniz reflects that sometimes the best option is to recognize when a situation cannot be changed and to move on. Self-reflection Question: What boundaries would you establish with a dominant Product Owner, and at what point would you decide that the situation cannot be improved? [The Scrum Master Toolbox Podcast Recommends]
Deniz Ari: Security Team Breakdown—The Devastating Impact of Poor Product Ownership Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Deniz shares the story of a security project with a team of eight experienced, senior engineers working on mission-critical systems. Despite initial motivation and clear architectural solutions, the team soon exhibited signs of negative behavior including complaints and criticism. The root cause traced back to frequent Product Owner changes—several within less than a year—and poor client management. Instead of shielding the team, the PO directly transferred stress from clients to the team, demanded overtime, and created unnecessary tension by bringing unfiltered conflicts to the team and requesting excessive details. Deniz emphasizes the importance of avoiding unnecessary tensions, being more political when necessary to protect the team, and being mindful of tone in written communications. Self-reflection Question: In what ways might you be failing to set proper boundaries in your role, and how could establishing clearer limits improve both your effectiveness and your team's performance? Featured Book of the Week: Boundaries by Henrik Cloud Deniz recommends "Boundaries" by Henrik Cloud, a book about human relationships and personal limitations. The book addresses crucial questions: Does your life feel out of control? Do you keep saying yes to everyone? Are you taking responsibility for others' feelings and problems? Have you forgotten your own limitations? Deniz explains how this book helped them learn to say "no" while still considering others' realities and feelings, and understanding why we often struggle with setting boundaries. Deniz highlights that being a Scrum Master involves much more than just processes and methods—it requires healthy personal boundaries. [Scrum Master Toolbox Podcast Recommends]
Chris Sims: The Empathy Advantage, How Great POs Connect Teams with Users Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Deep Market Knowledge Creates Team Empathy Brad exemplifies a truly effective Product Owner through his exceptional understanding of end users and customers in the investment management space. What sets Brad apart is not just his deep domain knowledge, but his established relationships with gatekeepers at customer organizations. These connections provide valuable insights that inform product decisions. Most importantly, Brad regularly spends time with the development team, helping them empathize with stakeholders and understand the real-world impact of their work. His user stories consistently focus on actual users and why the requested features matter, creating clear context for developers and fostering meaningful connections between technical work and business outcomes. The Bad Product Owner: The Disempowered Proxy Problem Chris identifies a common anti-pattern: the disempowered proxy Product Owner. This situation occurs when someone performs the day-to-day PO responsibilities for the team, but lacks true authority to make decisions. Instead, an unseen "real PO" holds ultimate control and can swoop in at any time to change priorities or requirements. This arrangement quickly erodes team trust as they realize the proxy must continually defer decisions, creating delays and uncertainty. Chris suggests either empowering the proxy with more decision-making authority while keeping stakeholders appropriately involved, or having the higher-level PO commit to spending sufficient time with the team to fulfill the true Product Owner role themselves. Self-reflection Question: How might you identify and address power imbalances in the Product Owner role within your organization? [Scrum Master Toolbox Podcast Recommends]
Richard Brenner: Hypothesis-Driven Product Ownership, The Experimental Mindset Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Experimenter Richard describes great Product Owners as "experimenters" who understand that everything they do is a hypothesis requiring validation. The best POs establish feedback loops early, actively engage with users and clients, and approach product development with a scientific mindset. Richard shares an experience working with a "coaching PO" who excelled at involving everyone in defining what needed to be done. This PO was inspiring and helped the team participate in both building and decision-making processes. Richard emphasizes that the relationship between PO and team must be a true partnership—not hierarchical—for success to occur. Great POs facilitate team involvement rather than dictating direction, creating an environment where collaborative problem-solving thrives. In this segment, we refer to the Role Expectation Matrix Retrospective, and the Product Owner Sprint Checklist, a hands-on coaching tool for anyone interested in helping PO's prepare and lead successful Sprints with their teams. The Bad Product Owner: The Tech Visionary Disconnected from Users Richard recounts working with a high-level sponsor, a medical doctor interested in technology, who hired multiple development teams (up to four Scrum teams) to build a product. While technically knowledgeable, this PO had very concrete ideas about both the technology and solution based on assumptions about client needs. The team developed impressive technology, including a domain-specific language (DSL), and felt they were performing well—until they delivered to actual clients. Only then did they discover users couldn't effectively use the software, requiring a complete rethinking of the UX concept. This experience taught Richard the critical distinction between the customer (the sponsor/PO) and the actual end users, demonstrating how even technically sophisticated Product Owners can miss essential user needs without proper validation. Self-reflection Question: How might you help Product Owners in your organization balance their vision with the practical realities of user needs and feedback? [Scrum Master Toolbox Podcast Recommends]
Endlich wieder vereint am Mikro: Kai und Andreas sprechen im AI or DIE Podcast über Datenprodukte, AI-Produkte und warum die klassische Projektlogik ausgedient hat. Statt Hektik in Q4 lieber echte Verantwortung, Nutzbarkeit und Impact. Es geht um Product Ownership, Lifecycle, Use-Case-Fokus und die Frage: Wie denken wir Datenprodukte wie echte Produkte – mit Roadmap, Skalierung und Feedbackschleife? Und wie übertragen wir dieses Mindset auf KI-Anwendungen? Von PowerPoint als Datenprodukt bis zum AI-Agenten, der Prozesse übernimmt – alles dabei. Wer Data und AI wirklich auf die Straße bringen will, muss umdenken. Diese Folge liefert die Ansage. Klar, direkt, praxisnah.
BONUS: The End of Product Management? Three Experts Reveal the Unstoppable Rise of Product Engineers With Anton Zaides, Rafa Paez, and Max Piechota In this BONUS episode, we explore the emerging concept of the Product Engineer with three experts in the field: Anton Zaides, Rafa Paez, and Max Piechota. Together, they discuss how software engineers are evolving beyond just technical skills to embrace product thinking, business understanding, and customer empathy. This shift represents a move toward what they call "M-skilled" professionals who combine technical expertise with product sensibility to create greater impact. The Evolution of Software Engineering "The role of the software engineer is evolving to a product engineer...they understand what to build and why they are building it." Rafa Paez kicks off the conversation by sharing insights from his article on Substack, titled "The Rise of the 100x Product Engineer." He explains how the modern software engineer is taking on greater ownership of their work, focusing not just on writing code but understanding the underlying business reasons for features. This new breed of engineers thinks critically about product metrics, challenges assumptions, and takes extreme ownership of outcomes rather than just outputs. Breaking Product Management "Engineers don't really care about what they work on...but what if they did?" Anton Zaides discusses his provocative Substack article "Product Management is broken, a change is coming," where he challenges the traditional separation between engineers and product decisions. He describes the phenomenon of the "ZOOM-based product manager" who remains disconnected from both users and engineers, and contrasts this with engineers who genuinely care about the products they build. Anton argues that when engineers are invested in the product outcomes, the entire development process improves. For a podcast episode with Anton Zaides about the Product Management is broken article, listen to this Scrum Master Toolbox Podcast episode. Measuring What Matters "We need to measure the product outcome, the customer value and incentivize developers based on that." Max Piechota shares how his journey toward product engineering began through conversations with his CEO about measuring software engineer performance. His research led him to realize that traditional engineering metrics often miss what truly matters - the value delivered to customers. Max advocates for aligning developer incentives with product outcomes rather than just code output, representing a fundamental shift in how we evaluate technical contributions. Catalyzing the Transformation "What helped me change was working with those people that wanted to create products." The conversation turns to practical ways to foster this evolution toward product engineering: Max describes how exposure to product-oriented colleagues and learning about the Lean Startup methodology transformed his perspective as a developer. Anton outlines a three-step approach: helping engineers see metrics and user interactions, building business literacy, and connecting more deeply with the domain. The group discusses the importance of helping engineers understand concepts like gross margin and the AARRR framework (Acquisition, Activation, Retention, Revenue, Referral). Beyond Solutions to Problems "Often we only focus on the solution, without understanding the actual problem we are trying to solve." One crucial insight from the conversation is the need for engineers to take a step back from solution mode and better understand the underlying problems. The panel shares practical tips: Clarify how the business works and identify opportunities for improvement Be thoughtful about how developers are incentivized Connect technical decisions to financial outcomes Focus on landing page conversion and other customer-facing metrics when they're the bottleneck to growth This mindset shift enables engineers to make more strategic decisions about where to invest their technical efforts for maximum impact. About Anton Zaides, Rafa Páez, Max Piechota Anton Zaides is the founder of Manager.dev, where he shares insights about engineering management and product development. With extensive experience in both engineering and product leadership roles, Anton is passionate about bridging the gap between technical execution and product vision. You can link with Anton Zaides on Substack. For inquiries, reach him at Anton@manager.dev. Rafa Paez is a product engineering advocate who wrote the influential article "The Rise of the 100x Product Engineer." Through his work, Rafa explores how engineers can expand their impact by embracing product thinking and business understanding alongside technical skills. You can link with Rafa Paez on Substack. Find more of his work at rafapaez.com. Max Piechota is a thought leader in the engineering productivity space who has researched effective ways to measure and improve developer performance. He advocates for outcome-based metrics that focus on customer value rather than code output. You can link with Max Piechota on Substack.
BONUS: Keeping Backlogs Lean With The Now-Next-Later-Never Roadmap Framework with Kent McDonald In this BONUS episode, we explore the art of backlog management with product management expert Kent McDonald. As someone with decades of experience in software product development, Kent shares practical strategies for keeping backlogs lean, meaningful, and focused on outcomes that truly matter. Learn how to escape the trap of bloated backlogs and implement a Now-Next-Later-Never approach that will transform your product management practice. The Problem with Bloated Backlogs "Some teams use backlogs as 'long term storage' devices." Product backlogs often become unwieldy and difficult to manage because teams view them as a permanent repository for every idea that comes along. Kent explains that this "storage mentality" is one of the primary reasons backlogs grow out of control. Another common mistake is diving in too early and splitting items before they're actually ready to be worked on, which multiplies the backlog size unnecessarily. These practices lead to confusion, lost focus, and ultimately decrease a team's ability to deliver value efficiently. The Now-Next-Later-Never Roadmap Framework "You want to group things together on roughly categories of when you will attack it." Kent walks us through the practical implementation of a Now-Next-Later-Never roadmap approach that keeps things manageable. This framework provides a simple but powerful way to organize initiatives based on their priority and timing. Instead of maintaining an endless list of requirements, teams can group work into these four buckets, making it easier to communicate priorities both internally and with stakeholders. Kent emphasizes that these roadmap items should be described in terms of outcomes rather than features, helping everyone stay focused on the value being delivered rather than specific implementations. For more on the origin of the Now-Next-Later roadmap practice, see this article by Janna Bastow. Making "Now" Work in Practice "We only split items in the 'now' column." When implementing the Now-Next-Later-Never approach, the "Now" column is where the magic happens. Kent advises: Only split items that are in the "Now" column into actionable tasks Express roadmap items in terms of outcomes or customer problems to solve Limit the number of items in the "Now" column to maintain focus List outcomes rather than detailed features to avoid having a large number of items Kent explains that the "Later" and "Never" columns serve an important purpose in setting expectations with stakeholders about what won't be worked on immediately or at all. Managing the Movement Between Roadmap Categories "Items can move back and forth, to facilitate expectation setting." The Now-Next-Later-Never roadmap isn't static. Kent provides practical advice on how to manage the flow of items between categories: Revisit the roadmap regularly, ideally monthly Consider reviewing the roadmap during sprint review sessions Use this format when communicating with stakeholders for clearer expectation setting Hold strong on the "Now" items to maintain focus and avoid constant reprioritization This approach creates a dynamic but controlled environment where priorities can evolve without creating chaos or confusion. Dealing with Backlog Bloat "Create a 'museum', a set of items you can look at, but don't look at every day." For teams struggling with already-bloated backlogs, Kent offers bold but effective advice: Create a "museum" for items you want to preserve but don't need to see daily Consider deleting your old backlog and starting fresh Begin by asking: "What are the main outcomes we're trying to achieve?" Focus on getting to a smaller set of bigger items, then sequence them appropriately These approaches help teams overcome the fear of "losing" work while refocusing on what truly matters. Maintaining a Lean Backlog "Backlog items don't age well." Kent's team maintains an impressively lean backlog of just 23 items across three brand websites. He shares the routines and guardrails that prevent backlog bloat from creeping back in: Create a filter to control what gets into the backlog in the first place Keep the Product Owner just slightly ahead of the development team Avoid the anti-pattern of trying to keep all developers busy all the time Remember that backlog items don't age well and lose relevance over time These practices ensure the team stays focused on delivering current value rather than managing an ever-growing list of aging requirements. About Kent McDonald With decades in software product development, Kent is a go-to expert in product management, and agile strategy. He is a seasoned consultant and author of three books on agility, he helps teams cut through clutter to focus on what truly matters. When not optimizing workflows, he's exploring National Parks (52/63) or grooving to some jazz tunes. You can link with Kent McDonald on LinkedIn, or follow Kent McDonaldn on Substack.
We're in a season of disruption—political shifts, evolving policies, contracting delays, and social tensions are impacting how business gets done, especially in the federal space. If you're a small business owner or leader trying to make sense of how to stay relevant—or just stay open—you're not alone.In this episode, we're unpacking how to navigate the high-stakes environment of public sector contracting when the rules seem to keep changing. We'll explore how policy, politics, and procurement slowdowns intersect with real-world business survival.Then, we'll shift gears and talk about tangible strategies to pivot smartly—without losing your footing. Whether you're repositioning your offers, realigning with a new customer, or expanding to commercial markets, this conversation is your guide to pivoting with power, not panic.Guest Bio:Shaun Edens founded Lucky Rabbit in 2020 and has since led its growth into a trusted digital modernization partner for agencies like USCIS, OPM, CMS, GSA, and ED, as well as commercial clients like CrabPlace.com. With a background in senior roles at firms including CTEC, TechFlow, Enlightened, and Booz Allen Hamilton, he brings deep expertise in agile transformation, cloud migration, DevSecOps, and enterprise architecture.Shaun holds an MBA from the University of Illinois and a B.S. in Computer Science from Morehouse College. He's certified in SAFe, Scrum, Product Ownership, and AWS, and skilled in tools like ReactJS, Go, Python, and CI/CD pipelines. Focused on innovation and transparency, Shaun continues to lead Lucky Rabbit in delivering human-centered, secure digital solutions that drive real impact.Call(s) to Action:Help spread the word about Unveiled: GovCon Stories: https://shows.acast.com/unveiled-govcon-storiesDo you want to be a guest or recommend a topic that you would like to learn or hear about on the podcast? Let us know through our guest feedback and registration form.Links:Lucky RabbitLucky Rabbit BlueTechFollow Lucky Rabbit on LinkedInSponsors:The views and opinions expressed in this podcast are solely those of the hosts and guests, and do not reflect the views or endorsements of our sponsors.Withum – Diamond Sponsor!Withum is a forward-thinking, technology-driven advisory and accounting firm, helping clients to be in a position of strength in today's complex business environment. Go to Withum's website to learn more about how they can help your business! Hosted on Acast. See acast.com/privacy for more information.
ABOUT JON HYMANJon Hyman is the co-founder and chief technology officer of Braze, the customer engagement platform that delivers messaging experiences across push, email, in-app, and more. He leads the charge for building the platform's technical systems and infrastructure as well as overseeing the company's technical operations and engineering team.Prior to Braze, Jon served as lead engineer for the Core Technology group at Bridgewater Associates, the world's largest hedge fund. There, he managed a team that maintained 80+ software assets and was responsible for the security and stability of critical trading systems. Jon met cofounder Bill Magnuson during his time at Bridgewater, and together they won the 2011 TechCrunch Disrupt Hackathon. Jon is a recipient of the SmartCEO Executive Management Award in the CIO/CTO Category for New York. Jon holds a B.A. from Harvard University in Computer Science.ABOUT BRAZEBraze is the leading customer engagement platform that empowers brands to Be Absolutely Engaging.™ Braze allows any marketer to collect and take action on any amount of data from any source, so they can creatively engage with customers in real time, across channels from one platform. From cross-channel messaging and journey orchestration to Al-powered experimentation and optimization, Braze enables companies to build and maintain absolutely engaging relationships with their customers that foster growth and loyalty. The company has been recognized as a 2024 U.S. News & World Report Best Companies to Work For, 2024 Best Small & Medium Workplaces in Europe by Great Place to Work®, 2024 Fortune Best Workplaces for Women™ by Great Place to Work® and was named a Leader by Gartner® in the 2024 Magic Quadrant™ for Multichannel Marketing Hubs and a Strong Performer in The Forrester Wave™: Email Marketing Service Providers, Q3 2024. Braze is headquartered in New York with 15 offices across North America, Europe, and APAC. Learn more at braze.com.SHOW NOTES:What Jon learned from being the only person on call for his company's first four years (2:56)Knowing when it's time to get help managing your servers, ops, scaling, etc. (5:42)Establishing areas of product ownership & other scaling lessons from the early days (9:25)Frameworks for conversations on splitting of products across teams (12:00)The challenges, complexities & strategies behind assigning ownership in the early days (14:40)Founding Braze (18:01)Why Braze? The story & insights behind the original vision for Braze (20:08)Identifying Braze's product market fit (22:34)Early-stage PMF challenges faced by Jon & his co-founders (25:40)Pivoting to focus on enterprise customers (27:48)“Let's integrate the SDK right now” - founder-led sales ideas to validate your product (29:22)Behind the decision to hire a chief revenue officer for the first time (34:02)The evolution of enterprise & its impact on Braze's product offering (36:42)Growing out of your early-stage failure modes (39:00)Why it's important to make personnel decisions quickly (41:22)Setting & maintaining a vision pre IPO vs. post IPO (44:21)Jon's next leadership evolution & growth areas he is focusing on (49:50)Rapid fire questions (52:53)LINKS AND RESOURCESWhen We Cease to Understand the World - Benjamín Labatut's fictional examination of the lives of real-life scientists and thinkers whose discoveries resulted in moral consequences beyond their imagining. At a breakneck pace and with a wealth of disturbing detail, Labatut uses the imaginative resources of fiction to tell the stories of Fritz Haber, Alexander Grothendieck, Werner Heisenberg, and Erwin Schrödinger, the scientists and mathematicians who expanded our notions of the possible.This episode wouldn't have been possible without the help of our incredible production team:Patrick Gallagher - Producer & Co-HostJerry Li - Co-HostNoah Olberding - Associate Producer, Audio & Video Editor https://www.linkedin.com/in/noah-olberding/Dan Overheim - Audio Engineer, Dan's also an avid 3D printer - https://www.bnd3d.com/Ellie Coggins Angus - Copywriter, Check out her other work at https://elliecoggins.com/about/
Eine Zertifizierung ist für viele Product Owner ein Thema, das immer wieder aufkommt – oft dann, wenn sie neu in der Rolle sind oder sich weiterentwickeln wollen. Doch was bringt eine Zertifizierung wirklich? Ist sie nur ein Türöffner für den ersten Job oder hilft sie tatsächlich dabei, ein besserer Product Owner zu werden? Gleichzeitig gibt es eine Vielzahl an Anbietern für solche Zertifizierungen – von etablierten Organisationen wie der Scrum Alliance oder scrum.org bis hin zu eher unbekannten Anbietern. Jede Organisation verspricht einen eigenen Mehrwert. Manche Zertifikate lassen sich durch das Bestehen eines Online-Tests erwerben, andere setzen auf Trainings mit erfahrenen Coaches. Doch nicht jede Zertifizierung passt zu jedem Kontext oder Lerntyp. Eine Zertifizierung kann ein guter Einstieg sein, um sich strukturiert mit den Grundlagen des Product Ownership auseinanderzusetzen. Sie gibt Orientierung und zeigt, welche Themen zur Rolle gehören. Aber sie ersetzt nicht die tägliche Praxis, nicht den Austausch im Team, nicht die Auseinandersetzung mit Stakeholdern oder Nutzerbedürfnissen. Wer Product Owner ist, lernt ständig dazu – unabhängig vom Zertifikat auf dem Papier. Besonders spannend wird es, wenn wir uns die Motivation anschauen, warum Menschen überhaupt eine Zertifizierung machen wollen. Geht es um ein besseres Gehalt? Um Sichtbarkeit im Unternehmen? Oder darum, sich selbst sicherer in der Rolle zu fühlen? Je nach Zielsetzung können ganz unterschiedliche Formate sinnvoll sein. Für manche ist zum Beispiel ein Einstiegskurs wie der „Professional Scrum Product Owner“ (PSPO I) ideal, andere profitieren mehr von Advanced-Kursen mit Fokus auf Stakeholder-Management, strategischer Produktentwicklung oder Leadership. Zertifizierungen sind also weder gut noch schlecht – sie sind Werkzeuge. Und wie bei allen Werkzeugen kommt es darauf an, wie man sie einsetzt. Ein Product Owner, der gelernt hat, wie wichtig kontinuierliche Validierung von Hypothesen ist, wird sich nicht auf ein Zertifikat verlassen, sondern im Alltag ausprobieren, verwerfen, neu denken. Genau das macht die Rolle so anspruchsvoll – und so spannend. Am Ende zählt weniger, welches Logo auf dem Zertifikat steht, sondern was die Person daraus macht. Wer bereit ist, kontinuierlich zu lernen, Feedback anzunehmen und sich mit anderen POs zu vernetzen, braucht nicht unbedingt eine Zertifizierung, um gute Arbeit zu leisten. Aber sie kann ein sinnvoller Baustein sein – vor allem dann, wenn sie nicht als Endpunkt, sondern als Anfang verstanden wird.
In this episode of the Scrum.org Community Podcast, Dave West and PST Andy Brandt explore the state of Agile transformations and the shift toward the Agile Product Operating Model (APOM) as featured in their recently written whitepaper. While Agile has been widely adopted, challenges like misalignment between business strategy and technical execution persist. Andy shares how focusing on products instead of work and starting small with one team can drive meaningful change. They discuss the role of AI in enhancing productivity, the importance of organizational alignment, and how executive commitment can lead to spectacular results. Tune in to learn how to move beyond Agile transformations and embrace a product-first mindset!Referenced whitepaper: Moving Beyond Agile Transformations: Leveraging the Agile Product Operating Model
BONUS: Challenging the Agile Status Quo with #NoBacklogs, Allan Kelly In this BONUS episode, we explore the provocative ideas of Allan Kelly, the author who introduced #NoBacklogs to the Agile community. Allan shares his insights on why traditional backlogs may be hindering true agility, offers practical alternatives, and explains how teams can maintain accountability while focusing on outcomes rather than outputs. The Problem with Traditional Backlogs "Backlogs keep ideas for far too long." Allan Kelly challenges the conventional wisdom of maintaining extensive backlogs in Agile environments. He distinguishes between sprint backlogs and product backlogs, highlighting how the latter often becomes a repository for stale ideas that outlive their relevance. Allan argues that this practice undermines the adaptability that should be at the core of Agile methodologies, transforming what should be a flexible approach into a more rigid, traditional project management framework. Outcome-Focused Alternatives "What are you doing to try and change the world?" Instead of lengthy backlogs filled with specific tasks and features, Allan advocates for approaches centered on outcomes and meaningful change. He discusses the concept of OKRs (Objectives and Key Results) as a form of "test first management" - a powerful framework that shifts focus from outputs to measurable impacts. This perspective encourages teams to consider the broader purpose of their work rather than simply executing a predetermined list of tasks. Balancing Structure and Flexibility "There should be a 'Best before' date for all backlog items." Finding the right balance between necessary structure and agile flexibility is crucial for effective delivery. Allan suggests implementing a "best before" date for all backlog items to prevent the accumulation of outdated ideas. He emphasizes starting with the Sprint Goal as a guiding principle, using it to create focus and purpose that allows teams to adapt their approach while maintaining a clear direction. Breaking Free from Traditional Mindsets "The work to do is not a fixed entity." According to Allan, the reliance on extensive backlogs has perpetuated traditional project management mindsets within supposedly Agile organizations. He challenges the underlying assumption that the scope of work is a predetermined, fixed entity waiting to be discovered and documented. Instead, he suggests embracing the evolving nature of work, allowing teams to respond to changing priorities and insights as they emerge. Maintaining Accountability Without Backlogs "Test first management as a management innovation that helps focus on goals, and measure progress by the teams." Allan addresses concerns about accountability by offering practical approaches to tracking progress without traditional backlogs. He emphasizes the importance of regular demonstrations of working solutions and assessing whether these demonstrations align with the team's strategic direction. His concept of "test first management" provides a framework for focusing on goals while measuring genuine progress rather than simply tracking task completion. Resources for Deeper Learning "Honey, I shrunk the backlog." For listeners interested in exploring these ideas further, Allan recommends his YouTube presentation "Honey, I shrunk the backlog," which offers additional insights and practical guidance on implementing a #NoBacklogs approach in Agile teams. About Allan Kelly Allan Kelly is the author of #noprojects: A Culture of Continuous Value, and an outspoken Agile practitioner that helped introduce the idea of #NoBacklogs to the Agile community. His work spans several decades, and includes some breakthrough contributions that he shares in his books and conference talks. He is the author, among others, of Project Myopia: Why projects damage software, Continuous Digital: An agile alternative to projects for digital business, The Art of Agile Product Ownership: A Guide for Product Managers, Business Analysts, and Entrepreneurs, and Xanpan: Team Centric Agile Software Development. You can link with Allan Kelly on LinkedIn.
Global Agile Summit Preview: Implementing Agile Practices for Data and Analytics Teams with Henrik Reich In this BONUS Global Agile Summit preview episode, we dive into the world of Agile methodologies specifically tailored for data and analytics teams. Henrik Reich, Principal Architect at twoday Data & AI Denmark, shares his expertise on how data teams can adapt Agile principles to their unique needs, the challenges they face, and practical tips for successful implementation. The Evolution of Data Teams "Data and analytics work is moving more and more to be like software development." The landscape of data work is rapidly changing. Henrik explains how data teams are increasingly adopting software development practices, yet there remains a significant knowledge gap in effectively using certain tools. This transition creates both opportunities and challenges for organizations looking to implement Agile methodologies in their data teams. Henrik emphasizes that as data projects become more complex, the need for structured yet flexible approaches becomes critical. Dynamic Teams in the Data and Analytics World "When we do sprint planning, we have to assess who is available. Not always the same people are available." Henrik introduces the concept of "dynamic teams," particularly relevant in consulting environments. Unlike traditional Agile teams with consistent membership, data teams often work with fluctuating resources. This requires a unique approach to sprint planning and task assignment. Henrik describes how this dynamic structure affects team coordination, knowledge sharing, and project continuity, offering practical strategies for maintaining momentum despite changing team composition. Customizing Agile for Data and Analytics Teams "In data and analytics, tools have ignored agile practices for a long time." Henrik emphasizes that Agile isn't a one-size-fits-all solution, especially for data teams. He outlines the unique challenges these teams face: Team members have varying expectations based on their backgrounds Experienced data professionals sometimes skip quality practices Traditional data tools weren't designed with Agile methodologies in mind When adapting Agile for data teams, Henrik recommends focusing on three key areas: People and their expertise Technology selection Architecture decisions The overarching goal remains consistent: "How can we deliver as quickly as possible, and keep the good mood of the team?" Implementing CI/CD in Data Projects "Our first approach is to make CI/CD available in the teams." Continuous Integration and Continuous Deployment (CI/CD) practices are essential but often challenging to implement in data teams. Henrik shares how his organization creates "Accelerators" - tools and practices that enable teams to adopt CI/CD effectively. These accelerators address both technological requirements and new ways of working. Through practical examples, he demonstrates how teams can overcome common obstacles, such as version control challenges specific to data projects. In this segment, we refer to the book How to Succeed with Agile Business Intelligence by Raphael Branger. Practical Tips for Agile Adoption "Start small. Don't ditch scrum, take it as an inspiration." For data teams looking to adopt Agile practices, Henrik offers pragmatic advice: Begin with small, manageable changes Use established frameworks like Scrum as inspiration rather than rigid rules Practice new methodologies together as a team to build collective understanding Adapt processes based on team feedback and project requirements This approach allows data teams to embrace Agile principles while accounting for their unique characteristics and constraints. The Product Owner Challenge "CxOs are the biggest users of these systems." A common challenge in data teams is the emergence of "accidental product owners" - individuals who find themselves in product ownership roles without clear preparation. Henrik explains why this happens and offers solutions: Clearly identify who owns the project from the outset Consider implementing a "Proxy PO" role between executives and Agile data teams Recognize the importance of having the right stakeholder engagement for requirements gathering and feedback Henrik also highlights the diversity within data teams, noting there are typically "people who code for living, and people who live for coding." This diversity presents both challenges and opportunities for Agile implementation. Fostering Creativity in Structured Environments "Use sprint goals to motivate a team, and help everyone contribute." Data work often requires creative problem-solving - something that can seem at odds with structured Agile frameworks. Henrik discusses how to balance these seemingly conflicting needs by: Recognizing individual strengths within the team Organizing work to leverage these diverse abilities Using sprint goals to provide direction while allowing flexibility in approach This balanced approach helps maintain the benefits of Agile structure while creating space for the creative work essential to solving complex data problems. About Henrik Reich Henrik is a Principal Architect and developer in the R&D Department at twoday Data & AI Denmark. With deep expertise in OLTP and OLAP, he is a strong advocate of Agile development, automation, and continuous learning. He enjoys biking, music, technical blogging, and speaking at events on data and AI topics. You can link with Henrik Reich on LinkedIn and follow Henrik Reich's blog.
Season Hughes: From Defensive to Collaborative Product Ownership Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Building Team and Customer Connection A great Product Owner demonstrates deep care for both the product and the team members, understanding their challenges and experiences. Season highlights how exceptional POs actively advocate for customer involvement in sprint reviews and consistently conduct customer interviews, creating a strong bridge between the development team and end-users. The Bad Product Owner: The Defensive Questioner Season describes a challenging situation where a Product Owner would respond to team proposals with defensive "why" questions, creating an atmosphere where developers felt they needed to justify their suggestions. This approach led to team defensiveness and reduced collaboration, highlighting the importance of asking questions in a way that promotes understanding rather than creates tension. Self-reflection Question: How do you ensure your communication style encourages collaboration rather than defensiveness? [The Scrum Master Toolbox Podcast Recommends]
Heute freue ich mich, gleich zwei Gäste von George Labs begrüßen zu dürfen: Roland Illés und Julia Zaadorian-Klammer. Roland ist Lead Designer mit 12 Jahren Erfahrung und leitet die Wealth & Payments Teams. Dabei balanciert er diese Rolle mit seiner Tätigkeit als Individual Contributor für George Invest. Sein Fokus liegt darauf, klares und menschliches Wording in Designs zu verwenden und dabei auf „bankish“ zu verzichten.Julia ist Leiterin des User Experience Research Teams bei George Labs und bringt über 17 Jahre Erfahrung in User Experience und User-Centered Design mit. Ihr kennt Julia schon aus 2 UX Heroes Folgen - Folge 26 gehört zu den 3 meistgehörten Folgen von UX Heroes und sie ist heute gleich das dritte Mal dabei. Mit ihrem Hintergrund in Psychologie ist es ihr besonders wichtig, den Dingen auf den Grund zu gehen – sei es, die Ursachen von Usability-Problemen zu verstehen oder die Auswirkungen von Produktentscheidungen auf die Nutzer zu analysieren.George Labs ist das Innovationszentrum und Designstudio der Erste Group, das hinter dem digitalen Banking George steht. George dient heute als digitale Finanzplattform für über 10 Millionen Kunden in Europa. Neben der Product Ownership für George ist George Labs verantwortlich für UX- und UI-Design sowie Forschung im Bereich digitales Banking. Mit aktuell 74 Mitarbeitenden und einem agilen Ansatz und einem Fokus auf Kreativität unterstützt George Labs die kontinuierliche Weiterentwicklung der Plattform. Gemeinsam mit anderen Departments und Banken der Erste Group arbeiten insgesamt ca. 500 Personen an George.Julia und Roland teilen spannende Einblicke darüber, wie sie mit diesem großen Team von 500 Mitarbeitenden User Experience Maßnahhmen steuern, um eine Plattform zu entwickeln die auch für Investment-Neulinge zugänglich ist. Sie erzählen von MVP-Testing, der Wichtigkeit „bankish“ zu vermeiden, ihren Designentscheidungen und der Balance zwischen Nutzerfreundlichkeit und den regulatorischen Anforderungen als Bank.Julia und Rolands LinksJulias LinkedInRolands LinkedInRessourcenResearchOpsBuilt for Mars NewsletterHeyDesigner Newsletter Julian und Rolands BuchempfehlungenDesigning for the Digital Age - Kim GoodwinThe Making of a Manager - Julie ZhuoIch hoffe, ihr fandet diese Folge nützlich. Wenn ihr auch die nächsten nicht verpassen wollt - abonniert UX Heroes doch auf Spotify, Apple oder eurem Lieblingspodcaster - ihr könnt uns dort auch bis zu 5 Sterne als Bewertung dalassen. Wenn Ihr Fragen oder Feedback habt, schickt uns doch gerne eine Nachricht an podcast@userbrain.com.Ihr findet ihr mich auf LinkedIn unter Markus Pirker. Bis bald bei UX Heroes.UX Heroes ist ein Podcast von Userbrain.
Karthiga Seturaj: The Isolated Product Owner, Lacking Collaboration and Engagement Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Dealing With Uncertainty and Growing Team Trust Karthiga shares the characteristics of an exemplary Product Owner, emphasizing their ability to navigate ambiguity and support their teams during challenging moments. Great Product Owners demonstrate strong leadership, foster team relationships, and celebrate successes, contributing to a positive and collaborative environment. The Bad Product Owner: The Isolated PO, Lacking Collaboration and Engagement Karthiga discusses anti-patterns in Product Ownership, including the absence of strong relationships with developers and testers. A “bad” PO often fails to collaborate effectively within the “three amigos” framework or acts solely as a task scribe. These behaviors hinder refinement and the overall development process, emphasizing the need for active, communicative Product Owners. Self-reflection Question: How does your Product Owner foster collaboration with developers and testers? [The Scrum Master Toolbox Podcast Recommends]
Patricia Kong is back to flip the script and interview Dave about Product Definition, answering remaining questions from his webinar on the topic a few weeks ago. Dave covers:Challenges in Moving to a Product OrganizationImpact of Digital Products and Organizational ComplexityTransitioning to a Product ModelCore vs. Context in Product PortfolioRole of AI in Product DevelopmentTune in for great insights!
In this episode of the Scrum.org Community Podcast, Mik Kersten, CTO at Planview, returns to chat with Dave about the movement from project-centric to product-driven models, reflecting on the recent Project to Product event where they both spoke. Together, they explore how pragmatic organizations are embracing product operating models, underscoring the need for executive sponsorship, business alignment, and visibility into flow metrics. Kersten shares valuable lessons from Vanguard's success, the challenges of technical debt, and the importance of infrastructure for sustained transformation. Tune in to learn why Mik and Dave are optimistic about the future of product-based models, especially with agile and DevOps practices setting the foundation for success.
In this Ask a PST session, Agile Director, Executive Coach and Professional Scrum Trainer Jay Rahman answers listener questions and offers advice about their Scrum challenges and obstacles. Jay offers strategies for avoiding and recovering from product delivery failures. Jay emphasized the importance of alignment across leadership, management, and teams, and the need for business and technology to work together. He highlights the critical role of Retrospectives in identifying and addressing issues, and the necessity of senior leadership's accountability. Jay also stresses the importance of Product Owners being fully engaged and available, and the value of using OKRs to foster a culture of accountability. He shares practical examples, such as cross-skilling teams to reduce dependencies and leveraging stakeholder metrics to prioritize requirements. Tune in for a thought provoking session!
Jelena Vucinic: Why Sharing Product Ownership Leads to Better Product Results Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Sharing Product Ownership with the Team In this episode, Jelena highlights the qualities of a great Product Owner (PO) who excels by sharing product ownership with the team. This PO had deep knowledge of the product but also understood that they didn't need to know everything. By involving the team in product decisions and creating a sense of co-ownership, the team became more engaged and motivated to deliver better results. Jelena emphasizes that this collaborative approach helps the team to fully understand customer needs and take pride in the product's success. The Bad Product Owner: Two Anti-Patterns, The Controller and The Organizer Jelena identifies two common anti-patterns in Product Owners: The Controller and The Organizer. The Controller tries to make every decision, leading to a bottleneck and stifling team creativity. On the other hand, The Organizer focuses more on coordination and administration but lacks a deep understanding of the product. This PO is often disconnected from the team's efforts and the product vision. Jelena suggests fostering better collaboration and encouraging Product Owners to involve the team in decision-making processes, particularly through practices like mobbing, which can help integrate the PO more closely with the team and the product. About Jelena Vucinic Jelena is a self-conscious perfectionist and an everlasting optimist. She is deeply curious about the way people interact. After listening attentively, she likes to ask open questions that often help to reflect and improve collaboration. Jelena believes that every single person makes a difference, and she is dedicated to helping teams and leaders unlock their potential. You can link with Jelena Vucinic on LinkedIn.
Dominika Bula: The Power of Storytelling in Product Ownership Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Storytelling and Focus Dominika shares a story about a great Product Owner (PO) who excelled in communicating the essence of what the team was doing through storytelling. This PO acted as an ambassador, bridging the gap between the team and stakeholders. They knew when to step in and when to step back, allowing the team to contribute their ideas. This PO also helped the team focus by presenting clear objectives and guiding the team through challenges without micromanaging. Their ability to communicate and foster collaboration made them an excellent example of what a Product Owner should strive to be. The Bad Product Owner: Overwhelmed and Isolated In contrast, Dominika highlights a negative Product Owner pattern where the PO tried to take on too much by themselves. Lacking a holistic view of their role, this PO attempted to manage everything alone, making decisions without team input and feeling overwhelmed as a result. This led to a lack of team collaboration, with the team feeling unappreciated and their feedback ignored. The PO, in this case, failed to justify or validate their decisions, leading to disengagement and frustration for both the PO and the team. Self-reflection Question: Are you fostering collaboration as a Product Owner, or are you trying to manage everything on your own? Leave your answer in the comments, let's get this conversation started! About Dominika Bula Dominika is an Agile Coach at SAP Signavio with a strong background in agile practices from her experiences at Oracle and Red Hat. She is passionate about Kanban and firmly believes that Agile and DevOps are the perfect combination. As a facilitator for the Women in Agile mentorship program, Dominika is dedicated to supporting and nurturing the next generation of agile leaders. You can link with Dominika Bula on LinkedIn.
Don't Make This Mistake! The Importance of Product Ownership In this episode, Rachel is getting really passionate about the possibility of making one huge mistake…not taking ownership of your products in your apparel brand. In Rachel's 20+ years of experience in the apparel industry, she's seen and heard it all. She shares real-life stories and recent client calls that demonstrate how skipping certain steps can compromise your product's quality and jeopardize your brand's future. From production mishaps to changing vendors, she goes deep in explaining the significant dangers and highlights why it's important to retain control over your tech packs, patterns, and materials to ensure consistency, customer loyalty, and brand survival. In this episode, you'll hear: -A lot of start-ups are developing product through their manufacturers - why this is a HUGE mistake. -At some point, you will need to diversify your sourcing base. -A real-life example of what can go wrong and what can happen when there's a mishap with your factory. -Why it's important to own your tech packs and patterns and how this helps you in the future. We can't wait to hear what you think of this episode! Purchase the Business of Apparel Online Course: https://www.thebusinessofapparel.com/course To connect with Rachel, you can join her LinkedIn community here: LinkedIn. To visit her website, go to: www.unmarkedstreet.com.
Paul Kuijten and Fredrik Wendt join Dave West again to discuss the third piece of the Professional Product Ownership Capabilities model - Evolve with Validation. They discuss the importance of understanding and validating the "why" behind product features. They discuss the evolution from traditional requirements to user stories and outcomes, and the need for continuous experimentation to validate assumptions. The conversation highlights the shift towards more empirical and economic validation methods, the role of AI in enhancing this process, and the importance of team collaboration in achieving product success.
In this episode, Kate and Ryan discuss the potential of AI tools in product ownership and product planning. They explore how AI tools like ChatGPT and the emerging "product owner in a box" tool reshape how Product Owners and Product Managers write user stories, create release plans, and support product development. Ryan shares his experience using AI as a thought partner for automating tasks and overcoming writer's block, while Kate emphasizes the importance of critical thinking and human oversight. Together, they reflect on how AI can enhance productivity and creativity, making work more efficient and enjoyable but never entirely replacing the human touch. Tune in to hear about the balance between leveraging AI for productivity and maintaining the unique value of human intuition.
Eli Goodman: Keeping Product Teams Aligned, Advice for Product Leaders in Remote Teams NOTE: We want to thank the folks at Tuple.app for being so generous with their stories, and supporting the podcast. Visit tuple.app/scrum and share them if you find the app useful! Remember, sharing is caring! Eli reflects on the unique challenges of being a product manager for a distributed team. He emphasizes the importance of staying in touch with reality, testing assumptions, and journaling as key habits for success. He also shares tips on how to pair effectively with colleagues to maintain accountability and stay aligned with the team's goals. Listen in to find out what are some of the key habits that can help product managers thrive in remote environments. Featured Retrospective Format for the Week: The Sailboat Retrospective In this episode, Eli Goodman, Head of Product at Tuple, shares his favorite retrospective format: the Sailboat Retrospective. Eli explains why this format helps teams visualize their progress and challenges while promoting open communication. He highlights the importance of retrospectives in creating alignment and continuous improvement within distributed teams. About Eli Goodman Eli Goodman has been working on software teams for 17 years. He's been a full-stack developer and engineering manager at both large and small companies, including Etsy and Headspace. A few years ago, Eli transitioned to product management and is now the Head of Product at Tuple, a remote pair programming service used by companies such as Figma, Shopify, and many others in the software industry. You can link with Eli Goodman on LinkedIn, or email Eli at Eli@Tuple.app.
In this episode of the Scrum.org community podcast, PSTs Paul Kuijten, and Fredrik Wendt join Dave to discuss the "lead to value" capability in Professional Product Ownership. They emphasize the importance of contextual awareness, understanding market dynamics, and aligning product strategies with business goals. They highlight the challenges of defining products, the impact of organizational capabilities, and the necessity of considering financial aspects and pricing strategies. The conversation also touches on the iterative nature of product definition and the need for long-term decision-making to avoid accumulating technical and business debt. A key theme in this discussion is the importance of leading teams towards value creation and the practical application of Product Ownership principles.
In this series, we will be exploring the key tenets of the Capabilities and Skills of Professional Product Ownership. This first episode focuses on the "Engage with Vision" area. PSTs Fredrik Wendt and Paul Kuijten emphasize the importance of a shared vision for product development, highlighting that a clear, inspiring vision aligns the team towards a common goal. They share examples stressing the need for vision clarity and its practical application. The conversation also covers the importance of goals, roadmaps, and stakeholder engagement, as well as fostering innovation and creativity within the team. The discussion underscores the role of leadership in creating an environment that empowers teams to deliver value.
Johann Botha: The Role of Self-Accountability in Product Ownership Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Role of Self-Accountability in Product Ownership Great Product Owners understand both the business and the team's needs. Johann shares an inspiring example of a PO who not only managed the product but also guided the team with a deep understanding of business and technology. What qualities set great Product Owners apart, and how can they drive both product and team success? Johann highlights the importance of accountability and collaboration in effective Product Ownership. The Bad Product Owner: How Bad Product Owners Derail Agile Teams A bad Product Owner (PO) can derail even the best Agile efforts. Johann discusses common PO anti-patterns and the importance of getting PO responsibilities right. Why do organizations struggle with effective Product Ownership, and how can they avoid common pitfalls? Johann emphasizes the critical role of the PO in maximizing value and maintaining team morale. [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Johann Botha Johann joins us from South Africa, helping build digital-age capabilities by developing practical skills to solve problems, grow people, and facilitate difficult change. A long-time proponent of Lean and Agile, Johann consults, coaches, speaks, and writes on the topic. He is also the chief examiner for the EXIN Agile Scrum product. You can link with Johann Botha on LinkedIn and connect with Johann Botha on Twitter.
In this Scrum.org Community Podcast episode, PSTs Paul Kuijten and Lavaneesh Gautam join to discuss the creation of the new Professional Product Discovery and Validation class that officially launched today, aimed at helping Product Owners and Product Managers validate product ideas before development. They share insights on the development process, including beta classes, customer feedback, and evaluating market and solution fit. They explain how they used techniques from the class to develop it. The episode highlights the importance of continuous learning, data-driven decision-making, and experimentation.
Pooja Gupta: The Role of Business Knowledge in Effective Product Ownership Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Empowering Teams with a Clear Product Vision Pooja shares an inspiring story of a Product Owner who turned a struggling team around by focusing on the product vision and applying models like SCARF and the Five Dysfunctions model. This Product Owner's approach not only clarified the team's goals but also empowered the team to take ownership of the product's short and long-term success. The Bad Product Owner: Escaping the JIRA Secretary Syndrome Pooja discusses a common anti-pattern where Product Owners become "JIRA secretaries," focusing on backlog management rather than being involved in business decisions. She explains how this lack of business knowledge can turn Product Owners into bottlenecks, hindering team progress. Pooja emphasizes the need for Product Owners to have a deep understanding of the business and to bring a clear vision for the product. What are the dangers of having a Product Owner who isn't aligned with the business, and how can you avoid this anti-pattern? Listen in to find out! [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Pooja Gupta Pooja is an Agile Coach at Visma Solutions and Agile Community Lead for Visma Group. With a passion for "limitless learning" and "selfless teaching," she brings empathy and a people-centric approach to her work and everyday life. Based in Helsinki for 9 years, she finds balance through yoga, meditation, and family life. You can link with Pooja Gupta on LinkedIn.
In this episode of the Scrum.org Community podcast, Steve Lizotte, VP of Engineering at NEC, and PST Yuval Yeret are interviewed by Dave about the practical implementation of Scrum and Kanban practices at NEC as a part of our Value Delivered series. They explore the importance of collaboration, continuous improvement, and maintaining a customer-centric approach. Steve shares insights on separating program teams from product teams, finding the right balance between custom solutions and standardized offerings, and managing the tension between empowering teams and cognitive load. The discussion also touches on the evolution of Automated Fingerprint Identification Systems (AFIS), the complexities of managing agile delivery in challenging environments, and the critical role of Product Ownership and accountability in driving successful outcomes.
In this episode of Ask a PST, we focus in on Product Ownership, Sam Falco answers questions about stakeholder engagement, PO participation in Scrum Events, measuring value, the shift from a Scrum Master to a Product Owner and more!
Karina Margole: User-Centric Product Ownership, A Key to Agile Team engagement Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: User-Centric Product Ownership, A Key to Agile Team engagement Karina shares a success story of an engaged and technically adept Product Owner who collaborated closely with the team and stakeholders. This PO's focus on user-centric solutions and effective communication led to a successful project outcome. The Bad Product Owner: The Consequences of a Disengaged and Absent Product Owner In this segment, Karina tells the story of a project plagued by an absent Product Owner, leading to poor communication and integration issues between teams. This scenario highlights the importance of a PO's active involvement in the development process. What happens when a Product Owner is disengaged? Discover the pitfalls of absentee Product Owners and how to avoid them. [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Karina Margole Karina Margole is an Agile Coach with over a decade of experience, based in the UK. She has ADHD and a passion for creating an environment where everyone can do their best work. Karina approaches her work with a holistic, systemic view while also paying attention to individuals on a personal level. You can link with Karina Margole on LinkedIn.
In this episode of the Scrum.org Community Podcast as a part of our Value Delivered series highlighting Scrum case studies, host Dave West, sits down with Professional Scrum Trainer Mary Iqbal, founder of Rebel Scrum and organizer of Scrum Day Madison. They discuss the agile transformation journey of WPS, a leading health insurance provider. Mary shares insights into WPS's shift from a waterfall model to a product-based Agile approach using Scrum, the challenges faced during this transition, and the strategies employed to streamline product ownership and improve delivery processes. Tune in to learn about the importance of defining clear products, empowering teams and fostering a product mindset in large-scale agile implementations.
Milica Lubinic: Product Owner Anti-Pattern, The Renamed Project Manager Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Balancing Involvement and Authority in Product Ownership Milica highlights how great Product Owners involve their teams in decision-making while maintaining responsibility for final decisions. She discusses tools for prioritization and the importance of structured approaches to processing team input. Scrum Masters can help PO's balance ownership and shared decision making with the teams and stakeholders. The Bad Product Owner: The Renamed Project Manager Milica discusses a common anti-pattern in Product Ownership: simply renaming project managers as Product Owners, without role clarity or team involvement. She shares tips for distributing cognition between PO's and their teams. She also emphasizes the importance of clear role definitions and external training for PO's, stakeholders, and teams. [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Milica Lubinic Milica is a Mom and Professional and Organizational Coach who is all about dealing with complexity, whether it's child development or organizational/team/individual transformation and growth. She found her true calling in the world of Agile, Cynefin, and Progressive organizational cultures. Creating safe spaces for innovation, nurturing trust, and sparking engagement is her true passion. You can link with Milica Lubinic on LinkedIn.
Strobbo, an HR platform faced challenges with its software development processes. The company's initial mechanical approach to Scrum, coupled with poor communication and lack of trust, hindered progress and morale. To address these issues, Co-Founder Bert Neels brought in Professional Scrum Trainer Steven Deneir to help.This episode hosted by Leslie Morse, Product Owner at Scrum.org features Bert, Steven and Michael Voorhaen, PO at Strobbo. They discuss Strobbo's journey with Professional Scrum and how they were able to accelerate their go to market by embracing agile practices. They talk about self-management, Product Ownership, the importance of trust and more! Part 2 will be released next week!Read the written case study!
Guest: Ida Hameete, Application Security Consultant, ZenrosiOn LinkedIn | https://www.linkedin.com/in/idahameete/____________________________Host: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/sean-martin____________________________Episode NotesJoin Sean Martin in this episode of "On Location" as he speaks with Ida Hameete at the OWASP Global AppSec Conference in Lisbon. Sean and Ida dive into the critical topic of creating a robust security culture within organizations. The conversation begins with an overview of the conference, emphasizing the importance of building secure applications that protect both users and businesses.Ida, with her extensive background in product ownership and security strategy, shares her unique perspective on why a security culture is integral to an organization's overall success. She explains that fostering a security culture isn't merely about training engineers but involves a collective effort from management and executive teams to prioritize and endorse security practices.Ida underscores the significance of aligning security culture with company culture, arguing that this alignment leads to smoother operations and fewer security breaches. She elaborates on how companies with strong security awareness often use their secure products as a marketing tool to differentiate themselves in the marketplace. This strategic approach not only enhances product safety but also provides a competitive edge.The discussion also touches on the common issues where management's lack of understanding or support for security measures can hinder effective implementation. Sean and Ida explore how management's commitment to security, demonstrated through adequate resource allocation and strategic planning, can drive a positive security culture through the entire organization.Ida provides practical examples from her experience, illustrating how purpose-driven business cultures can naturally incorporate security into their core values, benefiting both employees and customers. She highlights that a well-integrated security culture can lead to better workflows, reduced costs, and enhanced customer experiences.Towards the end of their conversation, Ida reflects on the necessity of communicating the business value of security to upper management, suggesting that this approach can shift the perception of security from a fear-driven mandate to a valuable business asset. She encourages leaders to find their company's purpose and align security practices with that mission to achieve sustainable success.Listeners are invited to attend Ida's session, "Winning Buy-In: Mastering the Art of Communicating Security to Management" at the conference, which promises to offer deeper insights into securing executive support for security initiatives.Be sure to follow our Coverage Journey and subscribe to our podcasts!____________________________Follow our OWASP AppSec Global Lisbon 2024 coverage: https://www.itspmagazine.com/owasp-global-2024-lisbon-application-security-event-coverage-in-portugalOn YouTube:
Guest: Ida Hameete, Application Security Consultant, ZenrosiOn LinkedIn | https://www.linkedin.com/in/idahameete/____________________________Host: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/sean-martin____________________________Episode NotesJoin Sean Martin in this episode of "On Location" as he speaks with Ida Hameete at the OWASP Global AppSec Conference in Lisbon. Sean and Ida dive into the critical topic of creating a robust security culture within organizations. The conversation begins with an overview of the conference, emphasizing the importance of building secure applications that protect both users and businesses.Ida, with her extensive background in product ownership and security strategy, shares her unique perspective on why a security culture is integral to an organization's overall success. She explains that fostering a security culture isn't merely about training engineers but involves a collective effort from management and executive teams to prioritize and endorse security practices.Ida underscores the significance of aligning security culture with company culture, arguing that this alignment leads to smoother operations and fewer security breaches. She elaborates on how companies with strong security awareness often use their secure products as a marketing tool to differentiate themselves in the marketplace. This strategic approach not only enhances product safety but also provides a competitive edge.The discussion also touches on the common issues where management's lack of understanding or support for security measures can hinder effective implementation. Sean and Ida explore how management's commitment to security, demonstrated through adequate resource allocation and strategic planning, can drive a positive security culture through the entire organization.Ida provides practical examples from her experience, illustrating how purpose-driven business cultures can naturally incorporate security into their core values, benefiting both employees and customers. She highlights that a well-integrated security culture can lead to better workflows, reduced costs, and enhanced customer experiences.Towards the end of their conversation, Ida reflects on the necessity of communicating the business value of security to upper management, suggesting that this approach can shift the perception of security from a fear-driven mandate to a valuable business asset. She encourages leaders to find their company's purpose and align security practices with that mission to achieve sustainable success.Listeners are invited to attend Ida's session, "Winning Buy-In: Mastering the Art of Communicating Security to Management" at the conference, which promises to offer deeper insights into securing executive support for security initiatives.Be sure to follow our Coverage Journey and subscribe to our podcasts!____________________________Follow our OWASP AppSec Global Lisbon 2024 coverage: https://www.itspmagazine.com/owasp-global-2024-lisbon-application-security-event-coverage-in-portugalOn YouTube:
In this episode of the Product Podcast, unlock the secrets to leading successful product teams in our latest episode featuring Ryan Dally Gallardo, the Senior Vice President of Product at Dow Jones. Join us as Ryan takes us on her inspiring journey from intern to a pivotal leader managing top consumer brands like the Wall Street Journal.In this episode, Ryan shares how her upbringing in a large family honed her communication skills, crucial for overseeing diverse teams. Her background in market research and analytics laid a solid foundation for her current role, emphasizing the importance of understanding systems rather than coding.Dive deep into the concept of "front seat, back seat" leadership and learn how clear roles and communication are paramount in product management. Ryan also discusses the structure of Dow Jones' product teams and the advantages of having dedicated product owners for each brand and platform.Explore essential product metrics, monetization strategies, and the delicate balance between user needs and business goals. Ryan explains how Dow Jones maintains a premium user experience while integrating ads and the impact of AI on journalism. This episode offers a comprehensive guide to building and leading successful products at scale, with valuable insights into leadership, cross-functional collaboration, and the significance of context in data interpretation.Don't miss this opportunity to gain valuable insights from Ryan's wealth of experience! This episode is brought to you by Pendo, the only all-in-one product experience platform for any type of application. With all the tools you need, in one simple-to-use platform, Pendo makes it easy to answer critical questions about how users are engaging with your product—then turn those insights into action—all so you can get your users to do what you actually want them to do. Visit our website to create your free Pendo account today, and start building better experiences across every corner of your product.Episode highlights
Join Brian and Mike Cohn as they dissect the vital roles and responsibilities of the product owner, from story mapping to stakeholder management. This episode is a treasure trove for anyone looking to sharpen their Agile skills and understand the nuanced demands of a product owner. Overview In this insightful episode, Brian and Mike Cohn explore the multifaceted role of product owners in Agile development, discussing everything from market analysis and vision creation to the nuts and bolts of sprint planning and retrospectives. Emphasizing flexibility and adaptability, Brian and Mike offer a comprehensive look at how product owners can excel by focusing on strategic planning and fostering strong team dynamics. This episode is essential for product owners seeking to enhance their impact in Agile environments and drive successful outcomes. Listen Now to Discover: [1:07] - Brian welcomes special guest Mountain Goat Software and Agile Alliance founder Mike Cohn. [1:31] - Brian introduces Mountain Goat Software’s What Happens When for a Product Owner, and Mike flips the script, setting Brian, as the creator, into the guest seat on this episode. [3:16] - Join Brian as he explores the vital, behind-the-scenes efforts of product owners that set the stage for Scrum success, all before the first sprint begins. [6:24] - Brian explains the dynamics of crafting a product vision, clarifying how much responsibility lies with the product owner and how much is shared with the team. [7:46] - Brian offers expert guidance on the optimal timing for creating a story map within the Scrum process. [9:46] - Brian and Mike explore the optimal quantity of backlog items to have ready before adding them to a sprint. [13:45] - Join Brian as he explains the importance of setting a product goal in Scrum, detailing how it enhances functionality and guides the development process. [17:03] - Brian invites you to download Mountain Goat Software’s What Happens When for Product Owners, a comprehensive guide designed to support your Scrum journey. [17:43] - Brian explains how to effectively integrate road mapping into the Scrum process, ensuring it adds valuable foresight and preparation without causing shortsightedness. [19:55] - Mike suggests a strategy for managing stakeholders who overemphasize the product roadmap, offering a creative approach to preserve the flexibility and adaptability that effective road mapping allows. [22:48] - Brian delves into the critical role and strategies of effective sprint planning, essential for driving successful Scrum projects. [24:20] - Brian offers his perspective on the significance and involvement of the product owner in the daily scrum, detailing their role and contributions. [26:15] - Mike recounts a memorable story about receiving exceptionally impressive customer feedback at trustworthy.com, highlighting the impact of genuine client interactions. [28:30] - Brian emphasizes that the product owner is an integral part of the team and its goals, underscoring their collaborative role rather than being separate. [29:18] - Brian explores the crucial involvement of the product owner in the backlog refinement process, detailing their responsibilities and impact. [30:48] - Brian explains why he views the sprint review as the product owner's event and offers strategies for executing it effectively. [32:17] - Brian delves into the product owner's essential participation in the retrospective, emphasizing that their insights and experiences are crucial for the team's growth and improvement. [34:10] - Brian outlines ways the product owner can proactively prepare for the next sprint, ensuring a smooth transition and effective planning. [35:27] - Brian discusses a key pitfall that product owners should avoid to ensure success in their role. [37:35] - Brian shares a big thank you to Mike for taking over this episode of the show. [37:57] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. [38:08] - We invite you to like and subscribe to the Agile Mentors Podcast and share the episode with a friend who could benefit. [38:56] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here. References and resources mentioned in the show: Mike Cohn What Happens When For Product Owners trustworthy.com Subscribe to the Agile Mentors Podcast Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors, we are back. We are here for another episode of the Agile Mentors podcast. I'm here as always, Brian Milner, and today I have the big man back with me, the OG, we've got Mike Cohn in the house with us. Welcome in, Mike. Mike (00:15) Hey, Brian, thanks for having me back. Brian (00:18) Always happy to have Mike here. Always a pleasure to have him here and learn from his experience. And really, really grateful he's here. We wanted to have Mike on because we have something that we put together recently. Honestly, it's kind of been something we've been talking about we just haven't put together. We had a document that we had out there called What Happens When for Scrum Master. And we just didn't have one of those for a product owner. So I did some work there on the side on that and put it together. And we're getting that out for people so that you can find that and download it from our site. And we wanted Mike to come on to share his wisdom in that area as well, because a lot of this is stuff that I put together. But we wanted to get Mike's insights on these areas as well. Does that sound about right, Mike? Mike (01:11) That's what we agreed to do, but it's not what I'm going to do. Brian (01:14) Okay. Sounds good. Mike (01:19) I'm going to turn the tables on you, Brian, because it's your PDF. It's your document. You're the ideas behind this. So I kind of want to turn it around and take over. I'm going to kind of interview you, ask you things. I mean, I'll chime in with opinions here, of course. I can never shut my mouth long enough to not share an opinion. But it's your PDF. I want to ask you some questions about it, if that's OK with you. And I assume we'll have the link for this in the show notes for folks. They can get the. Brian (01:41) Sure, fair game. Yeah, absolutely. Yeah, they'll be in the show notes. Anyone can find this. If you want to download it now and follow along, just pause, you know, go find that in the show notes and you can follow along as we talk through this. Mike (01:55) Great. So Brian, you separated the document out into things that a product owner does. And of course, I mean, kind of naturally you did it by timeframe, right? Do this before you even go and do this every sprint, things like that. I want to talk to you about some of the stuff that we do before the project that a good product owner should do before a project. You had in there a couple of things like do market analysis and create a vision. You tell me more about what you would expect of a great product owner in that world. Brian (02:25) Yeah, that first bullet point, what I was trying to capture is that there's some behind the scenes kind of product, standard product work that we don't really account for in a scrum sense. Things like market analysis and trying to understand the competitive landscape. There's a whole discipline there of activity and work that goes on behind the scenes. And I think it's important to understand, that Scrum isn't in any way saying throw that out or that that's not needed, that is something that would come, in my opinion, before you even begin this kind of work. Scrum does not include in it a process that would say, let's verify that they should fund this product. Let's do a pitch. So the CEO of, you know, here's why you should have this product. That's what I was trying to capture in that first bullet point is just understand there are some standard kind of product development work that goes on that we're not, we're kind of skipping over a little bit. Mike (03:36) That's one of the things I've always loved about Scrum is that Scrum is silent, deliberately so on many topics. And occasionally I will have somebody that I'll meet and they'll say, Scrum doesn't say how we should do product envisioning, right? It doesn't say how we should do that. So I guess we don't do it. It's like, well, Scrum doesn't say that you should code, right? Nowhere in the Scrum guide does it say code your software product, right? Yet if you're doing a software product, somebody's coding, right? Somebody's doing something. And so I like that Scrum is deliberately silent on a lot of things like this because you're talking about doing this market analysis. I work with plenty of companies that are doing internal software. And if we're doing internal software, we're not going to do a market analysis, just kind of internal user needs analysis perhaps, but it's going to be very different. And so I do like that flexibility there. Brian (04:13) Hmm, yeah. Yeah. So that's a good point, though, is depending on the product, it is sort of more as needed or as it would fit. Like you said, if it's an internal product, it's going to look very different than if you're doing a public -facing one. Mike (04:40) I think for any of the steps that you've outlined, I think they can vary. I'm sure some are going to be the same for everybody, but I always think of it as commercial development, right? We're making Microsoft Word, right? I think of it as in -house development, right? We're making a payroll system to pay our employees or contract development are kind of the three big branches to me. And then things get very different within those three types of development. I'm thinking more product development there specifically, but of course we can be using this for non -product things. Brian (05:10) Well, and I do want to say that that second bullet point, they're talking about vision. That's where I honestly, from my perspective, that's where the product owner portion of this begins, right? Because that's sort of the first thing you need to do. And in fact, when we teach our CSPO class, this is, you know, if you've been through a CSPO class with us, you will recognize this order because that's exactly how we go through it in our CSPO class, very deliberately. You know, that Mike (05:39) I'm sorry, I was getting off there, but I was getting interested in something you're saying there. So product owner kind of starting with the vision. I know that the team can influence the vision, right? But where would you draw the line or how much of the vision is the product owners? Is it like, you know, I'm the product owner dictator. Here's my vision, shut up and build it. Brian (06:02) Yeah, I don't know that there's one answer there. I mean, I have seen in certain situations where it's more of a group effort. And that might be part of that earlier genesis of the product, where we go through an effort to define the vision with other key stakeholders, with leaders in the organization. I do think that there is sort of a separate activity that I would take with the team itself. So I might spend a deal of time with key stakeholders developing a vision, but then I might also then have a separate meeting with the team once that's established to say, you know, here's kind of what we're defining it as. Let's walk through this. Tell me if you agree, disagree, or how you might improve or change this. Just so that we, you know, part of our job as a product owner is to cast that vision. and help people get caught up in the excitement for what it is we're trying to do. So that's kind of the purpose there I see of doing that. Mike (07:04) Yeah. Yeah, the more excited we get people about it, the better off we're going to be throughout the course of the project. You also have some things in here about things to do before the first sprint about identifying users, possibly go into the persona level, but then also story mapping. I want to ask you about the story maps for a second. What's your guideline? Because somebody asked me this recently, I'm curious on your answer. What's your guideline for when we should create a story map? Do you do always, only at the start, only in the middle? What's your advice? Brian (07:35) Creating it, I always created at the start. I mean, my, just, and again, this is my experience, right? But what I have found to be useful is to do it at the beginning. And it's sort of right in that order, right? I've done the vision, I've talked, I figure out who my users are. And then I wanna know what the general big picture is for my product. I wanna be able to step back from a 50 ,000 foot view and say, all right, here's kind of the step by step of what we're gonna be doing. Because, you know, kind of like a product backlog, it's a living, breathing document. It's not done, you know, we do it once at the beginning of our product and then it's done set forever. It's constantly adapting and changing as we add new feature areas, as we, you know, understand differently how our users would interact with the product. We're going to adjust and change it. I want it to always reflect reality. Mike (08:30) Do you, so let's talk about reality there. I mean, I agree with that, but what I see is story maps that are hard to keep up to date. Are you seeing teams that really succeed at keeping them up to date all the time? I know the living breathing thing for like a couple months and then it's like the dusty old story map, right? Brian (08:47) Yeah, well, this is kind of one of the things where it was kind of hard for me to put this in a time frame because there's really two time frames that I would like this to appear in. Yes, I do think we should do it before the first sprint. And by the way, again, there, I would do this in multiple rounds with different sets of stakeholders. But then once it's established, I kind of would slide that into that quarterly kind of activity to say, we may not touch it every quarter, but every quarter I would want to... Mike (09:03) Sure. Brian (09:16) check in on it and just say, is this still accurate? Do we need to adjust it? Do we need to do anything different about it? Mike (09:16) Okay. see that. A couple of the things on the before the first spring here, you've got identify assumptions, possibly test some of those, and then create a product goal. And then the last couple of you got, you know, get enough of the backlog written to get started. And a sprinkle, how much of the backlog do you think a team should have to get going? I mean, I know it's probably not like seven and a half items, but you know, you're looking for, you know, one sprint, one or two sprints, eight sprints. Brian (09:45) Bye. Well, no, Mike nailed it. It's seven and a half. Seven and a half items. No, just kidding. Now we can start. No, yeah, I mean, it's, you know, that's why I use the term enough, right? What is enough? Well, you know what enough is, right? You kind of know what that is. There's a, you know, there's a goal that we have in general that we've, lots of us trainers and coaches have put out there to say, Mike (09:52) seven and a half backlog items. There we go. Once you've written seven and a half, we can get started. Brian (10:14) you want to aim for about two to three sprints worth of items that are in ready to go shape. They're ready to move into a sprint and start at any given time. I don't know that you need two to three sprints to start. Yeah, I mean, I think you need, I think there's sometimes a hesitancy in teams to get everything documented upfront. And I'm trying to help people kind of push past that to say, no, we don't need to have everything. Mike (10:25) That's a start. Brian (10:42) We just gotta have enough to start. And when I'm working with a team, I wanna get them into that first sprint as soon as possible because they're gonna learn much more from just doing it than they are from talking about it beforehand. That's why I've never been a real big fan of like a sprint zero or something like that because it just doesn't take a whole sprint to do everything that you need to do to get ready for your first sprint. Mike (10:58) Right. Yeah, I think you're right. I mean, to me, I always put it in terms of like, we're gambling our time, right? Is it worth gambling more of our valuable time writing more backlogs, or should we just play and get started? And if we're a company whose name is invoices are us, right? You know, should we go ahead and write some stories about the invoicing part of the system? Yeah, I bet we should. But if we're not sure that, I don't know what we're building, but if we're not sure invoice is going to be part of it, don't write anything about that on the backlog yet. Just put one big item, do invoices, right? Break it down when you get there. So. Brian (11:36) Yeah. Yeah, I mean, you typically know where you need to start. You know, there's a million things you could do. But when you have a big idea for a product and you're starting fresh and you're starting new with it, at least in my experience, again, I found like, I always know where I'm starting. And that's what I would encourage you to do is just get it out there, get it started. Even if you don't have all the different features and aspects of it thought through, that's OK. Mike (11:44) Right. Brian (12:05) You just want to start making progress so you learn. Mike (12:08) That reminds me of something I've shared with a lot of leadership teams that I've met with over the years, which is that I'll tell them that they're basically solving the wrong problem. And they're trying to answer the question of what should we build? What should the product be? And that's totally the wrong question. The right question is what should we build next? What's that next one or two steps that would tell you what the next four or five steps will be? And so simplify the question, not what are we building, but what are we building next? And I think you're right there. Brian (12:26) Yeah, yeah. Mike (12:36) one sprint worth is enough and put in the backlog if you need to write more backlog items. Go from there. Brian (12:41) Yeah. And I don't want anyone to hear us incorrectly here. I mean, part of the reason that we had them there to identify assumptions and try to test hypothesis is I don't want to open a, the silly example I always use in classes, I don't want to open a store that sells lip balms online and not test whether people want to buy lip balm online or not. There's some fundamental assumptions that you're going to have to test and know. Mike (12:48) Thank you. Brian (13:11) probably before you're gonna even get with a team and start getting up and running on this. And that should happen here. Mike (13:16) Yeah. I was with a company, this is years ago, they were in Boston, we finished the engagement, I'm walking next to my rental car, and one of the guys walks out with me, one of the like VPs, and he's like, I got a question for you. He says, how often should we cancel projects? And I said, Brian (13:34) Seven and a half. Mike (13:35) I don't know, seven and a half. I said, I don't know. So I don't know how often, but you should be canceling a fair number of projects. You get started, you find out it's going to take twice as long as you thought, or you get started, and it's not really going to deliver the value that you hoped for. So you stop. And he's like, I thought so. He said something like, I've been here, I think, eight years, we've never canceled a project. And it's like, OK, that's bad. You should get into these and find out your assumptions are wrong. Brian (13:51) Yeah. Wow. Yeah. Mike (14:04) I want to talk about your quarterly items on here. And you've got a couple, let me just kind of read some of these here. So you've got establish a product goal. That's a relatively new thing in Scrum. I mean, I still think of 2020 as relatively new, but as a old timer with Scrum, product goal is one of the newer enhancements. You've got doing the story writing workshop. So you're supporting what you said there. Talk to me about the product goal here. Brian (14:19) Yeah. Yeah, so I feel silly talking to Mike Cohen about what a product goal is. Product goals are just that neck, they're a milestone, right? And that's typically the way I talk about this in class is to say, especially when you're starting something new, you may not know everything that you're gonna do, but you know the next big thing that you need to accomplish. You know the next big mile marker that you're gonna hit in the life of your product. Mike (14:56) Mm -hmm. Brian (14:59) And that's what we want to establish with the product goal. Something that's going to take longer than a sprint, multiple sprints to do. I've got this in the quarterly section. And that's kind of how we tend to talk about it a lot here at Mountain Goat. But even in class, we'll even say quarterly -ish. Right, right, bigger than a sprint. And sometimes it'll be longer. Sometimes it'll be shorter. That's OK. Mike (15:16) It's the bigger than a sprint section, right? Brian (15:25) You just want to have that big thing that the team can keep their eyes on and kind of know, you know, here's, you got a sprint goal that tells us why what we're doing in this sprint is important and how my small task feeds into that. And you've got this product goal to say, how does the sprints work fit into this bigger picture of what we're trying to do? So you're making those... Mike (15:47) Yeah. Brian (15:50) connections consciously for the developers so that they are not just, hey, here's a laundry list of stuff to do, but here's the objective we're trying to accomplish. Mike (16:01) Yep. I think it's important to have something that's out there bigger than a sprint. A sprint is just, it's just kind of suboptimizing, right? I think about if you're climbing a mountain and a sprint is like, what's the highest thing I see and just always walk into the highest thing you see. Meanwhile, those are all false summits. The real summit is, you know, behind some valley, but you don't see it because you don't set out that bigger goal. And I like how you talked about it quarterly because if the goal's too big, if it's too far out there, we're not going to feel very motivated. about it. I had this the wackest example of this. I hope the guy's not listening. Actually, I hope he is. But he was told me he was on a project with the large particle collider. And he said his whole project won't be due for 40 years, right? I mean, I don't get it. But it's like they've got to run like 40 years worth of data before it's like totally done. And I just picture myself showing up for work on a 40 year project, right? Brian (16:31) Right. Yeah. Mike (16:57) I know you, you're going to be reading Dallas Cowboys news for the first 35 years, right? You know, sports news and you know. Brian (17:04) That's a 40 year project too. Mike (17:07) Well, you're not going to take it serious for 35 years. Then you're going to wake up and go, the deadline's only five years away. I better get to work on this. And then what I would do is realize, wow, I'll be retired after 40 years. So anyway, I've been silly. But I mean, you're on a project with a 40 -year deadline. How do you say motivated? And I think three months is a really good time where I can see a bigger impact than a sprint. But it's not so far. Brian (17:15) Right. Right, right, exactly. Yeah. Yeah. Mike (17:34) that that student syndrome kicks in and I feel, I don't really have to worry about it. Let's go to a long lunch. We'll get to work on it tomorrow. So I do like the quarter -ish approach there. You mentioned here a couple others here. These are probably straightforward, but manage and maintain the economics of your project, assess stakeholder relations, and road mapping. You want to talk about any of those, maybe road mapping especially? Brian (17:46) Yeah, yeah. Yeah, road mapping, I think, is an important aspect. I mean, it kind of goes along with that product goal. But I do get people who come through a product owner class that will say, I don't like this approach because it seems like it's all so short -sighted. And we're not really having the big picture of where we're going. And in my world, we have this year -long thing, or 10 year. I've worked with some teams that build automobiles and they're on a three -year release cycle. They're working on the model year that's three years ahead. I've worked with some teams that do aerospace kind of stuff and they're working on a space launch that's multi -years out in the future. Mike (18:34) Yeah. Brian (18:43) And when you ask them, how certain are you that you're really going to be working on this five years from now? Pretty darn certain, right? Because it's there. We're building toward that launch date's going to be there. So I think that that roadmap is an important step for a product owner. Now, I just want to be clear about this. When I say a roadmap, I'm not talking about setting hard and fast dates and saying, we're going to be here by this date. We're going to be there by this date. Mike (18:50) Yeah. Brian (19:12) It's okay for us to say, here's kind of where we feel things are gonna fall, but I really am a strong proponent of the forecasting method, like kind of looking ahead and seeing, you know, kind of based on yesterday's weather kind of thing, right? Here's what the weather was like at this time last year. So it's probably a good indicator of where we're gonna be at this season this year, that sort of thing. So I'm a proponent of the forecasting forward. And I think a roadmap can fall very well in line with that because we can slot things and say, here's kind of this quarter's, here's the next quarter kind of things that we're thinking that are gonna take place. And if one thing moves forward or backwards, one of those sections, that's not a big deal. It's not gonna change earth shatteringly the course of our product, but it does allow for preparation. And that's what I think is the most important thing that people lose sight of in sort of forecasting and projecting forward is why do we do this in the first place? Well, we do it most of the time because there's someone else who needs to get ready. They need to be prepared. They need to be ready when this is delivered to do XYZ. And that's what we're trying to accomplish with this. We can do that with forecasting. Mike (20:32) Yeah, I think you talk about taking those things seriously. And if we miss one, it's not the end of the world. Except there's always somebody in an organization who's going to say it is the end of the world. The danger for me with roadmaps is how serious people take them. They'll look at it and go, we got a roadmap. It says we're going to come out with this in 12 months. I bet we're going to do exactly these 12 things. And so that literalness to a roadmap. Brian (20:50) Yeah. Mike (20:59) is scary. I've only done this a couple of times, but I like the result is I put together roadmaps for with teams in a couple of organizations. And we kind of modeled them on the idea of the old, I don't know, 200 or 300 year ago, 400 year ago maps, right? And you would have like, you know, the. horrible map of what the world looked like, right? And there'd be Darby Dragons right on the edge of the map. And we actually did that on a roadmap, right? It had stacks of items are going to be delivered. You know, this, this six months, this six months. And then below there, we had just put a few things in kind of an unreadable font at Darby Dragons below there. Trying to reiterate that you can't take this that literally, but there often is somebody who's like, my annual bonus is tied to that box on the roadmap. Brian (21:24) I'm going to go ahead and close the video. Right. Well, you can see this in, you know, I'm not going to get on a tangent here on safe, but you even see this in safe when people do things like PI planning and they plan out the next quarter. One of the pitfalls that I think a lot of organizations fall into when they do that is that they see it as a commitment. That the team is making a commitment to getting all that work done in that PI, in that program increment. And that's not the way it's intended. It's intended as here's our loose plan. We know what we're going to do in the next sprint, but the other sprints are Mike (21:48) Right. Yep. Brian (22:17) more fluid and we'll adjust as we need to. Mike (22:20) Yeah, I've written so many times about a plan is not a commitment or commitment is not a guarantee, right? You know, I can make a commitment to this. I'm going to commit to do my best. We're going to commit to try to achieve these. But I love a Clint Eastwood quote, one of his movies. He said, if you want a guarantee, buy a toaster. Right. So. Those are the days when supposedly banks used to give you a toaster when you open a new account, right? That. Brian (22:25) Yeah, yeah. you can guarantee a toaster in today's world. Well, we joke in our family because my wife's grandparents have a, well, they're no longer with us, but they had a refrigerator that was from the 1950s that was sitting out in their barn that still worked perfectly. But we had, you know, our refrigerator is, you know, five years old and it's already breaking down and you have to consider replacing it. So, yeah, yeah. Mike (22:49) precede my day, but I... Wow. It's all the electronics in them, I think, right? So I want to move on to the sprint planning. So from the quarterly planning. So in sprint planning, you've got this broken out by what people do in the planning meeting daily during the sprint. So I want to start in the planning meeting. You're proposing a goal and work with developers to kind of improve that, answer questions about backlog items, and talk about your schedule as the product owner share your schedule. You want to elaborate on what you're thinking about with these sprint planning activities? Brian (23:15) Yeah, yeah. Yeah, I mean, so I think a goal is important for the sprint. I think that gets us all on the same page and it's kind of one of the teaming aspects of it. We want to all have our eyes on the prize of what it is we're trying to accomplish together so that we're not all just in different places working on different things. I think it's important that we're there in sprint planning to answering questions because that's when they come up. We're making our plan for when we're going to do something. So I think it's important that we're there to kind of help them plan how they're going to accomplish stuff. Mike (23:59) Yep. Brian (24:08) We're not telling them how to, but we're giving them the information they need to determine how. And then, you know, as far as our schedule is concerned, I think it's a great idea for a product owner in sprint planning to say, you know, here's the next two weeks of my calendar. Here's where I'm going to be out of the office these days. I'm going to be at a client site on these days, just so that people can prepare. If I'm a developer and I know I need to get approval from my product owner and I know they're going to be out for the next two days at a conference or something, well, that might... guide me in how I'm going to plan and arrange my work. Mike (24:38) Yep. Some of my favorite POs have been ones that have done something like said, look, between one and two o 'clock every day is total team time. I will never schedule a meeting. I'll always be available if you need me from one to two or one to three or eight to nine, whatever it is, but they'll have some sort of window there that is basically guaranteed access. Doesn't mean that's the only time they're available, but it's a guaranteed time, which is nice. I think it's nice. Brian (25:04) Yeah, I love that too. Mike (25:06) Talk to me about the daily scrums and what you'd expect out of a product owner during the daily standups. Brian (25:08) Ha ha ha. Yeah, daily scrums are kind of a controversial thing here for lots of reasons, but I mean, there's some who would say a product owner doesn't need to be at a daily scrum. I disagree. I think product owners do need to be there. I don't think they're required. Actually, if you want to ask me my opinion, the only people I think are required are the developers, because it's for them, it's by them. You can't have it if they're not there. If anyone else is not there, you can still have the meeting. Mike (25:14) Thank you. Brian (25:38) But the product owner, I think, is important to try to be at as many of these as they possibly can. Because just like in sprint planning, they're making a plan for what they're doing, here it's immediately before they're going to be doing this work. So it's the time when the rubber meets the road. And here's where they're going to have some real practical questions. And if you're not there to answer them, you could hold them up. You could delay them. Mike (26:04) Yeah. Brian (26:05) I also, like you said, I like to use this as an opportunity to say, here's when I'm available today. Mike (26:10) I wake that product owners attend because of the message it helps sends as well. If the PO never goes, is this project important, right? Or team members start to think, we have to show up daily and say what we did yesterday, that that person never has to do this, you know? And we started to get some resentment towards them. So I strongly encourage product owners to attend. I'm like you, that don't require, but my requirement test is always, would I cancel the meeting if this person had a dentist appointment, right? Brian (26:16) Yeah. Mike (26:41) If the product owner had a dentist appointment in the morning of planning, I'd probably say, can we do it in the afternoon? My product owner can't make the daily scrum because I've got a dentist appointment? well. We're still doing the daily scrum. But you're right. If all of the teams, this will be silly, but if all of the team members were all having dentist appointments, yeah, we'd cancel the meeting. There'd be no point. So. Brian (26:53) Right. Yeah, the Scrum Master and Product Owner can't have a daily scrum, just the two of them. Mike (27:07) What should we make them do? Let's talk about what to do during the sprint. You talked about kind of ongoing research. So you don't want to do all the research upfront on this. Brian (27:09) Right, exactly. Right, no, it's a continual thing, right? I mean, if I'm working on my product and my competitor comes out with a killer feature that's starting to gain traction, I can't do that research upfront. That's something that becomes apparent as the product kind of goes along. So I think it's important that we keep in touch with what's going on in the real world with our product and the competitors. Mike (27:43) Mm -hmm. through the marketing, through the market. The thing you had next here was about connecting with customers to hear feedback. I want to share a story on this one because it literally just happened. I told you I was out of the office. I got back like 15 minutes before we wanted to do this recording. And I'd been gone all morning, so I talked to my wife for about five minutes. And she and I had come across some software recently that we're using that looks kind of interesting. It's things like, you know, when you die, who gets access to your Facebook? Brian (27:57) Yeah. Mike (28:18) password, right? And most of my friends are pretty shifty. So I don't want to give my Facebook password now because they'd probably go post weird things. But I want you know, when I die, I want that to happen, right? And so we're looking at various software that does those things like who do you notify when after you died? Brian (28:19) Yeah. Mike (28:35) And we signed up with this company. I'm actually going to share the name because I like them so much here in a minute, but let me say why I like them. My wife and I both had interactions with them by email about totally different things. One was a little bug that I came across and then something that I think she was asking about how does the future work. But here's what I love. They contacted her today and said, can we get on the phone with you and hear what you think about our product? They're a fairly new company, I believe. what you think about our product and what you think about how we've, in particular, have like the three tiers of service that we offer, right? You know, this feature, this feature. And I just love that they're doing that, right? Because not as many companies do that as they should, right? As they should. Because I love that company, so I'm gonna mention their name, trustworthy .com. Probably nobody listening needs them, but they are just this kind of like, you know, I don't wanna say like death planning, because they're not like playing your funeral, but it's like. Brian (29:23) Hahaha. Mike (29:28) Who gets your Facebook account? What bank accounts do you have? So your heirs can figure it out. Right. So, so. Brian (29:34) Yeah, yeah, that's great. No, I love having that mission if they're, they have good customer service. Yeah, definitely. Let's, let's mention them. Mike (29:40) Yeah, and my wife and I favorably disposed of them, and that just put me over the top with them literally a half hour ago. You talk about checking in with the Scrum Master, about how you as a product owner are doing, but also staying in touch with devs. Brian (29:46) That's awesome. Yeah. Yeah, I mean, I think that it's important for us to understand that we are not somehow separate from the team. We are part of the team. So we have the same goal as everyone else, and that's to deliver as much value as we can to our customers. We have a specific role, a responsibility to play in that. But I think checking in, partly I put that on there because. checking with a scrum master. That's something that we have on our scrum master sheet is to check in with a product owner. And I do think that those two need to kind of work hand in hand over the course of a sprint. And on an ongoing basis, kind of touch base to see how are things on your end? How are things on my end? And how can we help each other to kind of achieve our goals here? Mike (30:24) Yeah. Yeah, you often notice something about somebody else before they may notice it themselves, right? We've got a couple other meetings that I'll move on to. So let's talk about refinement. Can you share what your thoughts are for a product owner's responsibilities during refinement? Brian (30:43) Mmm. Yeah. Yeah, I mean, refinement, I always hesitate to even think about it as a meeting because it's kind of more of a series of activities. And you might have multiple meetings that would need to take place here. But yeah, I think that there's a lot of prep work that goes into. If I'm going to have the stakeholders come in and help me prioritize, I've got to prep a lot of that work. I've got to have the stuff that's ready to go prior to that meeting. I can't just show up and go, let's see what we got in our backlog. And we'll just kind of wing it. Mike (31:02) Good point. if What do you think about this product owner? I don't know. Let me think now. Yeah. Did I write that one? Brian (31:21) Right. Right. I don't even know what that is. I don't know. Let me read it. Right. That's just going to waste everyone's time and frustrate people. So I think there's a lot of prep that goes into that and prepping to go into anything like estimation. Do we have the right sort of things that are going to be estimated? I don't want to waste my team's time estimating stuff that's maybe really a long way in the future. And I'm not going to look at it for a while. So, you know, I think there's a lot of prep time that goes into that. And I think that, you know, we're at the center, at the focal point of any kind of refinement activity. as a product owner. So that's going to be, I don't really know exactly how those meetings are going to play out for you, but I think that there is some configuration there that you got to plan for. Mike (32:02) I'm hearing your message. There is the old boy scout motto, be prepared, right? It's a new product owner motto, right? We'll, we'll steal it from the boy scouts. you have any, that's true. Just don't take away my Girl Scout cookies. So let's talk about the, the sprint review. what do you think a great product owner does then? Brian (32:06) Yes, yes. Yeah. Well, that's okay, because there's no more Boy Scouts. So you don't have to worry about that. Right. wow. So this is our event. I really think of this as the product owners event. Yeah, exactly. I think you're the emcee. I think you show up, you host it, you send out the invites for it. What I typically tell product owners is kick it off with kind of a look back at some things that have been done recently by the team. Here's some features that we developed in the past three to six sprints and maybe even show some statistics about the impact those things are making. Mike (32:30) you Showtime! Brian (32:56) on the product and the market, on the customers. Our customer satisfaction has gone from here to there as a result of releasing these features, those kinds of things. So I think that the meeting opens that way. Then we move into the demonstration of the work and what we've done in that sprint. And yes, I would turn that over in large part to the developers so that they can demonstrate. But then I think it circles back at the end to come back to the product owner to say, all right, let's take a peek ahead. Let's look ahead what's coming up in our product backlog. Here's what our... looking at as candidates for the next sprint. And I think that's really important. It gives the stakeholders a chance to speak up and say, hey, what about this thing that I had that was really important? I don't see that prioritized. I really need that in the next sprint. I want to have those conversations in advance, not after sprint planning, when it's sort of locked in. Yeah. Mike (33:45) Tell me about the retrospective. One of the things I noticed you had in there was that you want product owners to attend every retrospective. There's going to be pushback on that from some teams. What's your thought there? Brian (33:59) Yeah, my thought there is, again, kind of reiterating that point that we are on the team, we are a team member like anyone else. And again, we have different responsibilities. We have a named kind of set of accountabilities that we have that may differ from others. But I kind of consider it like this. If I'm on a, in the US, we'd say soccer team, but if I'm anywhere else in the world, I'd say football team. If I'm on that kind of a team and I'm the keeper, the goalkeeper. I've got a very unique role, right? I mean, there's a set of things I do that no one else does. I'm allowed to do things that nobody else is allowed to. I'm allowed to touch the ball with my hands. Nobody else is, right? But if there's a team meeting, you're not gonna have a team meeting without your goalkeeper. They're an important vital part of your team. And that's what this is. It's the team meeting to get together to say, how can we get better? How can we improve? What's going on? What's wrong? What's right? And what do we wanna focus on? Mike (34:36) Right. Yeah. Brian (34:58) So I think it's vital for a product owner to be at every one just because like I said, we're a team member. Mike (35:04) I agree. To me, it's always like, if you don't feel comfortable having your product owner at the retrospective, that's the first thing I want to talk about at the retrospective. Right? It would figure out why we're not comfortable with that so we can move past that. I do like here in the retrospective, you talked about having the product owner commit to making progress on the improvement items, which I think is important because sometimes it is product owners who have to improve. Right? So. Brian (35:31) Yeah. Yeah, I mean, one of the things we'll talk about in class is how the product owner is a vital communication relay point. They are the, I call them kind of the, it slipped my mind. What's the stone that had the different languages on it from Rosetta Stone, sorry. They're kind of the Rosetta Stone, right? Because they speak tech with the developers. They speak. Mike (35:36) Mm -hmm. Rosetta. Brian (35:57) business with the stakeholders and they translate across those two groups. So I think, yeah, I think it's important that we're there to try to, if there's communication issues with us and the developers, this is the place to work it out, right? This is the place to say, what do you need from me so that it's more clear the next time I write stories. Mike (36:02) Yep. Yeah, that's a good point. What about for the next sprint? What should product owners do this sprint to be ready for the next one? Brian (36:24) Yeah, excuse me. Yeah, I think it's important that we really get a handle on what should be prioritized, that we have a good understanding of what's going to be coming up, that we have that idea of what our next proposed sprint goal might be, where we're focused on stuff. And as I said, I want to check in with my stakeholders, especially my key stakeholders, on that prioritization so that it's not a surprise to anyone. I don't want to. I don't want anything to be a surprise when it gets to sprint planning. By the time we circle back around in sprint planning, I want my developers to have looked at these things multiple times before they see it in sprint planning. We've had estimations. We've had discussions about these. So there could have been multiple times we've had conversations about these. So by the time we get to sprint planning, it's not the first time we're looking at these things. Mike (37:00) Yeah. Yeah, it should be a surprise. Brian (37:15) And that's kind of what I'm trying to allude to here is that there's a series of activities that just are kind of the glue between one sprint to the next sprint. And if we kind of drop that ball in any way, like I said, I can't show up at sprint planning and sort of just say, well, let's see what we got, guys. I have no idea what we're going to do, but let's just take a look. Yeah, I can't wing it. Mike (37:30) Right. Yeah, wing it. Yeah, that's not a good approach for things. Brian, you told me a lot of things that product owners should do. I want to twist it a little bit and ask you for one thing product owners should not do before the sprint, during the sprint, before the project, whatever. What's one thing, the one thing you would tell product owners to not do? Brian (37:57) Wow, that's such a great question. I think probably the number one thing that I would say is to understand the boundary between the what and the how, and really to try to stay out of the how. What I mean by that is we're in charge as product owners of the what side of the equation. What is it that we're going to be doing? What are we focused on? The developers are in charge of the how. How do we accomplish this? What's the best way to deliver this? And I... I know as a product owner in my past, I've always struggled with that balance of, yeah, but I've got a vision in my head of exactly the way I want it to play out. And I have to kind of rein myself back in a little bit and say, yeah, but kind of remind yourself that that's not really my role here. My role is not to explain exactly how the page is going to need to look and exactly how this feature plays out. If I have no really discernible reason that I have to have it one way over another, right? If there's not like a legal reason or compliance that I've got to do it one way, then I want to as much as possible stay out of the house so that the developers really get to exert their expertise. Mike (38:59) Right. Yeah, that's where they're going to be, they're going to be best at. I was describing it as that there's, there is a fine line between what and how, which is why people often will struggle with it. the way I think about it is like every time we dip into that, how at all product owners dip into that at all, they start to kind of take away degrees of freedom from the team. The team has less maneuvering room on how they're going to solve the problem. And great, take away one degree of freedom here and there. It's not going to be the end of the world. Take away too many, and you over -constrained the solution. The team doesn't engage as fully. All sorts of negative things, as you've touched on. Brian (39:39) Yeah. Mike (39:40) Brian, I want to thank you for letting me take over and turn the tables on you and ask you the question. Since you had made the PDF, I wanted to be the one asking you what your thoughts were on your great PDF that we have for folks. So I'll turn it back over to you. Let it be back to your show now. Brian (39:41) Hahaha I... Yeah, no, well, thank you very much. This has been a pleasure. It's been really fun to have to see what it's like on the other side of the table a little bit. So thanks for being willing to do it, Mike, and thanks for being willing to share your insights as we walked through this.
In this episode of the Scrum.org Community Podcast, guest host Sabrina Love chats with PST Ravi Verma and Vinayak Joglekar, Founder Director at Rezoomex, a work marketplace platform. They dive into how an immersive training program transformed Rezoomex's product development by enhancing alignment and communication. The discussion highlights their collaborative effort to create an effective learning program that allowed the team to build a product while learning. They also stress the significance of continuous learning beyond the classroom.
In this episode Dave West and PST Sam Falco discuss the confusion surrounding Scrum Master job titles and Accountabilities, emphasizing the need to broaden one's perspective beyond the team level to understand the organization's strategic goals. They discuss the roles and accountabilities of Product Owners and Scrum Masters in agile development, highlighting the importance of a Product Owner with a clear vision for improvement and the ability to validate that vision through increments, as well as the Scrum Master's role in facilitating the Scrum framework and ensuring effective Product Ownership.
Mike Lyons: When Technical Knowledge is an Impediment to Great Product Ownership in Scrum Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Visionary Product Ownership, Leading with Passion and Purpose In this segment, Mike celebrates a Product Owner who exemplifies vision and passion, bringing humanity and customer focus into the product development process. He also shares how this approach enhances team empathy and product quality, and what lessons can other Product Owners take from this exemplary behavior. The Bad Product Owner: The Pitfalls of Technical Product Ownership In this segment, Mike discusses the challenges and pitfalls when technical expertise overshadows the true role of a Product Owner. What can go wrong when a former developer becomes a Product Owner, and how does disengagement from the role affect team dynamics? Unpack the essential qualities of vision, passion, and advocacy that every Product Owner should embody. [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Mike Lyons After reading the Agile Manifesto in 2006, Mike focused on making teams and organizations more adaptive and efficient. Despite facing failures and mistakes, these experiences provided him with valuable lessons that enhanced his ability to achieve tangible results with Agile. You can link with Mike Lyons on LinkedIn.
Join host Dave West in a conversation with Professional Scrum Trainer Ralph Jocham as they chat about the challenges and strategies of Product Ownership. Explore the concept of the "Product Management Vacuum" and discover how to bridge the gap between business strategy and product development. Ralph shares insights on the three V's - vision, value, and validation - and how they drive product success in an agile environment.
Richard Hundhausen helps software organizations and teams deliver better products by understanding and leveraging Azure DevOps and Scrum. He is a Professional Scrum Trainer, Professional Scrum Developer, author of Professional Scrum with Azure DevOps (MS Press), and co-creator of the Nexus Scaled Scrum framework. As a software developer and consultant with over 30 years of experience, he understands that software is built and delivered by people and not by processes or tools. Topics of Discussion: [3:03] Is it really that easy to teach developers? [3:34] Scrum implementation and best practices for developers and managers. [5:11] What is a Scrum trainer and developer? [6:40] Reminding teams to talk to each other and deliver value earlier. [6:47] Remembering not just the nouns, but the verbs: improve, collaborate, share, love the values, commit, have courage, be open, have focus, and be respectful. [8:39] The importance of having the right teams. [12:04] Improving software development efficiency through cross-functional teams. [13:47] The importance of being a self-managing team. [15:04] When we outsource everything to HR to find a good culture, that can perpetuate the “it's someone else's job” mentality. [15:24] Bigger companies vs. smaller companies. [17:44] Giving creatives the space to create. [21:09] HDD (Hypothesis-driven development) can help us learn early and adapt. [29:27] The importance of focusing on outcomes and impacts, rather than just measuring resources, activities, and outputs. [31:08] Outcomes and impacts are where we should be focused. [32:40] One percent of product owners using Scrum as intended? [33:27] Even if you don't have a product owner, have someone who orders the work. Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! Accentient Upgrade Your Team Daniel Pink Practicing Hypothesis-Driven Development in Azure DevOps “Richard Hundhausen on Professional Scrum — Ep 100” Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.
Drew Craig: From Dictator, to Collaboration Facilitator, Contrasting Agile Product Ownership stances Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Seniority, Engagement, and Presence, Characteristics Of Standout PO's In this episode, Drew talks about an exemplary Product Owner who embodied seniority and dedication in their role. The standout PO was fully invested, engaged, and present, consistently participating in team discussions. Encouraging problem-solving autonomy, the PO crafted a visionary "what," and allowed teams to contribute the "how." Only intervening when necessary, this PO fostered an environment where teams could excel. The Bad Product Owner: Insights on Overcoming Dictatorial PO Patterns In this episode, Drew addresses Product Owner anti-patterns, recounting a scenario where a dictatorial PO hindered team collaboration. The PO struggled to create cohesion and dismissed ideas from contractors. Using a retrospective, Drew facilitated an open conversation, emphasizing the importance of helping the PO understand the consequences of their actions. Tips include doing a "reset" to redefine team dynamics and ensuring leadership comprehends Agile principles. Drew advocates for objective thinking as Scrum Masters, fostering empathy for PO challenges and encouraging open dialogue with POs about their influences. [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Drew Craig Drew calls himself an Agile Coach for humans; inspiring growth for individuals, teams, and systems to be better together. In all of his roles, the connection has been the people. He is passionate about establishing sustainable and simple processes, techniques, or insights as mechanisms toward self-sufficient and empowered systems. You can link with Drew Craig on LinkedIn and connect with Drew Craig on Twitter.
Ever wondered how visuals can transform your role as a product owner? Join Brian as he sits down with visual storyteller Stuart Young to unravel the power of visualization in product ownership. Join them on a journey to discover the art and science behind being a successful product owner. Overview Ever wondered how to elevate your product ownership game? In this episode, we delve into the world of visual storytelling with Stuart Young. Join Brian and Stuart as they discuss the diverse tools, such as story mapping and the product disposition canvas, that can bring your product visions to life. From storytelling techniques to the neurodiversity lens, we explore the art and science of communication that transcends traditional boundaries. Listen in to uncover the impactful ways visuals can shape your product strategy. Learn how being more visual can sharpen your skills, foster collaboration, and create a more inclusive and successful product development journey. Listen Now to Discover: [00:23] - Today welcomes Stuart Young, a Certified Scrum Trainer and visual storyteller to discuss storytelling through the product lens and more. [03:32] - Stuart discusses drawing large-scale pictures at conferences and recommends Visual Meetings and Visual Leaders by David Sibbit. [06:54] - Stuart emphasizes the impact of visual storytelling on individuals, highlighting the universal language and information retention through visuals. [08:46] - The benefits of visual representation in capturing the flow of ideas and aiding memory. [10:26] - The importance of varied methods for engaging different learning styles. [11:41] - Stuart discusses the value of visualization tools such as roadmaps, post-it notes, and story mapping to provide clarity and a clear narrative. [12:14] - The importance of blending Stuart references Pixar and Ed Catmull's book Creativity, Inc., discussing the importance of blending exciting elements, like storyboarding, in motivating teams and creating a compelling narrative. [15:13] - Stuart emphasizes the importance of authentic storytelling, even if it doesn't always have a happy ending, he references TEDxHogeschoolUtrecht - Steve Denning - “Leadership Storytelling" for further inspiration. [15:25] - Brian recommends Simon Sinek's TED talk on "Start With Why" as an example of effective storytelling despite not being visually polished. [16:09] - Stuart praises Henrik Kniberg's impactful video on product ownership, acknowledging the simplicity of the drawings but highlighting the potency of storytelling. He recommends the Sketchnote Handbook by Mike Rhodes for those interested in delving further into storytelling. [17:08] - The Agile Mentors Podcast is brought to you by Mountain Goat Software and their Certified Scrum Training Classes. For more information, click on the Mountain Goat Software Certified Scrum and Agile Training Schedule. [18:38] - Stuart highlights the significance of visual elements in crafting compelling visions and underscores the value of utilizing available templates, from sources like the Gamestorming book. [20:06] - Stuart discusses the role of visualization in making the intangible tangible, particularly in the tech space. [21:50] - Brian emphasizes the imprecision of words. He also discusses the value of showing rather than just telling, especially in product requirements, to enhance understanding and avoid delays caused by miscommunications. [23:34] - Stuart reflects on how visual communication can enhance inclusivity. He shares, “For people with reading and writing difficulties, pictures and symbols are better. The worst, the most abstract form, of course, is the word.” [25:22] - The role of a visual storyteller as a "human cursor" connecting diverse conceptual thinkers. Stuart recounts an illustration experience, emphasizing the challenge of visualizing details without clear specifications and underscoring the mantra of "process over art" in product ownership. [28:06] - Stuart underscores the product owner's role in leveraging the unique skills of team members to converge on a shared understanding of what "good" looks like. [29:19] - Brian references the episode of the show they did on Navigating Neurodiversity and the importance of understanding and accommodating different communication styles within a team. He highlights the need for product owners to be aware of the preferences of their team members and adjust communication methods accordingly. [30:54] - Stuart introduces the product disposition canvas and shares a personal revelation. [32:54] - Brian acknowledges the potential superpowers that come with neurodiversity, sharing his own experience of a late-in-life ADHD diagnosis and the benefits of leveraging the unique qualities each team member brings to a team. [33:36] - Stuart reflects on the importance of recognizing individual strengths and blind spots, emphasizing that everyone has a valuable contribution. [34:20] - Stuart encourages recognizing individual strengths for collective success. [35:23] - Listeners can connect with Stuart on LinkedIn and at Agile Nuggets | Agile Tips [37:38] - Please share this episode with others if you found it useful. Send feedback and suggestions for future episodes to podcast@mountaingoatsoftware.com. And don’t forget to subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode. [38:21] - If this topic was impactful to you and you want to continue the discussion, join the Agile Mentors Community where we have a topic discussion for each podcast episode. You can get a free year-long membership in the community just by taking any class with Mountain Goat Software. References and resources mentioned in the show: Stuart Young on LinkedIn Agile Nuggets | Agile Tips | Cprime Learning Scrum in Under 10 Minutes #76: Navigating Neurodiversity for High-Performing Teams with Susan Fitzell David Sibbet Visual Meetings by David Sibbet Visual Leaders by David Sibbet Creativity, Inc. Sketchnote Handbook by Mike Rohde TEDxHogeschoolUtrecht - Steve Denning - “Leadership Storytelling" Simon Sinek: How Great Leaders Inspire Action | TED Talk Agile Product Ownership in a Nutshell by Henrik Kniberg Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers Subscribe to the Agile Mentors Podcast on Apple Podcasts Certified ScrumMaster Training and Scrum Certification Certified Scrum Product Owner Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Stuart Young, a Certified Scrum Trainer and Visual Storyteller, merges Agile methodologies and design thinking to empower individuals and teams. As a thought leader, he champions Visual Storytelling for engaging stakeholders, addressing customer needs, and expediting learning. Through workshops, Stuart encourages teams to embrace visual methodologies to achieve business success.
Robert Briese: Beyond Requirements, Rethinking Agile Product Ownership Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Impact Mapping And Other Tools Great POs Use To Focus On Outcomes In this episode, Robert discusses the attributes of a great Product Owner based on an energy company's experience. The exemplary PO managed a budget, aimed to introduce new products, and emphasized impactful market presence. The PO's coachability and commitment to improvement are highlighted, along with insights from Marty Cagan's "Inspired." A great PO, as outlined, prioritizes impact over outputs, maintains clarity on product goals and business vision, and employs tools like Impact Mapping for outcome-focused development. The Bad Product Owner: Beyond Requirements, Rethinking Agile Product Ownership In this episode, Robert identifies Product Owner (PO) anti-patterns, emphasizing that many POs don't truly own a product. A common pitfall is when POs isolate themselves, detailing requirements independently and presenting them to the team for feedback. This approach creates a significant gap between development teams and POs, limiting the focus to "delivering requirements." The episode recommends a shift in approach, encouraging POs to step away from detailed isolation and instead bring direct customer/end-user information to development teams. [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Robert Briese Robert Briese, is an Agile Coach who's seen it all. From startup stumbles to orchestrating massive Large-Scale Scrum feats, like BMW's level 3 autonomous driving milestone. He's on a mission to simplify the complex and help teams build adaptable, sustainable organizations. Buckle up for a wild, Agile ride with Robert! You can link with Robert Briese on LinkedIn and connect with Robert Briese on Twitter.
Jean Coetzee: Breaking Free from the Proxy Trap And Reclaiming the Essence of the Product Owner Role Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Breaking Free from the Proxy Trap And Reclaiming the Essence of the Product Owner Role In this episode, Jean addresses some anti-patterns in the role of a Product Owner, with the most detrimental being when they become mere proxies for business owners or sponsors. He laments the recent disregard for the essence of the PO role, emphasizing that it should not serve as a mere intermediary. When POs are placed in proxy positions, they are set up for failure, relegated to the role of translators rather than empowered owners. Jean advocates for a reevaluation of the PO role to ensure they have the autonomy and authority necessary for success. The Bad Product Owner: Empowering Teams, Lessons from an Exceptional Product Owner In this episode, Jean shares a compelling story of a Product Owner who excelled without formal training in Agile or Product Ownership. This PO approached the role with a fresh perspective, free from preconceived notions. They embodied true ownership of the product, prioritizing vision-setting and supporting the team's end goal. The distinction between ownership and management was evident, as the PO focused on protecting the team from interference while also holding them accountable. Importantly, this Product Owner struck a balance by empowering the team to take ownership of their purpose, ultimately leading to a highly successful and self-sufficient team. [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Jean Coetzee Jean is passionate about humans, and how they work together from a psychology and neuroscience perspective. Jean, credits the early ScrumMaster podcasts for shaping his Agile career. These insightful episodes provided vital guidance during the early days, boosting confidence in serving others effectively. Jean learned to navigate uncertainties and gain confidence in their Scrum Master role, all thanks to this and other podcast contributors. You can link with Jean Coetze on LinkedIn.
© 2020-2025 Ivy Podcast Discovery LLC
