<?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 management | Scrum Agile Project Management Expert</title>
	<atom:link href="https://www.scrumexpert.com/tag/product-management/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 management | 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>
					<comments>https://www.scrumexpert.com/knowledge/building-the-right-product-vs-building-the-product-right/#respond</comments>
		
		<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>
		
					<wfw:commentRss>https://www.scrumexpert.com/knowledge/building-the-right-product-vs-building-the-product-right/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</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>MVP: Why We Confuse Building to Learn with Building to Earn</title>
		<link>https://www.scrumexpert.com/videos/mvp-why-we-confuse-building-to-learn-with-building-to-earn/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Thu, 04 Sep 2025 16:59:22 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[delivering value]]></category>
		<category><![CDATA[product management]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=8429</guid>

					<description><![CDATA[Minimum viable product (MVP) is one of the most misunderstood, misused, and abused terms in contemporary software development. In this presentation Jeff Patton explains the misunderstandings made by thought leaders that lead to confusion we all deal with today. You will learn the counter-intuitive concepts hidden in the MVP term and why really using them is so hard. You will discover techniques that will ultimately help you find smaller successful releases, test your ideas faster, develop higher quality software more predictably, and release more confidently than ever before. Because hidden in this nasty little term are clues that can help you do all that. Video producer: https://yowcon.com/]]></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>MVP Testing: How to Validate Your Product Idea Quickly and Effectively</title>
		<link>https://www.scrumexpert.com/knowledge/mvp-testing-how-to-validate-your-product-idea-quickly-and-effectively/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Fri, 01 Mar 2024 15:19:01 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[product management]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7788</guid>

					<description><![CDATA[MVP or minimum viable product is a test of a hypothesis about the value of a product to the user. MVP allows you to quickly and cost-effectively test an idea to see if the market needs such a product. MVP testing is extremely important for startups and companies that want to release an innovative product. According to statistics, about 80% of startups fail because they don&#8217;t test their ideas enough. In this article, we will take a closer look at what MVP testing is, why it is important, and how to plan and execute it properly. We will also look at how to analyze the results and apply them to further product development. By following the advice in this guide, you will be able to quickly test the viability of your idea and save time and money on the full development of an unclaimed product. What is MVP Testing and Why is it Important? MVP testing is the process of validating a product idea by creating a minimum viable product (MVP) and testing it with real users. The goal is to gather feedback and data to determine if the product solves a real problem and provides value to customers before investing significant time and money in full development. An MVP is a stripped-down version of a product with just enough core functionality to be usable by early adopters. For a mobile app, it might be basic workflows and a minimal UI. For a physical product, it could be a prototype. <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/mvp-testing-how-to-validate-your-product-idea-quickly-and-effectively/" title="MVP Testing: How to Validate Your Product Idea Quickly and Effectively">[...]</a>]]></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>Practical Guidance for a Project to Product Transformation</title>
		<link>https://www.scrumexpert.com/videos/practical-guidance-for-a-project-to-product-transformation/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Wed, 15 Jun 2022 15:19:47 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Videos]]></category>
		<category><![CDATA[product management]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=7094</guid>

					<description><![CDATA[Ross Clanton and Amy Walters walk through an enterprise playbook, tactics, and case studies for how to successfully transform from a project to product based operating model. The target audience for this paper is leaders at any level of the enterprise who are driving a transition to a product-centric model. Transformations that shift from project to product require changes at every level and in every corner of the enterprise. To gather information that is both relevant and that has been proven successful, Ross Clanton and Amy Walters interviewed industry thought leaders across fourteen large enterprises who successfully drove product and technology transformations. These leaders had amazing insights from their successes and failures in moving organizations from project to product at scale. The companies assessed span the following industries: retail, banking, airline, telecommunications, apparel, accessories, sports equipment, financial services, insurance, technology, food and beverage, and medical software. Video producer: https://itrevolution.com/]]></description>
		
		
		
			</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>
		<item>
		<title>Seven Reasons To Build MVP For Your Business</title>
		<link>https://www.scrumexpert.com/knowledge/seven-reasons-to-build-mvp-for-your-business/</link>
		
		<dc:creator><![CDATA[scrumexpert]]></dc:creator>
		<pubDate>Mon, 13 Dec 2021 12:31:52 +0000</pubDate>
				<category><![CDATA[Agile & Scrum Articles]]></category>
		<category><![CDATA[Knowledge]]></category>
		<category><![CDATA[product management]]></category>
		<category><![CDATA[product owner]]></category>
		<category><![CDATA[white papers]]></category>
		<guid isPermaLink="false">https://www.scrumexpert.com/?p=6843</guid>

					<description><![CDATA[The Minimum Viable Product (MVP) is an approach that aims to avoid building products that customers don&#8217;t need or want by maximizing your learning about what is valuable for them. In this article, Sergej Hermoni shares seven reasons why you should include building an MVP in your Agile approach. Author: Sergej Hermoni, Impltech What is MVP? The minimum viable product (MVP) is a concise product that can be created based on a value proposition. This is the earliest version of a product which requires a minimum of possible characteristics, specifications, or functionalities, which gives us a chance to demonstrate the value of the idea the way it covers the needs of a targeted audience. The MVP gives an idea of how the final product will look like. There are two approaches that can be used when developing a MVP: validating MVP and invalidating MVP. The validating MVP uses a product that has a worse quality than the final product to test the market, while the invalidating MVP is an improved product, which exceeds the final product. The invalidating MVP is almost always the best approach to use. Seven Reasons To Build MVP For Your Business To save time and money Planning is a major factor in the success of any business and it helps to save time and money. No one wants that business fails. The MVP stands as a checkmate as even a failure at this stage does not mean the whole idea will crash. It only gives you a <a class="mh-excerpt-more" href="https://www.scrumexpert.com/knowledge/seven-reasons-to-build-mvp-for-your-business/" title="Seven Reasons To Build MVP For Your Business">[...]</a>]]></description>
		
		
		
			</item>
	</channel>
</rss>
