<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>product owner | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/tag/product-owner/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com</link>
	<description></description>
	<lastBuildDate>Thu, 01 Oct 2026 12:40:41 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	

<image>
	<url>https://www.scrumexpert.com/wp-content/uploads/favicon.png</url>
	<title>product owner | Scrum Agile Project Management Expert</title>
	<link>https://www.scrumexpert.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Building the Right Product vs Building the Product Right</title>
		<link>https://www.scrumexpert.com/knowledge/building-the-right-product-vs-building-the-product-right/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Fri, 28 Aug 2026 20:47:23 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[product management]]></category>
		<category><![CDATA[product owner]]></category>
		<category><![CDATA[requirements]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8834</guid>

					<description><![CDATA[In his book &#8220;Specification by Example &#8211; How successful teams deliver the right software&#8221;, Gojko Adzic had some interesting quotes about building the right product. &#8220;In the last decade, the software development community has strived to build software the “right” way, focusing on technical practices and ideas to ensure high-quality results. But building the product right and building the right product are two different things. We need to do both in order to succeed. To build the right product effectively, software development practices have to provide the following: * Assurance that all stakeholders and delivery team members understand what needs to be delivered in the same way. * Precise specifications so delivery teams avoid wasteful rework caused by ambiguities and functional gaps. * An objective means to measure when a piece of work is complete. * Documentation to facilitate change, in terms of both software features and team structure.&#8221; Source: &#8220;Specification by Example &#8211; How successful teams deliver the right software&#8221;, Gojko Adzic, Manning This idea of &#8220;building the right&#8221; product is also the center of the &#8220;Software Testing is Dead&#8221; presentation made by Alberto Savoia at the Google Test Automation Conference 2011.  I strongly agree that you cannot have a successful project without good requirements (which mean also good domain experts and product owners). We should however not forget that the right product would not be used if it is not working right. Keeping also the focus on building quality into the application is mandatory. You must do both, <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/building-the-right-product-vs-building-the-product-right/" title="Building the Right Product vs Building the Product Right">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>The Product Owner Triangle of Tension: Wants, Needs &#038; Feasibility</title>
		<link>https://www.scrumexpert.com/videos/the-product-owner-triangle-of-tension-wants-needs-feasibility/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Thu, 13 Aug 2026 15:55:39 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[feature1]]></category>
		<category><![CDATA[product management]]></category>
		<category><![CDATA[product owner]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8830</guid>

					<description><![CDATA[How do you manage the inevitable tension between what stakeholders want, what is needed, and what’s feasible? As Product Managers or Product Owners, we constantly navigate this &#8216;Triangle of Tension,&#8217; balancing human dynamics with practical constraints. The Triangle of Tension isn’t a problem to solve, it’s a dynamic to embrace. Success lies in navigating it with clarity, boldness, and empathy. As more organizations adopt Agile product practices, expectation management becomes increasingly critical. Misalignment between stakeholders and Scrum teams can stall progress and erode trust. This talk offers practical advice for transforming that tension into a force for collaboration and delivery, equipping Product Owners or Product Managers to approach these challenges with confidence. Drawing on 15 years of experience, including a recent case study with a charity client, the presenter shares her mistakes, lessons learned and actionable strategies for managing expectations, fostering trust, and aligning your Agile teams for success. Video producer: https://www.agileonthebeach.co.uk/]]></description>
		
		
		
			</item>
		<item>
		<title>Learning in Product: How Wrong are You Ready to Be?</title>
		<link>https://www.scrumexpert.com/videos/learning-in-product-how-wrong-are-you-ready-to-be/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 31 Mar 2025 16:46:48 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[product management]]></category>
		<category><![CDATA[product owner]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8289</guid>

					<description><![CDATA[While many Scrum teams talk proudly about progress, fewer engage in rich discussions about product. Many teams who become more confident in progress, or getting work done, often embrace the more ambiguous question of product, or “Are we meeting the needs of our customers”, with some customers buying, by paying for subscriptions, and others buying in, by showing (and glowing about) their use of the system. This presentation shares experiences helping companies and Scrum teams adopt a customer and product / services approach. From small digital product companies to large enterprises who are IT focused, it presents an approach for moving to or augmenting an existing move towards impact driven work. Topics that will be covered include: * mapping teams to products and services * early product discovery * blending product discovery and product delivery * ideas for doing these things at scale. Video producer: https://yowcon.com/]]></description>
		
		
		
			</item>
		<item>
		<title>The Product Confidence Trap for Agile Teams</title>
		<link>https://www.scrumexpert.com/videos/the-product-confidence-trap-for-agile-teams/</link>
					<comments>https://www.scrumexpert.com/videos/the-product-confidence-trap-for-agile-teams/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 20 Feb 2024 15:30:08 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[product management]]></category>
		<category><![CDATA[product owner]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7779</guid>

					<description><![CDATA[This presentation to provides a framework with which Agile teams can assess their product context, grow confidence in the insight they have developed, and decide on their next best option to deliver customer value. This is the pattern to follow to help break out of the ‘Product Confidence Trap’. Design Thinking and Product Discovery practices can help Scrum teams to learn more about product strategy, our customer opportunities, the potential solutions, and how they might deliver customer value. This is a non-linear flow that helps increase confidence in the chosen direction of travel for product management. The ‘Product Confidence Trap’ is the mental loop in which we can get stuck when we are looking to confirm that we have increased confidence enough to move forwards, but when we are unsure that we have enough insight. It is often hard to assess if and when we can move on based on the level of risk we are willing to take. During this talk we discuss the different phases of Product Discovery, how we might increase confidence during these phases, and how we might make weighted decisions to move forwards : * Strategy &#8211; How might we assess we have shaped the vision enough? * Opportunity &#8211; How might we decide we have explored the customer&#8217;s needs correctly? * Solution &#8211; How might we know we have designed the appropriate solutions? * Delivery &#8211; How might we be confident we have decided on the correct way to deliver? https://vimeo.com/847864276 Video producer: https://aceconf.com/]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/videos/the-product-confidence-trap-for-agile-teams/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>Five Mistakes to Avoid When You Select Product Metrics</title>
		<link>https://www.scrumexpert.com/videos/five-mistakes-to-avoid-when-you-select-product-metrics/</link>
					<comments>https://www.scrumexpert.com/videos/five-mistakes-to-avoid-when-you-select-product-metrics/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 27 Nov 2023 17:17:20 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[metrics Agile]]></category>
		<category><![CDATA[product management]]></category>
		<category><![CDATA[product owner]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7711</guid>

					<description><![CDATA[Product metrics and key performance indicator(KPIs) have been getting increasingly more important and useful for Agile organizations that develop digital products. When done right, they can become an engine for product growth and inform great strategic and tactical decisions. When done wrong, they can lead to a huge amount of sunk resources and wasted time. This presentation explains the most common and the most dangerous mistakes that you should avoid to make sure your KPIs and metrics work to your advantage. You will learn to: * recognize the most typical problems with metrics in everyday work with your product * identify behaviors that lead to problems with metrics * prevent situations where a serious error is made when selecting product metrics https://vimeo.com/843391054 Video producer: https://aceconf.com/]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/videos/five-mistakes-to-avoid-when-you-select-product-metrics/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>Tips for Effectively Applying the Product Owner Role</title>
		<link>https://www.scrumexpert.com/videos/tips-for-effectively-applying-the-product-owner-role/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 17 Jul 2023 16:44:25 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[product owner]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7573</guid>

					<description><![CDATA[This presentation offers tips to successfully apply the product owner role. It distinguishes different product owner flavors, explains hope the Scrum product owner role differs from the SAFe one, and how product ownership can be scaled. Video producer: https://agilebyexample.com/]]></description>
		
		
		
			</item>
		<item>
		<title>Every Product Owner is Different</title>
		<link>https://www.scrumexpert.com/knowledge/every-product-owner-is-different/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Fri, 12 May 2023 14:15:10 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Quotes]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[product owner]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7488</guid>

					<description><![CDATA[Every Product Owner is different. Every Product Owner needs to work out what is right the right way for them to fill the Product Owner role. Every organization is different. Every team is different, and every individual is different. For a newly appointed Product Owner, the first job is to sit down and decide what type of Product Owner they will be. Both what the organization expects of them and what type of Product Owner they want to be. For example: They may be a Backlog Administrator taking instructions from others, structuring and filtering the backlog, working effectively with the team, and burning down the backlog. They may be a Subject Matter Expert using expert knowledge of the domain to decide what the right product to build is, then helping team members understand the details of what is being built. Some Product Owners will work like Business Analysts. They will analyze internal process and business lines, meet with stakeholders, and balance competing internal requests. Frequently they will work as proxy customers. Others Product Owners will need to get out on the road. They will meet with customers—and potential customers. They will study their market and seek out opportunities using the skills of Product Management. All Product Owners will need to call on skills from other fields too: Project Management, Consulting, and Entrepreneurship, to name a few. Every organization will — rightly or wrongly — expect different things from the people it anoints Product Owner. Source: The Art of Agile Product <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/every-product-owner-is-different/" title="Every Product Owner is Different">[...]</a>]]></description>
		
		
		
			</item>
		<item>
		<title>How to Recognize a True Product Owner</title>
		<link>https://www.scrumexpert.com/videos/how-to-recognize-a-true-product-owner/</link>
					<comments>https://www.scrumexpert.com/videos/how-to-recognize-a-true-product-owner/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Tue, 14 Mar 2023 14:07:47 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[product owner]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7438</guid>

					<description><![CDATA[There are many examples of fake Product Owners (PO) in the companies (PO as Business Analyst, PO as Project Manager, Proxy PO). Companies cause this by using many organisational design antipatterns (assign one PO per team, &#8220;Product&#8221; being in fact a component, using committee for product decisions instead of one person). Sometimes these antipatterns are hard to see because they are hidden in the history and organization layers of the company. Are there any clear indicators that tell us that a person is a true Product Owner in the Scrum and LeSS sense? The presenter thinks yes and emphasizes them in the talk. For example: &#8211; a true PO can kill the product &#8211; a true PO doesn&#8217;t need to prepare status reports &#8211; a true PO spends more time talking to customers than to teams Video producer: https://less.works/ Further reading: How To Hire Scrum Product Owners]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/videos/how-to-recognize-a-true-product-owner/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>Mission Impossible: The Scrum Product Owner</title>
		<link>https://www.scrumexpert.com/videos/mission-impossible-the-scrum-product-owner/</link>
					<comments>https://www.scrumexpert.com/videos/mission-impossible-the-scrum-product-owner/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Thu, 14 Jul 2022 13:52:36 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[product owner]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7123</guid>

					<description><![CDATA[Does Scrum ask too much of product owners? Is the role set up to fail? In this presentation, Allan Kelly looks at some of the problems Product Owners face&#8230; and tries to make some useful suggestions. Have you ever worked with an excellent product owner? One who had enough time to be with the team, visit customers, analyze the market, talk to UXD, marketing and upper management? Worked at a sustainable pace and still had time for their kids? A product owner who could tell the team what to do without impinging their autonomy? A product owner who could write user stories and roadmaps, do story and impact mapping, define the details of acceptance criteria and the big picture of product strategy? One who can design experiments and MVPs, refine the backlog, set priorities, understand a CfD, calculate weighted lead time, cost of delay and still tell you when it will be done? Video producer: https://www.agileonthebeach.co.uk/ You will find more ideas of Allan Kelly about the product owner in his book The Art of Agile Product Ownership]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/videos/mission-impossible-the-scrum-product-owner/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
		<item>
		<title>5 Tips to Improve Product Backlog Refinement</title>
		<link>https://www.scrumexpert.com/knowledge/5-tips-to-improve-product-backlog-refinement/</link>
					<comments>https://www.scrumexpert.com/knowledge/5-tips-to-improve-product-backlog-refinement/#comments</comments>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 07 Mar 2022 16:09:23 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[product backlog]]></category>
		<category><![CDATA[product management]]></category>
		<category><![CDATA[product owner]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6953</guid>

					<description><![CDATA[The Product Backlog Refinement (PBR) activity is one that many new Scrum teams struggle with. Insufficient PBR often results in long sprint planning meetings and incomplete backlog items at the end of the sprint. This article provides some tips on how to improve backlog refinement, which in the past was called backlog grooming. Author: Anthony Mersino, Vitality Chicago, https://vitalitychicago.com/ Backlog refinement is the process of discussing, breaking down, gathering details, and estimating backlog item. The focus is on what is needed and why, rather than on how to solve the business need. Backlog refinement is done in the current sprint, for future backlog items, not for those backlog items that are in the current sprint. Participants in the backlog refinement process include the entire development team, appropriate subject matter experts (SMEs), the product owner or requestor for the item, and possibly the Scrum Master. Others may attend but those are the main actors. Why Product Backlog Refinement is Important Product Backlog Refinement or PBR is not only important, but it is also critical for Scrum Teams. The refinement, or grooming as it used to be called, helps align the team on the details of the backlog item. It leverages the insights from all team members to add necessary details to the backlog item. And it should involve a discussion with the product owner, customer or requestor so that the team can gather all the details about the requested item and why it is needed. Good backlog refinement processes will reduce <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/5-tips-to-improve-product-backlog-refinement/" title="5 Tips to Improve Product Backlog Refinement">[...]</a>]]></description>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/5-tips-to-improve-product-backlog-refinement/feed/</wfw:commentRss>
			<slash:comments>1</slash:comments>
		
		
			</item>
	</channel>
</rss>
