# Roman Pichler > Expert Training & Consulting in Product Management ## Pages - [Coaching](https://www.romanpichler.com/coaching/) - [test](https://www.romanpichler.com/?page_id=27822) - [Cookie Policy](https://www.romanpichler.com/cookie-policy/): Please wait while the policy is loaded. If it does not load, please click here. - [Tools](https://www.romanpichler.com/tools-2/): Templates - [Podcast Interviews with Roman](https://www.romanpichler.com/podcast/interviews-with-roman/): In addition to hosting his own podcast, Roman regularly joins others for discussions about product management. Below are a selection... - [Essential Articles](https://www.romanpichler.com/essential-articles/): This page provides you with quick access to some of the key articles Roman has written. They are grouped into... - [Product Owner MasterClass](https://www.romanpichler.com/training-courses/product-owner-masterclass-course/) - [Roman's Product Management Framework](https://www.romanpichler.com/tools/romans-product-management-framework/) - [GO Product Roadmap](https://www.romanpichler.com/tools/the-go-product-roadmap/) - [The Decision Making Chart](https://www.romanpichler.com/tools/the-descision-making-chart/) - [The Product Canvas](https://www.romanpichler.com/tools/the-product-canvas/) - [The Official Product Vision Board](https://www.romanpichler.com/tools/product-vision-board/) - [The Sprint Goal Template](https://www.romanpichler.com/tools/the-sprint-goal-template/) - [The Persona Template](https://www.romanpichler.com/the-persona-template/) - [Agile Product Management with Scrum](https://www.romanpichler.com/romans-books/agile-product-management-with-scrum/): Creating Products that Customers Love Agile Product Management with Scrum explains how product owners can create successful products with Scrum. The... - [How to Lead in Product Management](https://www.romanpichler.com/romans-books/how-to-lead-in-product-management/): Practices to Align Stakeholders, Guide Development Teams, and Create Value Together Reading this book will help you become a better... - [Scrum](https://www.romanpichler.com/romans-books/scrum/): Applying Agile Project Management Successfully Roman’s first book, published in December 2007, provides a comprehensive yet concise guide to applying... - [Strategize, 2nd Edition](https://www.romanpichler.com/romans-books/strategize/): Product Strategy and Product Roadmap Practices for the Digital Age AI is transforming how digital products are conceived, built, and... - [Roman's Product Management Vlog](https://www.romanpichler.com/romans-vlog/): A Can I pass on my ticket to someone else? You can transfer your ticket to another person if you... - [Roman's Product Management Podcast](https://www.romanpichler.com/podcast/): A Can I pass on my ticket to someone else? You can transfer your ticket to another person if you... - [Coaching, In-house Talks & Workshops](https://www.romanpichler.com/consulting-and-coaching/): Coaching Programs Roman offers tailored coaching and consulting to help product leaders and their teams develop winning strategies, foster effective... - [Roman Pichler's Product Owner Master Class](https://www.romanpichler.com/roman-pichlers-product-owner-masterclass-thank-you/): A Can I pass on my ticket to someone else? You can transfer your ticket to another person if you... - [Company-internal Talks](https://www.romanpichler.com/talks/): Invite Roman to speak at your next conference, corporate event, or internal product summit. As an internationally recognised authority on... - [](https://www.romanpichler.com/privacy-policy/): Please wait while the policy is loaded. If it does not load, please click here. - [Sitemap](https://www.romanpichler.com/sitemap/): A Can I pass on my ticket to someone else? You can transfer your ticket to another person if you... - [Workflow Inbox](https://www.romanpichler.com/workflow-inbox/): Workflow Inbox - [Product Strategy & Roadmap](https://www.romanpichler.com/training-courses/product-strategy-roadmap/) - [Product Leadership Workshop](https://www.romanpichler.com/training-courses/product-leadership/) - [Workshops](https://www.romanpichler.com/training-courses/) - [Roman Pichler's Product Management Blog](https://www.romanpichler.com/blog/): A Can I pass on my ticket to someone else? You can transfer your ticket to another person if you... - [Tools](https://www.romanpichler.com/tools/) - [Get in touch](https://www.romanpichler.com/contact/): We love to hear from you, answer your questions, and discuss how we can help you! To contact Roman, please... - [Roman's Books](https://www.romanpichler.com/romans-books/): A Can I pass on my ticket to someone else? You can transfer your ticket to another person if you... - [About Roman](https://www.romanpichler.com/about-roman/): Roman Pichler is an internationally recognised product management expert, author, and keynote speaker and a trusted advisor and coach. For... - [Expert Consulting and Coaching for Product Leaders and Product Teams](https://www.romanpichler.com/) ## Posts - [How to Create a Truly Inspiring Product Vision](https://www.romanpichler.com/blog/how-to-create-an-inspiring-product-vision/): “If you are working on something exciting that you really care about, you don’t have to be pushed. The vision... - [Emotional Intelligence for Product Managers: The Critical Capability AI Can't Replicate](https://www.romanpichler.com/blog/emotional-intelligence-in-product-management/): As product management becomes increasingly data-driven and AI-powered, one human capability is growing in importance: emotional intelligence. In this article,... - [The Product Strategy Framework: A Revised Guide for Product Leaders](https://www.romanpichler.com/blog/romans-product-strategy-framework-v3/): One of the biggest mistakes I see product managers make is making decisions in isolation: Deciding on strategy without considering... - [Should Product Managers be Product Builders?](https://www.romanpichler.com/blog/product-managers-product-builders/): Is it a good thing when product managers are hands-on and use AI to build prototypes and generate code? Will... - [Get the Outcomes on Your Product Roadmap Right](https://www.romanpichler.com/blog/get-the-outcomes-on-your-product-roadmap-right/): Product outcomes define the specific value a product creates—for users, customers, and the business. When applied correctly, they align stakeholders,... - [Succeeding with the Product Operating Model](https://www.romanpichler.com/blog/succeeding-with-the-product-operating-model/): This article explains how you can successfully implement the product operating model—based on my experience of helping companies introduce and... - [How to Build a Strategy for an Existing Product](https://www.romanpichler.com/blog/how-to-create-a-product-strategy-for-an-existing-product/): Every product has a strategy. But not all product strategies are clearly articulated, let alone communicated and understood. This can... - [Should Product Teams be Self-Managing?](https://www.romanpichler.com/self-managing-product-teams/): Product teams play a key role in solving user problems and achieving product success. But who should lead the team... - [How to Use AI to Create a Winning Product Strategy](https://www.romanpichler.com/blog/how-to-use-ai-to-create-a-product-strategy/): AI has significantly impacted product management. But so far, most product teams have used it to create new features and... - [5 Tips to Succeed with Stakeholder Management](https://www.romanpichler.com/blog/stakeholder-management-tips/): Stakeholder management is as important as it is challenging: Without the support of the stakeholders, it is virtually impossible to... - [How to Combine Product Strategy, OKRs, and KPIs](https://www.romanpichler.com/blog/product-strategy-okrs-and-kpis/): Product strategy, OKRs, and KPIs are popular product management frameworks. But how can they be applied successfully together? What comes... - [Product Leadership FAQs](https://www.romanpichler.com/blog/product-leadership-faqs/): How product leadership is practised has a big impact on the success of individual products and the product management group... - [Product Strategy FAQs](https://www.romanpichler.com/blog/product-strategy-faqs/): The product strategy is a crucial product management artefact. But what exactly is it? Who should create the strategy? How... - [Product Roadmap FAQs](https://www.romanpichler.com/blog/product-roadmap-faqs/): The product roadmap is an important product management tool. But is it still useful? What is an outcome-based roadmap, and... - [Product Portfolio Strategy FAQs](https://www.romanpichler.com/blog/product-portfolio-strategy-faqs/): Product portfolios, like Microsoft 365 and Adobe Creative Cloud, play an increasingly important role in value creation. But how can... - [Product Vision FAQs](https://www.romanpichler.com/blog/ultimate-product-vision-faqs/): The product vision can be a powerful vehicle to inspire and guide people. But how can you create a truly... - [Stakeholder Management FAQs](https://www.romanpichler.com/blog/stakeholder-management-faqs/): No matter if you love or dislike your stakeholders, you need their input and support to achieve product success. But... - [Product Team FAQs](https://www.romanpichler.com/blog/product-team-faqs/): Product teams play a crucial part in achieving product success. But who should be on the team? How can the... - [Product Backlog FAQs](https://www.romanpichler.com/blog/product-backlog-faqs/): The product backlog can be a powerful tool to discover and deliver the right product features. But how can you... - [5 Product Vision Mistakes You Should Avoid](https://www.romanpichler.com/blog/5-product-vision-mistakes-you-should-avoid/): The product vision can be a powerful vehicle for creating a shared purpose, inspiring people, and galvanising them. Unfortunately, I... - [Strategy and Product Teams](https://www.romanpichler.com/blog/strategy-and-product-teams/): Strategy and product teams are both key to achieving product success. But what exactly do we mean by strategy? Which... - [The Innovation Ambition Matrix](https://www.romanpichler.com/blog/innovation-ambition-matrix/): What do incremental enhancements of a legacy app and the development of a new AI product have in common? Both... - [AI and Product Strategy: Benefits and Limitations](https://www.romanpichler.com/blog/ai-and-product-strategy/): AI has significantly impacted software-based products and has started to change how product management is practised. But how is it... - [Setting up Product Teams for Success](https://www.romanpichler.com/blog/setting-up-product-teams-for-success/): Product teams are key in enabling product-led growth and offering successful products. In this article, I explain what product teams... - [Succeeding with Product Portfolio Roadmaps](https://www.romanpichler.com/blog/product-portfolio-roadmap/): As helpful as they can be, product roadmaps are not always enough. To closely align a group of products and... - [Product Strategy as a System](https://www.romanpichler.com/blog/product-strategy-system/): When it comes to product strategy, people often focus on templates, tools, and frameworks. While these matter, they are only... - [How to Leverage Conflict in Product Management](https://www.romanpichler.com/blog/how-to-leverage-conflict-in-product-management/): It may not be pleasant to experience, but conflict is necessary to innovate successfully. Without competing ideas, it's virtually impossible... - [The Product Strategy and the Product Life Cycle](https://www.romanpichler.com/blog/the-product-strategy-and-the-product-life-cycle/): Developing a winning product strategy is hard. Keeping the strategy relevant and achieving continued product success is even harder. In... - [When You Should NOT Use a Product Roadmap](https://www.romanpichler.com/blog/when-you-should-not-use-a-product-roadmap/): The product roadmap is a popular product management tool that communicates how a product is likely to evolve. But despite... - [Product Strategy Discovery](https://www.romanpichler.com/blog/product-strategy-discovery/): The product strategy is probably the most important artefact in product management. But how do you come up with an... - [Should Stakeholders Be on the Product Team?](https://www.romanpichler.com/blog/stakeholders-on-the-product-team/): A product team is a cross-functional group whose members work together to achieve product success. Most people would agree that... - [Maximising Stakeholder Buy-in to Product Strategy and Product Roadmap](https://www.romanpichler.com/blog/stakeholder-buy-in-product-strategy-roadmap/): The most amazing product strategy and product roadmap are ineffective if the stakeholders don’t support them. Without their buy-in, you’ll... - [How to Get Started with Outcome-Based Product Roadmaps](https://www.romanpichler.com/blog/how-to-get-started-with-outcome-based-product-roadmaps/): Outcome-based product roadmaps offer many benefits over traditional, feature-based ones including a strong focus on the value a product should... - [Continuous Strategizing](https://www.romanpichler.com/blog/continuous-strategizing/): As markets, products, and technologies change at an ever-faster pace, strategies that used to last for years are in danger... - [OKRs and Product Roadmaps](https://www.romanpichler.com/blog/okrs-and-product-roadmaps/): OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs on product roadmaps? What benefits... - [The Strategy Stack: Connecting Business, Product, and Technology Strategy](https://www.romanpichler.com/blog/the-strategy-stack/): For any business to succeed, it is crucial to make the right strategic choices. To achieve this, you’ll benefit from... - [Understanding Empowerment in Product Management](https://www.romanpichler.com/blog/empowerment-levels-in-product-management/): Being empowered can make all the difference in doing a great job. Sadly, not all product people have the authority... - [Everything You Need to Know about Product Portfolio Strategy](https://www.romanpichler.com/blog/product-portfolio-strategy/): Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think of Word, Excel, and PowerPoint,... - [Product Strategy and Product Discovery](https://www.romanpichler.com/blog/product-strategy-and-product-discovery/): Product discovery has become increasingly popular in recent years as a way to determine the right solution. In this article,... - [Decoding Product Leadership](https://www.romanpichler.com/blog/decoding-product-leadership/): Strong product leadership is crucial to offering successful products and enabling product-led growth. Unfortunately, there is disagreement and confusion about... - [GO Product Roadmap Checklist](https://www.romanpichler.com/blog/go-product-roadmap-checklist/): The GO Product Roadmap is a simple yet effective tool to help teams create goal-oriented, outcome-based roadmaps. Despite its simplicity,... - [Building High-Performing Product Teams](https://www.romanpichler.com/blog/building-high-performing-product-teams/): "Great things in business are never done by one person. They're done by a team," Steve Jobs once said. This... - [10 Product Strategy Mistakes to Avoid](https://www.romanpichler.com/blog/10-product-strategy-mistakes-to-avoid/): The product strategy is an important product management artefact. But despite its significance, it is not always effectively used. In... - [Choosing the Right Approach to Capture the Product Vision](https://www.romanpichler.com/blog/double-vision-how-to-capture-the-product-vision/): The product vision plays a crucial part in achieving product success: It sets a shared direction and helps create strong... - [How to Offer Constructive Feedback: A Framework for Product People](https://www.romanpichler.com/blog/offering-constructive-feedback-a-framework-for-product-people/): To create value, product people, stakeholders, and development teams have to work together. But when people collaborate, things don’t always... - [Leveraging New Technologies: 3 Tips for Product People](https://www.romanpichler.com/blog/leveraging-new-technologies-tips-for-product-people/): Change seems to be the only constant when it comes to software technology. Over the last ten years, microservices, cloud-based... - [Should a Head of Product Make Strategic Product Decisions?](https://www.romanpichler.com/blog/head-of-product-and-product-strategy/): The head of product role and the product strategy are often linked. But should a head of product make strategic... - [What Exactly is a Product Strategy?](https://www.romanpichler.com/blog/what-is-a-product-strategy/): The product strategy is possibly the most important product management artefact. But what exactly is it? Which information should it... - [Succeeding with Scrum: 10 Tips for Product People](https://www.romanpichler.com/blog/succeeding-with-product-delivery-and-scrum/): Scrum is not a product management framework. But it can be tremendously valuable for product people: It can help you... - [Product Vision Board Checklist](https://www.romanpichler.com/blog/product-vision-board-checklist/): I designed the product vision board to be a simple yet effective tool to capture the product vision and the... - [Leading without Being the Boss: Tips for Product People](https://www.romanpichler.com/blog/leading-without-being-the-boss-tips-for-product-people/): As the person in charge of the product, you have a rewarding but challenging job. A key challenge is leading... - [10 Product Roadmapping Mistakes to Avoid](https://www.romanpichler.com/blog/product-roadmapping-mistakes-to-avoid/): The product roadmap is a great product management tool. But it can cause significant issues when it is not used... - [5 Tips for Stocking the Product Backlog](https://www.romanpichler.com/blog/5-tips-for-stocking-the-product-backlog/): The product backlog is a simple yet powerful tool to capture tactical product decisions and direct the work of the... - [Roman's Product Strategy Model](https://www.romanpichler.com/blog/my-product-strategy-model/): Making the right strategic decisions is crucial to achieve product success. If it’s not clear, for example, what a product’s... - [Empathy in Product Management](https://www.romanpichler.com/blog/empathy-in-product-management/): I was recently asked at a product management conference what superpower product people should have. I didn’t have to think... - [What Should a Head of Product Do?](https://www.romanpichler.com/blog/what-should-a-head-of-product-do/): Becoming a head of product is a career aspiration for many product managers and product owners. But what exactly should... - [Six Common KPI Mistakes to Avoid](https://www.romanpichler.com/blog/avoid-these-common-kpi-mistakes/): Key performance indicators (KPIs) are metrics that measure how well your product is doing. As useful as they are to... - [Product Teams in Scrum](https://www.romanpichler.com/blog/product-teams-in-scrum/): Scrum is a powerful framework that connects the person in charge of the product with the individuals designing and building... - [10 Tips for Effective Product Management Meetings](https://www.romanpichler.com/blog/10-tips-for-effective-product-management-meetings/): Meetings are essential to align the stakeholders and development team members and make the right product decisions. But we’ve all... - [Six Qualities of a Great Product Vision](https://www.romanpichler.com/blog/six-qualities-of-a-great-product-vision/): The product vision can be a powerful tool to align stakeholders and development teams. When used effectively, it acts as... - [Why Product Owners Need Effective Scrum Masters](https://www.romanpichler.com/blog/why-product-owners-need-effective-scrum-masters/): When you consider who the important partners for product people are, your thoughts might turn to the stakeholders, development team,... - [A Learning Roadmap for Product People](https://www.romanpichler.com/blog/a-learning-roadmap/): Working in product management can be very rewarding. But it can also be very challenging. One of the reasons is... - [Four Product Success Factors](https://www.romanpichler.com/blog/four-product-success-factors/): Our ultimate goal as product people is to achieve sustained product success: to ensure that our products do a great... - [Dealing with an Underperforming Development Team](https://www.romanpichler.com/blog/dealing-with-performance-issues-on-the-development-team/): As the person in charge of the product, you rely on the development team to do a good job. But... - [Seven Product Backlog Mistakes to Avoid](https://www.romanpichler.com/blog/product-backlog-mistakes/): The product backlog is a simple yet powerful tool to capture and revise detailed product decisions and direct the work... - [Three Qualities of Great Product Roadmaps](https://www.romanpichler.com/blog/three-qualities-of-great-product-roadmaps/): The product roadmap can be an incredibly useful planning tool that aligns the stakeholders and development teams and communicates how... - [Product Vision FAQs](https://www.romanpichler.com/blog/product-vision-faqs/): The product vision can be a powerful instrument to inspire and align stakeholders and development teams. But in practice, it... - [Tips for Becoming a Head of Product](https://www.romanpichler.com/blog/tips-for-moving-into-a-head-of-product-role/): Becoming a head of product and managing a group of product people is a significant career step. In this article,... - [Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams](https://www.romanpichler.com/blog/tips-for-deciding-with-stakeholders-and-dev-teams/): I am a big fan of involving the stakeholders and dev teams in important product decisions. But deciding together can... - [Five Product Owner Myths Busted](https://www.romanpichler.com/blog/five-product-owner-myths-busted/): The product owner is a role which is often misunderstood and frequently misapplied. In this article, I address five common... - [How to Choose the Right KPIs for Your Product](https://www.romanpichler.com/blog/how-to-choose-the-right-kpis-for-your-product/): A key challenge of working with KPIs is to select the right indicators: There are so many different metrics to... - [Product Goals in Scrum](https://www.romanpichler.com/blog/product-goals-in-scrum/): The 2020 edition of the Scrum Guide introduced a new type of goal, the product goal. This article shares my... - [How Agile Has Changed Product Management](https://www.romanpichler.com/blog/how-agile-has-changed-product-management/): As the Manifesto for Agile Software Development celebrates its 20th anniversary, I take a look at how agile practices have... - [5 Tips for Saying No to Stakeholders](https://www.romanpichler.com/blog/tips-for-saying-no-to-stakeholders/): Saying no is a firm part of our job as product people: Trying to please everyone and taking on board... - [OKRs in Product Management](https://www.romanpichler.com/blog/okrs-in-product-management/): OKRs—objectives and key results—have experienced a renewed popularity in recent years. Consequently, I am regularly asked if and how OKRs... - [The Product Strategy Cycle](https://www.romanpichler.com/blog/the-product-strategy-cycle/): Despite its importance, product strategy is not always effectively practiced. One of the key issues I encounter in my work... - [A Brief Guide to Product Strategizing](https://www.romanpichler.com/blog/a-brief-guide-to-product-discovery/): When practiced correctly, product discovery maximises the chances of achieving product success. Unfortunately, I find that it's not uncommon that... - [Prioritising a Product Backlog When Everything is Important](https://www.romanpichler.com/blog/prioritising-a-product-backlog-when-everything-is-important/): The product backlog is an essential product management tool: It captures detailed product decisions and directs the work of the... - [Common Product Vision Board Mistakes](https://www.romanpichler.com/blog/common-product-vision-board-mistakes/): The product vision board is a simple yet powerful tool to capture the product vision and the product strategy. Despite... - [Are Feature Teams or Component Teams Right for Your Product?](https://www.romanpichler.com/blog/feature-teams-vs-component-teams/): Whenever you require more than a single development team to progress your product, you have to consider how to organise... - [Stakeholder Management Tips for Product People](https://www.romanpichler.com/blog/stakeholder-management-tips-for-product-people/): As product people, we rely on the stakeholders to successfully progress our product. But effective stakeholder management can be challenging.... - [Six Types of “Product” Owners](https://www.romanpichler.com/blog/six-types-of-product-owners/): While the product owner role is not new—it emerged in Scrum in the second half of the 1990ies—there is still... - [Dealing with Difficult Emotions in Product Management](https://www.romanpichler.com/blog/dealing-with-difficult-emotions/): As product people, we make tough decisions and sometimes, we have to work with challenging people. It is therefore no... - [How to Overcome 6 Key Product Leadership Challenges](https://www.romanpichler.com/blog/overcoming-six-key-product-leadership-challenges/): Products are developed, provided, and enhanced by people, and effectively leading them is crucial to achieve product success. But leading... - [Leveraging Software Platforms](https://www.romanpichler.com/blog/leveraging-software-platforms/): Software platforms can be powerful tools to grow a product portfolio and create new revenue streams. But successfully using them... - [Release Planning Advice](https://www.romanpichler.com/blog/release-planning-advice/): Release planning is an important task for product people working with agile teams: It ensures that the product is moving... - [Tips for Effective Product Strategy Reviews](https://www.romanpichler.com/blog/tips-for-effective-product-strategy-reviews/): The product strategy describes how you plan to achieve product success. It typically covers the product’s value proposition, market, stand-out... - [Product Roadmap Prioritisation](https://www.romanpichler.com/blog/product-roadmap-prioritisation/): Getting the product roadmap prioritisation right is a common challenge. Which items should be addressed first? Which ones can be... - [Empowering Development Teams](https://www.romanpichler.com/blog/empowering-development-teams/): An empowered development team owns its work, is authorised to make the right decisions, and is able to work independently.... - [Tips for Reducing the Product Backlog Size](https://www.romanpichler.com/blog/how-to-reduce-the-product-backlog-size/): It's normal that a product backlog changes over time. But some backlogs grow too big and become overly long, detailed,... - [Tips for Growing a Product Management Team](https://www.romanpichler.com/blog/tips-for-growing-a-product-management-team/): Growth is something wonderful: It means that individuals, teams, and products prosper. Growing a product management team, however, throws up... - [Should Product Roadmaps Have Dates?](https://www.romanpichler.com/blog/should-product-roadmaps-have-dates/): Whether product roadmaps should show dates is a controversial topic in product management. Some people passionately argue that dates should... - [Product Ethics](https://www.romanpichler.com/blog/product-ethics/): Digital products can have a significant impact on the users--from saving lives to exposing people to harmful content, encouraging unhealthy... - [10 Scaling Tips for Product People](https://www.romanpichler.com/blog/10-scaling-tips-for-product-people/): Managing a growing product can be as rewarding as challenging: Involving more people and teams and scaling up is hardly... - [A Strategy Map](https://www.romanpichler.com/blog/strategy-map/): Without an effective strategy, it’s hard to achieve product success. But what does strategy entail? And which tools are best... - [Listening Practices for Product People](https://www.romanpichler.com/blog/listen-to-understand-listening-practices-for-product-people/): Listening to users, customers, stakeholders, and development team members is crucial for us as product people. It allows us to... - [Tips for Rewriting a Digital Product](https://www.romanpichler.com/blog/tips-for-rewriting-a-digital-product/): Rewriting an existing product is often a cost and technology-centric exercise that can feel like a joyless necessity. But instead... - [Technical Debt and Product Success](https://www.romanpichler.com/blog/technical-debt-and-product-success/): Similar to a company experiencing financial debt, products can incur “technical debt”: This happens when wrong or suboptimal architecture, technology,... - [Sustainable Pace in Product Management](https://www.romanpichler.com/blog/sustainable-pace-product-management/): Working in product management is rewarding but demanding. As product people, we have a large set of diverse responsibilities, which... - [Establishing an Effective Product Strategy Process](https://www.romanpichler.com/blog/establishing-an-effective-product-strategy-process/): Developing a successful product is not down to luck or trying hard enough. Instead, product success starts with making the... - [Sprint Planning Tips for Product Owners](https://www.romanpichler.com/blog/sprint-planning-tips-for-product-owners/): As its name suggests, the sprint planning meeting sets up the sprint and establishes what can be done. While it’s... - [Strategic Options for Mature Products](https://www.romanpichler.com/blog/strategic-options-for-mature-products/): Product strategy does not only matter for new and young products; it is equally important for older ones. This article... - [Growth Mindset in Product Management](https://www.romanpichler.com/blog/growth-mindset-in-product-management/): Learning is crucial for us product people. As our products change and eventually mature, we must change the way we... - [Digital Transformation and Product Management](https://www.romanpichler.com/blog/digital-transformation-and-product-management/): Digital transformations often focus on new technologies, agile practices, and new business models. While these are undoubtedly important, a further... - [Product Leadership in Scrum](https://www.romanpichler.com/blog/product-leadership-in-scrum/): Product owners can take on too many responsibilities, become too tactical and inward-focused, and lose sight of their main job:... - [Why Product People Should Care About Business Strategy](https://www.romanpichler.com/blog/business-strategy-and-product-strategy/): As product people, we can be very fond of the products we manage. While it’s good to care about them,... - [Be a Balanced Product Leader, Not a Feature Broker or Product Dictator](https://www.romanpichler.com/blog/be-a-balanced-product-leader-not-a-feature-broker-or-product-dictator/): Being an effective product leader is not easy: It requires embracing people's ideas as well as saying no, being neither... - [Leading Through Shared Goals](https://www.romanpichler.com/blog/leading-through-shared-goals/): Ensuring that development teams and stakeholders are moving in the same direction is crucial to achieving product success. But aligning... - [Product Strategizing Tips](https://www.romanpichler.com/blog/product-discovery-tips/): Product strategizing refers to the activities required to determine if and why a product should be developed. Carrying out this... - [Leveraging Failure in Product Management](https://www.romanpichler.com/blog/leveraging-failure-in-product-management/): Innovation and failure go hand in hand. It’s impossible to bring new products and features to life without taking informed... - [Sprint Review Tips for Product People](https://www.romanpichler.com/blog/sprint-review-tips-for-product-people/): The sprint review is maybe the most important Scrum meeting for product people. Applied correctly, it increases the chances of... - [5 Tips for Building Empathy with Users](https://www.romanpichler.com/blog/empathy-tips-product-management/): Being able to empathise with the users and understand their feelings and thoughts is key to offer a successful product.... - [Choosing the Right Planning Horizon for Your Product](https://www.romanpichler.com/blog/choosing-the-right-planning-horizons-for-your-product/): As product manager and product owners, we need to forecast the likely development of our products. This creates a shared... - [Do Product Owners Need Technical Skills?](https://www.romanpichler.com/blog/product-owners-and-technical-skills/): As a product owner, you look after a digital product and work with a development team. Does this mean that... - [Dealing with Difficult Stakeholders and Team Members](https://www.romanpichler.com/blog/conflict-resolution-tips-product-managers-product-owners/): Experiencing disagreement and conflict is part of our job as product managers and product owners. We work with a broad... - [4 Daily Scrum Tips for Product Owners](https://www.romanpichler.com/blog/4-daily-scrum-tips-for-product-owners-product-managers/): The Daily Scrum is an important meeting for agile development teams: It facilitates self-organisation and helps maximise the chances of... - [The Product Portfolio Matrix](https://www.romanpichler.com/blog/balance-your-portfolio-with-the-product-portfolio-matrix/): The product portfolio matrix is a handy tool that helps you make the right product portfolio decisions. This post explains... - [The T-Shaped Product Professional](https://www.romanpichler.com/blog/the-t-shaped-product-manager/): Product management is a multi-faceted discipline. This makes our work interesting and varied. But it can also make it hard... - [How to Strengthen Your Authority as the Product Manager](https://www.romanpichler.com/blog/how-to-increase-your-product-leadership-power/): In this article, I explain how you can increase your ability to influence and guide others and boost your level... - [Product Manager vs. Product Owner](https://www.romanpichler.com/blog/product-manager-vs-product-owner/): For years, people have debated what the difference between the product manager and the product owner role is, if the... - [Making Unanimous Product Decisions](https://www.romanpichler.com/blog/unanimity-based-product-decisions/): Unanimity is a powerful approach to take advantage of the collective wisdom of the stakeholders and development team members and... - [User Story Reflections](https://www.romanpichler.com/blog/reflections-on-user-stories/): User stories are a simple, straightforward tool. But successfully applying them can be surprisingly hard. This post offers four refections... - [When should Product Backlog Refinement Take Place?](https://www.romanpichler.com/blog/when-should-product-backlog-refinement-take-place/): A refined product backlog facilitates the development of a successful product: It incorporates new insights and learning, and it provides... - [Make Your Product Stand Out with the Strategy Canvas](https://www.romanpichler.com/blog/make-your-product-stand-out-with-the-strategy-canvas/): Few products are ground-breaking innovations with zero competition. Chances are that alternatives for your product exist. You should therefore ensure... - [Use Decision Rules to Make Better Product Decisions](https://www.romanpichler.com/blog/decision-rules-to-make-better-product-decisions/): As product managers and product owners, we make a myriad of decisions—from shaping the product strategy and determining the product... - [Should Product People be Servant-Leaders?](https://www.romanpichler.com/blog/should-product-owners-be-servant-leaders/): Being an effective product professional requires leadership: Product management teams, stakeholders, and development teams need guidance and direction to collaborate... - [10 Tips to Fully Leverage the Product Backlog](https://www.romanpichler.com/blog/ten-product-backlog-tips/): Working with the product backlog can be challenging, and many Scrum product owners wrestle with overly long and detailed backlogs.... - [Mindfulness Tips for Product Managers and Product Owners](https://www.romanpichler.com/blog/mindfulness-tips-for-product-managers-and-product-owners/): As product managers and product owners, we are busy people with a diverse range of responsibilities. This makes it all... - [Is Scrum Right for Your Product?](https://www.romanpichler.com/blog/is-scrum-right-for-your-product/): Scrum offers a powerful way to develop products. In fact, it is often seen as the standard way to create... - [The Product Roadmap and the Release Plan](https://www.romanpichler.com/blog/product-roadmap-vs-release-plan/): Release planning and product roadmapping are both important practices to achieve product success. But what’s exactly the difference between a... - [10 Tips for Creating an Agile Product Roadmap](https://www.romanpichler.com/blog/10-tips-creating-agile-product-roadmap/): A product roadmap is a powerful tool to describe how a product is likely to grow, to align the stakeholders,... - [8 Tips for Collaborating with Development Teams](https://www.romanpichler.com/blog/tips-for-working-development-team-for-product-managers-product-owners/): The development team is a key partner for every product manager and product owner: the team designs and builds the... - [Scaling the Product Owner Role](https://www.romanpichler.com/blog/scaling-the-product-owner/): In theory, the product owner is one person. But in practice, managing a larger, complex product is usually a shared... - [What is a Digital Product?](https://www.romanpichler.com/blog/what-is-a-digital-product/): As product professionals, we create a product strategy and product roadmap; we manage the product backlog; we release minimum viable... - [How Minimum Viable Products & Features Helped Me Write "Strategize"](https://www.romanpichler.com/blog/minimum-viable-product-mvp-minimum-viable-feature/): A minimum viable product (MVP) is often mistaken as the first general release of a product, the initial offering that... - [Five Tips for Introducing Product Management to Your Company](https://www.romanpichler.com/blog/five-tips-for-introducing-product-management-to-your-company/): Product management plays a vital role in the digital age: it enables innovation and growth. It’s therefore not surprising that... - [10 Tips for Writing Good User Stories](https://www.romanpichler.com/blog/10-tips-writing-good-user-stories/): User stories are probably the most popular agile technique to capture product functionality: Working with user stories is easy. But... - [The Agile Product Owner Responsibilities](https://www.romanpichler.com/blog/the-product-owner-responsibilities/): In theory, the product owner’s responsibilities are simple: The individual should maximise the value the product creates according to the... - [10 Leadership Qualities of Successful Product Managers](https://www.romanpichler.com/blog/10-leadership-qualities-product-manager-product-owner/): Learn how to develop 10 important leadership qualities that help you become a successful product manager and effective product leader.... - [A Balanced Product Scorecard](https://www.romanpichler.com/blog/balanced-product-scorecard-template/): Product scorecards are an important product management tool: They help you track the performance of your product. Unfortunately, many scorecards... - [How to Choose the Right Product Management Leadership Styles](https://www.romanpichler.com/blog/product-management-leadership-styles/): Succeeding in product management requires more than having the right product expertise. While creating a valid product strategy, developing an... - [10 Tips for Using Key Performance Indicators](https://www.romanpichler.com/blog/10-tips-for-product-key-performance-indicators-kpis/): Product key performance indicators, or KPIs for short, are metrics that measure the performance of a product. They help you... - [Getting Stakeholder Engagement Right](https://www.romanpichler.com/blog/stakeholder-engagement-analysis-power-interest-grid/): Being a successful product manager or product owner requires more than building a product with the right user experience (UX)... - [Why User Stories Fail](https://www.romanpichler.com/blog/user-stories-failure/): User stories are a powerful agile technique to describe requirements from the perspective of the customers and users. Unfortunately, I... - [The GO Portfolio Roadmap](https://www.romanpichler.com/blog/the-go-portfolio-roadmap/): Products don’t exist in isolation. Instead, they are often related to other products, which they help sell or they share... - [3 Common Product Roadmapping Mistakes](https://www.romanpichler.com/blog/three-common-product-roadmapping-mistakes/): The product roadmap is a great tool to describe the likely growth of a product. But there are three common... - [How Detailed should the Product Backlog be?](https://www.romanpichler.com/blog/product-backlog-right-details/): The product backlog is a great tool. But using it effectively can be difficult. One of the challenges is to... - [Size Matters: Big vs. Small Product Owner](https://www.romanpichler.com/blog/big-product-owner-small-product-owner/): Product owners come in different shapes and sizes. That's only natural: The application of the role varies depending on the... - [Elements of an Effective Product Strategy](https://www.romanpichler.com/blog/elements-definition-product-strategy/): Creating a successful product requires attention to the details, from getting the user interaction and the visual design right to... - [Eliminate Features to Differentiate your Product](https://www.romanpichler.com/blog/eliminate-features/): It is tempting to add more and more features to make your product stand out and differentiate it from the... - [Market Segmentation Tips](https://www.romanpichler.com/blog/market-segmentation-tips-for-product-managers/): Identifying the right customers and users for your product is key to its success: It determines the value proposition and... - [How to Choose the Right Product Roadmap Format](https://www.romanpichler.com/blog/how-to-choose-the-right-product-roadmap-format/): A product roadmap is a high-level plan that shows how a product is likely to develop over the next few... - [Which UX Skills should Product Owners and Product Managers have?](https://www.romanpichler.com/blog/ux-skills-for-product-owners-and-product-managers/): Providing a great user experience is a must for many digital products, and user experience (UX) design has consequently become... - [The Product Owner’s Checklist for the First Sprint](https://www.romanpichler.com/blog/the-product-owners-checklist-for-the-first-sprint-in-scrum/): Scrum is a popular agile framework for developing a product with the right features and the right technologies. Unfortunately, it... - [What is Product Management?](https://www.romanpichler.com/blog/romans-product-management-framework/): Product management is a multi-faceted, complex discipline that can be difficult to grasp and hard to master. This post shares... - [8 Tips for Creating A Compelling Product Vision](https://www.romanpichler.com/blog/tips-for-writing-compelling-product-vision/): Creating and managing a successful product requires a lot of time and energy. In order to be fully committed, you... - [The Product Roadmap and the Product Backlog](https://www.romanpichler.com/blog/product-roadmap-product-backlog/): The product backlog is a great tool to capture ideas and requirements. But it is less suited to describe how... - [From Personas to User Stories](https://www.romanpichler.com/blog/personas-epics-user-stories/): User stories are a powerful technique to capture the product functionality from the perspective of a user or customer. But... - [10 Tips for Creating a Product Strategy with the Product Vision Board](https://www.romanpichler.com/blog/10-tips-creating-agile-product-strategy-vision-board/): This post does what its title says: It shares my recommendations for creating an agile product strategy using the Vision... - [The Product Owner’s Guide to the Sprint Retrospective](https://www.romanpichler.com/blog/product-owner-sprint-retrospective/): The sprint retrospective is a key mechanism in Scrum to improve the way people work. This article shares my tips... - [How to Choose the Right Product Validation Technique in Scrum](https://www.romanpichler.com/blog/beyond-product-demo-validation-techniques-in-scrum/): Scrum employs the product demo as its default technique to understand if the right product with the right features is... - [Every Great Product Owner Needs a Great Scrum Master](https://www.romanpichler.com/blog/every-great-product-owner-needs-great-scrummaster/): The Scrum product owner and the Scrum Master are two separate roles that complement each other. To do a great... - [A Template for Formulating Great Sprint Goals](https://www.romanpichler.com/blog/sprint-goal-template/): Sprint goals can guide the work of the development team and describe the desired outcome of a sprint. As useful... - [Data Analysis Tips for Product Managers and Product Owners](https://www.romanpichler.com/blog/data-analysis-tips-product-managers-product-owners/): Data analysis might sound a bit nerdy, but it should be part of every product manager's and product owner's tool... - [Working with the GO Product Roadmap](https://www.romanpichler.com/blog/working-go-product-roadmap/): The GO product roadmap is a goal-oriented product planning tool designed to work with Lean Startup and Scrum. By focusing... - [10 Tips for Creating Agile Personas](https://www.romanpichler.com/blog/10-tips-agile-personas/): Personas are a powerful technique to describe the users and customers of a product in order to make the right... - [The GO Product Roadmap](https://www.romanpichler.com/blog/goal-oriented-agile-product-roadmap/): The product roadmap is an important product management tool. But effectively applying it can be challenging. Roadmaps are too often... - [User Stories are Not Enough for a Great User Experience](https://www.romanpichler.com/blog/user-stories-enough-for-a-great-user-experience/): Creating a product with a great user experience requires more than just user stories. While capturing the product functionality is... - [The Minimum Viable Product and the Minimal Marketable Product](https://www.romanpichler.com/blog/minimum-viable-product-and-minimal-marketable-product/): The minimum viable product (MVP) and the minimal marketable product (MMP) are two powerful concepts: The MVP helps you test... - [The Picasso Product Owner: Balancing Users, Team, and Stakeholders](https://www.romanpichler.com/blog/picasso-product-owner/): Working as a product owner is fun and challenging at times. One challenge is to balance two separate concerns: the... - [Succeeding with Innovation and Maintenance](https://www.romanpichler.com/blog/innovation-and-maintenance/): Keeping a product successful can be tricky: New features have to be developed to ensure that the product stays beneficial... - [Combining Lean Startup and Scrum](https://www.romanpichler.com/blog/combining-lean-startup-and-scrum/): Can Lean Startup and Scrum be combined? And if so, how do they fit together? This post shares my answers... - [5 Common User Story Mistakes](https://www.romanpichler.com/blog/5-common-user-story-mistakes/): User stories are a simple, yet effective way to communicate how a user or customer employs a product. But writing... - [Get Your Focus Right: Learning and Execution in Scrum](https://www.romanpichler.com/blog/learning-and-execution-in-scrum/): Learning what a product should look like and do, and building solid, shippable software are different concerns. Separating the two... - [The Product Canvas Creation Workshop](https://www.romanpichler.com/blog/the-product-canvas-creation-workshop/): The Product Canvas is a simple, yet powerful tool that helps you create a product with a great user experience... - [Agile Scenarios and Storyboards](https://www.romanpichler.com/blog/agile-scenarios-and-storyboards/): User stories are great at capturing product functionality. But they are less suited to describe complex user interactions. This is... - [Agile Product Planning: Vision, Strategy, and Tactics](https://www.romanpichler.com/blog/agile-product-planning-vision-strategy-tactics/): Product planning is just as important in an agile context as in a traditional setting. Unfortunately, some product owners focus... - [Non-functional Requirements](https://www.romanpichler.com/blog/agile-nonfunctional-requirements/): This post explains how you can discover and describe non-functional requirements like performance, robustness, and interoperability. - [The Good, the Bad, and the Ugly Backlog](https://www.romanpichler.com/blog/the-product-backlogs-strengths-and-limitations/): The product backlog is an important tool: It lists the ideas and requirements necessary to create a product. But is... - [Tips for an Effective Product Demo](https://www.romanpichler.com/blog/product-demo-tips/): The sprint demo is a standard technique in Scrum to collect feedback from users, customers, and stakeholders in order to... - [Product Owner Empowerment](https://www.romanpichler.com/blog/product-ownership-empowerment/): Playing the product owner role can be challenging: It requires the authority to say no to ideas, request, and feedback... - [Creating Effective Sprint Goals](https://www.romanpichler.com/blog/effective-sprint-goals/): Working with a sprint goal is a powerful agile practice. This post helps you understand what sprint goals are, why... - [Epics and Ready Stories](https://www.romanpichler.com/blog/epics-and-ready-stories/): This post explains how to write user stories at the right level of detail, and how to derive small, ready... - [Working with the Product Vision Board](https://www.romanpichler.com/blog/working-with-the-agile-product-vision-board/): "This is your last chance. After this, there is no turning back. You take the blue pill – the story... - [The Scrum Cycle](https://www.romanpichler.com/blog/the-scrum-cycle/): Scrum is a simple framework based on the idea of inspect and adapt: Create a product increment, show it to... - [The Three Innovation Drivers](https://www.romanpichler.com/blog/the-three-innovation-drivers/): Employing experiments is a powerful technique to facilitate the creation of new products and new features. But to experiment effectively,... - [The Product Canvas](https://www.romanpichler.com/blog/the-product-canvas/): This post introduces my Product Canvas, a simple but powerful tool that helps you create a product with a great... - [Intuition and Data in Product Management](https://www.romanpichler.com/blog/intuition-data-agile-product-management/): Making the right product decisions is tough. Some product owners trust their intuition, others rely on data. Find out which... - [Choosing the Lean and Agile Innovation Practices](https://www.romanpichler.com/blog/choosing-the-right-lean-and-agile-innovation-practices/): Innovation can be a tricky thing: Not only does it means different things to different people, but creating a brand-new... - [Working with an Agile Product Roadmap](https://www.romanpichler.com/blog/agile-product-roadmap/): This blog post discusses what an agile product roadmap is. It covers the information such a roadmap should contain, the... - [A Simple Persona Template](https://www.romanpichler.com/blog/persona-template-for-agile-product-management/): Personas are a great way to capture our knowledge about the users and customers and their needs. But writing effective... - [The Product Backlog Refinement Steps](https://www.romanpichler.com/blog/the-product-backlog-refinement-steps/): Refining the product backlog helps you make the right product decisions and get the product backlog ready for the next... - [Agile User Interface Design](https://www.romanpichler.com/blog/agile-user-interface-design/): The role of design still puzzles many agile teams I work with. When should the design activities take place? Who... - [Focus on the User, not the Product!](https://www.romanpichler.com/blog/focus-on-the-user-not-the-product/): Getting lost in the product details and struggling to decide if a feature should be implemented is a common challenge... - [The Highlander Principle](https://www.romanpichler.com/blog/the-single-product-owner/): If you grew up as a teenager in the 1980s like me, you are probably familiar with the quote “There... - [The Product Backlog as a Learning Tool](https://www.romanpichler.com/blog/product-backlog-learning-tool/): Leverage the power of customer feedback, and use your product backlog as a learning tool. Discover the right product features... - [The Scrum Startup](https://www.romanpichler.com/blog/scrum-startup/): The blog posts explains how to setting up a Scrum team as an incubator in an established enterprise helps create... - [The Vision, the Product Backlog and the Minimum Viable Product](https://www.romanpichler.com/blog/the-vision-the-product-backlog-and-the-minimal-viable-product/): Learn how the product vision, the product backlog, and the concept of a minimal viable product (MVP) can be combined... - [Two Common Ways to Apply the Product Owner Role](https://www.romanpichler.com/blog/two-common-ways-to-apply-the-product-owner-role/): Applying the product owner role can be challenging, as no two products are the same. While products and projects vary,... - [The Minimal Marketable Product](https://www.romanpichler.com/blog/the-minimal-marketable-product/): Innovate successfully by creating a minimal marketable product, a product with just the right features. This allows you to launch... - [The Release Planning Workshop](https://www.romanpichler.com/blog/release-planning-workshop/): Determining the release date and budget before development starts can be tricky particularly for new or young products where the... - [User Story Modelling](https://www.romanpichler.com/blog/user-story-modelling/): User stories are great at capturing product functionality in isolation. But they are not well suited to describe the relationship... - [The Product Vision Board](https://www.romanpichler.com/blog/the-product-vision-board/): The vision plays an important role in bringing a new product to life: It acts as the overarching goal guiding... - [Choosing the Right Agile Pilot Project](https://www.romanpichler.com/blog/choosing-the-right-agile-pilot-project/): “Which project is best suited to pilot Agile? ” is a question I get regularly asked. This blog post discusses... - [The Product Backlog Board](https://www.romanpichler.com/blog/product-backlog-board/): Are you struggling with your product backlog? Then try my Product Backlog Board, a structured hierarchical product backlog that helps... - [The Definition of Ready in Scrum](https://www.romanpichler.com/blog/the-definition-of-ready/): “Ready are you? What know you of ready? ” says Yoda to Luke Skywalker in the Star Wars movie “The... - [How to Make Your Product Fail](https://www.romanpichler.com/blog/how-to-ensure-product-failure/): This blog post provides a tongue-in-cheek collection of common product creation mistakes. Combined they are a recipe for certain failure... - [The Scrum Product Owner Role on One Page](https://www.romanpichler.com/blog/one-page-product-owner/): The product owner is a product management role that emerged in Scrum in the late 1990ies. But many organisations still... - [Stable Agile Teams](https://www.romanpichler.com/blog/stable-teams/): It’s not uncommon for me to visit a new client and discover that the agile development teams frequently change, sometimes... - [Refining User Stories](https://www.romanpichler.com/blog/refining-user-stories/): User stories come in different shapes and sizes. Large stories, also called epics, allow quickly sketching product functionality, which is... - [The Lean Product Backlog - Limit Variation and Prevent Overburden](https://www.romanpichler.com/blog/the-lean-product-backlog-variation-and-overburden/): Many product backlogs are too long, detailed and complex. This is in stark contrast to what the product backlog should... - [The Lean Product Backlog - Eliminate Waste](https://www.romanpichler.com/blog/the-lean-product-backlog-eliminate-waste/): Many product backlogs are too long, detailed and complex. This is in stark contrast to what the product backlog should... - [Think Product!](https://www.romanpichler.com/blog/think-product/): This blog post explores the notion of a product in Scrum. Being clear on what a product is a prerequisite... - [Prioritising the Product Backlog](https://www.romanpichler.com/blog/prioritising-the-product-backlog/): This blog posts explores four useful factors to prioritise the product backlog: value; risk and uncertainty; releasability; and dependencies. - [When to Break up your Product Backlog](https://www.romanpichler.com/blog/when-to-break-up-your-product-backlog/): The product backlog is meant to be a simple tool that allows product owners to express detailed product decisions and... - [Pull Processes with Lean, Kanban and Scrum](https://www.romanpichler.com/blog/pull-processes/): Pull processes do not only play an important role in Kanban, they are also fundamental to Scrum. This post characterises... - [When Scrum is not a Good Fit](https://www.romanpichler.com/blog/when-scrum-is-not-a-good-fit/): Scrum is a simple, powerful framework created to manage the development of complex products. But seeing Scrum as a silver... - [User Stories or Use Cases?](https://www.romanpichler.com/blog/user-stories-or-use-cases/): User stories and use cases are both powerful techniques to capture requirements. But which one is right for you? This... - [How much Product Strategizing is Necessary?](https://www.romanpichler.com/blog/how-much-product-discovery-is-necessary/): Product discovery, exploring the value proposition, market, differentiators, business goals, and business model of a new or updated product, is... - [Why Product Owners should Care about Quality](https://www.romanpichler.com/blog/why-product-owners-should-care-about-quality/): Software quality is often perceived as something the nerds should worry about. But it can significantly impact customer satisfaction and... - [The Desirable Characteristics of a Product Owner](https://www.romanpichler.com/blog/desirable-characteristics-of-a-product-owner/): I often get asked what characteristics a product owner should exhibit. Even though the answer depends on a number of... - [Creating Products that Customers Love](https://www.romanpichler.com/blog/creating-products-that-customers-love/): We all want to create great products–products that customers love and that meet or exceed our financial goals. But the... - [Is the Product Owner the Product Manager?](https://www.romanpichler.com/blog/product-owner-product-manager/): This blog post explores the differences between working as a product manager and playing the product owner role. - [Business Analysts in Scrum](https://www.romanpichler.com/blog/business-analysts-in-scrum/): Business analysts play an important role: Traditionally, they act as the link between the business units and IT, help to... - [What is Agile Product Management?](https://www.romanpichler.com/blog/what-is-agile-product-management/): Find out how agile product management differs from traditional approaches. This post summarises the key differences between old-school and agile... - [Envisioning Your Product](https://www.romanpichler.com/blog/envisioning-your-product/): Being able to envision what a new product or the next product version should look like and do is essential... - [Refining the Product Backlog](https://www.romanpichler.com/blog/refining-the-product-backlog/): Product backlog refinement, or grooming, plays an important part in delivering a product. Done correctly, it increases the chances of... - [Make the Product Backlog DEEP](https://www.romanpichler.com/blog/make-the-product-backlog-deep/): The product backlog is intended to be a simple tool. But in reality, product backlogs are often too long, too... - [Avoiding Common Product Owner Mistakes](https://www.romanpichler.com/blog/avoiding-common-product-owner-mistake/): Applying the product owner role can be challenging. The role has diverse responsibilities, and its application is context-sensitive: it varies... - [Demystifying the Product Owner Role](https://www.romanpichler.com/blog/demystifying-the-product-owner-role/): The product owner role in Scrum has attracted plenty of interest and controversy. Some people believe it rebrands the traditional... ## FAQs - [How long have you been teaching your training courses?](https://www.romanpichler.com/blog/ufaqs/how-long-have-you-been-teaching/): Roman started teaching his Product Strategy and Roadmap course as a public workshop in 2014 and his Product Leadership training... - [Do you offer company-specific training?](https://www.romanpichler.com/blog/ufaqs/company-specific-training/): Yes, Roman offers company-specific training. If you are interested in having Roman teach one of his training courses for your... - [Can I pass on my ticket to someone else?](https://www.romanpichler.com/blog/ufaqs/can-i-pass-on-my-ticket-to-someone-else/): You can transfer your ticket to another person if you notify us by email no later than 14 days before... - [Will I get a place when I am on the waitlist?](https://www.romanpichler.com/ufaqs/will-i-get-a-place-when-i-am-on-the-waitlist/): When you have joined the waitlist of one of our courses, we will email you as soon as we receive... - [Can I purchase a voucher?](https://www.romanpichler.com/ufaqs/can-i-purchase-a-voucher/): Yes, you can buy a voucher to attend Roman’s training courses. Please contact us and tell us which training course(s)... - [Do you offer any discounts?](https://www.romanpichler.com/blog/ufaqs/do-you-offer-a-discount/): We offer the following discounts on the regular ticket price: Group: 15% discount when three or more tickets are purchased... - [Can I change to another class?](https://www.romanpichler.com/ufaqs/can-i-change-to-another-class/): You can transfer your booking to the same course on an alternative date if you notify us by email no... - [What size are Roman's classes?](https://www.romanpichler.com/blog/ufaqs/how-big-are-romans-classes/): Roman’s online classes are limited to a maximum of 15 attendees for his product leadership training and to a maximum... - [What is Roman's online training like?](https://www.romanpichler.com/blog/ufaqs/what-is-romans-online-training-like/): Roman’s online training is live, interactive, friendly, and engaging. Think of it as an instructor-led remote workshop with the appropriate... - [Can I pay by invoice?](https://www.romanpichler.com/blog/ufaqs/can-i-pay-by-invoice/): Yes, you can pay by invoice if payment by credit card and PayPal is not an option for you. To... - [How many people from the same company can attend?](https://www.romanpichler.com/blog/ufaqs/how-many-people-from-the-same-company-can-attend/): We limit the number of employees from the same company to four attendees per course. This ensures a balanced class,... - [Can I cancel my ticket and get a refund?](https://www.romanpichler.com/ufaqs/can-i-cancel-my-ticket-and-get-a-refund/): If we receive your notification at least 14 days before the start of the course and if we are able... - [Which tools do I need to attend the training?](https://www.romanpichler.com/ufaqs/which-tools-do-i-need-to-be-able-to-attend-online-training/): You will need a computer with a webcam and a microphone, preferably a device with a large enough screen, like... - [Why do I need to do some prep work?](https://www.romanpichler.com/ufaqs/why-do-i-need-to-do-some-prep-work/): Carrying out the recommended prep work will help you reflect on your understanding of the subjects covered and familiarise yourself... - [Will I get a copy of the presentation used in class?](https://www.romanpichler.com/ufaqs/will-i-get-a-copy-of-the-presentation-used-in-class/): You will receive a PDF document that contains the slides Roman shows in class, screenshots of all the artefacts created... ## YouTube Videos ## Events - [Product Leadership Workshop](https://www.romanpichler.com/event/product-leadership-workshop-5/): Succeed in Leading Stakeholders and Product Teams - [Product Strategy and Product Roadmap Workshop](https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-january-2026-2-2/): Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - [Product Strategy Workshop](https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-january-2026-2-2/): Learn how to Create a Winning Product Strategy. - [Product Leadership Workshop: In Person](https://www.romanpichler.com/event/product-leadership-training-may-2025-london-2/) - [Product Strategy and Product Roadmap Workshop](https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-january-2026-2/): Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - [Product Strategy and Product Roadmap Workshop: Online](https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-january-2026/): Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - [Product Leadership Training: Online](https://www.romanpichler.com/event/product-leadership-training-july-2025-2/): Succeed in Leading Stakeholders and Product Teams Achieving product success is not possible without strong leadership: You have to secure... - [Product Strategy and Product Roadmap Training](https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-14-2-2-2-2-2-2-2-2/): Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - [Product Strategy and Product Roadmap Training](https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-14-2-2-2-2-2-2-2/): Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - [Product Leadership Training](https://www.romanpichler.com/event/product-leadership-training-july-2025/): Succeed in Leading Stakeholders and Product Teams Achieving product success is not possible without strong leadership: You have to secure... - [Product Strategy and Product Roadmap Training](https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-14-2-2-2-2-2-2/): Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - [Product Leadership Training](https://www.romanpichler.com/event/product-leadership-training-5-2-2-2/): Succeed in Leading Stakeholders and Product Teams Achieving product success is not possible without strong leadership: You have to secure... - [Product Strategy and Product Roadmap Training](https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-14-2-2-2-2-2/): Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - [Product Leadership Training in Hamburg](https://www.romanpichler.com/event/product-leadership-training-8/) - [Product Strategy and Product Roadmap Training](https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-14-2-2-2-2/): Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - [Product Leadership Training](https://www.romanpichler.com/event/product-leadership-training-5-2-2/): Succeed in Leading Stakeholders and Product Teams Achieving product success is not possible without strong leadership: You have to secure... - [Product Strategy and Product Roadmap Training](https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-14-2-2-2/): Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - [Product Leadership Training](https://www.romanpichler.com/event/product-leadership-training-5-2/): Succeed in Leading Stakeholders and Product Teams Achieving product success is not possible without strong leadership: You have to secure... - [Product Strategy and Product Roadmap Training](https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-14-2/): Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. ## Episode - [How to Create a Truly Inspiring Product Vision](https://www.romanpichler.com/podcast/how-to-create-a-truly-inspiring-product-vision/): “If you are working on something exciting that you really care about, you don’t have to be pushed. The vision... - [Emotional Intelligence for Product Managers: The Critical Capability AI Can't Replicate](https://www.romanpichler.com/podcast/emotional-intelligence-in-product-management/): As product management becomes increasingly data-driven and AI-powered, one human capability is growing in importance: emotional intelligence. In this episode,... - [The Product Strategy Framework: A Revised Guide for Product Leaders](https://www.romanpichler.com/podcast/romans-product-strategy-framework-v3/): One of the biggest mistakes I see product managers make is making decisions in isolation: Deciding on strategy without considering... - [Should Product Managers be Product Builders?](https://www.romanpichler.com/podcast/product-managers-product-builders/): Is it a good thing when product managers are hands-on and use AI to build prototypes and generate code? Will... - [Get the Outcomes on Your Product Roadmap Right](https://www.romanpichler.com/podcast/get-the-outcomes-on-your-product-roadmap-right/): Product outcomes define the specific value a product creates—for users, customers, and the business. When applied correctly, they align stakeholders,... - [Succeeding with the Product Operating Model](https://www.romanpichler.com/podcast/succeeding-with-the-product-operating-model/): In this episode, I explain how you can successfully implement the product operating model—based on my experience of helping companies... - [How to Build a Strategy for an Existing Product](https://www.romanpichler.com/podcast/how-to-create-a-product-strategy-for-an-existing-product/): Every product has a strategy. But not all product strategies are clearly articulated, let alone communicated and understood. This can... - [Should Product Teams be Self-Managing?](https://www.romanpichler.com/podcast/self-managing-product-teams/): Product teams play a key role in solving user problems and achieving product success. But who should lead the team... - [How to Use AI to Create a Winning Product Strategy](https://www.romanpichler.com/podcast/how-to-use-ai-to-create-a-product-strategy/): AI has significantly impacted product management. But so far, most product teams have used it to create new features and... - [5 Tips to Succeed with Stakeholder Management](https://www.romanpichler.com/podcast/stakeholder-management-tips/): Stakeholder management is as important as it is challenging: Without the support of the stakeholders, it is virtually impossible to... - [How to Combine Product Strategy, OKRs, and KPIs](https://www.romanpichler.com/podcast/product-strategy-okrs-and-kpis/): Product strategy, OKRs, and KPIs are popular product management frameworks. But how can they be applied successfully together? What comes... - [5 Product Vision Mistakes You Should Avoid](https://www.romanpichler.com/podcast/product-vision-mistakes/): The product vision can be a powerful vehicle for creating a shared purpose, inspiring people, and galvanising them. Unfortunately, I... - [Strategy and Product Teams](https://www.romanpichler.com/podcast/strategy-and-product-teams/): Strategy and product teams are both key to achieving product success. But what exactly do we mean by strategy, and... - [The Innovation Ambition Matrix](https://www.romanpichler.com/podcast/innovation-ambition-matrix/): What do incremental enhancements of a legacy app and the development of a new AI product have in common? Both... - [AI and Product Strategy](https://www.romanpichler.com/podcast/ai-and-product-strategy/): AI has significantly impacted software-based products and has started to change how product management is practised. But how is it... - [Setting up Product Teams for Success](https://www.romanpichler.com/podcast/setting-up-product-teams-for-success/): Product teams are key in enabling product-led growth and offering successful products. In this episode, I explain what product teams... - [Succeeding with Product Portfolio Roadmaps](https://www.romanpichler.com/podcast/product-portfolio-roadmap/): As helpful as they can be, product roadmaps are not always enough. To closely align a group of products and... - [Product Strategy as a System](https://www.romanpichler.com/podcast/product-strategy-system/): When it comes to product strategy, people often focus on templates, tools, and frameworks. While these matter, they are only... - [How to Leverage Conflict in Product Management](https://www.romanpichler.com/podcast/how-to-leverage-conflict-in-product-management/): It may not be pleasant to experience, but conflict is necessary to innovate successfully. Without competing ideas, it's virtually impossible... - [The Product Strategy and the Product Life Cycle](https://www.romanpichler.com/podcast/product-strategy-and-product-life-cycle/): Developing a winning product strategy is hard. Keeping the strategy relevant and achieving product success on a continued basis is... - [When You Should NOT Use a Product Roadmap](https://www.romanpichler.com/podcast/when-you-should-not-use-a-product-roadmap/): The product roadmap is a popular product management tool that communicates how a product is likely to evolve. But despite... - [Product Strategy Discovery](https://www.romanpichler.com/podcast/product-strategy-discovery/): The product strategy is probably the most important artefact in product management. But how do you come up with an... - [Should Stakeholders Be on the Product Team?](https://www.romanpichler.com/podcast/stakeholders-on-the-product-team/): A product team is a cross-functional group whose members work together to achieve product success. Most people would agree that... - [Maximising Stakeholder Buy-in to Product Strategy and Product Roadmap](https://www.romanpichler.com/podcast/stakeholder-buy-in-product-strategy-roadmap/): The most amazing product strategy and product roadmap are ineffective if the stakeholders don’t support them. Without their buy-in, you’ll... - [How to Get Started with Outcome-Based Product Roadmaps](https://www.romanpichler.com/podcast/how-to-get-started-with-outcome-based-product-roadmaps/): Outcome-based product roadmaps offer many benefits over traditional, feature-based ones including a strong focus on the value a product should... - [Continuous Strategizing](https://www.romanpichler.com/podcast/continuous-strategizing/): Markets, products, and technologies change at an ever-faster pace, and product strategies are in danger of becoming quickly outdated if... - [OKRs and Product Roadmaps](https://www.romanpichler.com/podcast/okrs-and-product-roadmaps/): OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs on product roadmaps? What benefits... - [The Strategy Stack: Connecting Business, Product, and Technology Strategy](https://www.romanpichler.com/podcast/the-strategy-stack/): For any business to succeed, it is crucial to make the right strategic decisions. To achieve this, you’ll benefit from... - [Understanding Empowerment in Product Management](https://www.romanpichler.com/podcast/empowerment-levels-in-product-management/): Being empowered can make all the difference in doing a great job. Sadly, not all product people have the authority... - [Everything You Need to Know about Product Portfolio Strategy](https://www.romanpichler.com/podcast/product-portfolio-strategy/): Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think of Word, Excel, and PowerPoint,... - [Product Strategy and Product Discovery](https://www.romanpichler.com/podcast/product-strategy-and-product-discovery/): Product discovery has become increasingly popular in recent years as a way to determine the right solution. In this podcast... - [Decoding Product Leadership](https://www.romanpichler.com/podcast/decoding-product-leadership/): Strong product leadership is crucial to offering successful products and enabling product-led growth. Unfortunately, there is disagreement and confusion about... - [GO Product Roadmap Checklist](https://www.romanpichler.com/podcast/go-product-roadmap-checklist/): The GO Product Roadmap is a simple yet effective tool to help teams create goal-oriented, outcome-based roadmaps. Despite its simplicity,... - [Building High-Performing Product Teams](https://www.romanpichler.com/podcast/building-high-performing-product-teams/): “Great things in business are never done by one person. They’re done by a team,” Steve Jobs once said. This... - [10 Product Strategy Mistakes to Avoid](https://www.romanpichler.com/podcast/10-product-strategy-mistakes-to-avoid/): The product strategy is an important product management artefact. But despite its significance, it is not always effectively used. In... - [Double Vision: Choosing the Right Approach to Capture the Product Vision](https://www.romanpichler.com/podcast/double-vision-choosing-the-right-approach-to-capture-the-product-vision/): The product vision plays a crucial part in achieving product success: It sets a shared direction and helps create strong... - [How to Offer Constructive Feedback: A Framework for Product People](https://www.romanpichler.com/podcast/offering-effective-feedback/): To create value, product people, stakeholders, and development teams have to work together. But when people collaborate, things don’t always... - [Leveraging New Technologies: 3 Tips for Product People](https://www.romanpichler.com/podcast/leveraging-disruptive-technologies-3-tips-for-product-people/): Change seems to be the only constant when it comes to software technology. Over the last ten years, microservices, cloud-based... - [Should a Head of Product Make Strategic Product Decisions?](https://www.romanpichler.com/podcast/head-of-product-and-product-strategy/): The head of product role and the product strategy are often linked. But should a head of product make strategic... - [What Exactly is a Product Strategy?](https://www.romanpichler.com/podcast/what-is-a-product-strategy/): The product strategy is possibly the most important product management plan. But what exactly is it? Which information should it... - [Succeeding with Scrum: 10 Tips for Product People](https://www.romanpichler.com/podcast/succeeding-with-product-delivery-and-scrum/): Scrum is not a product management framework. But it can be tremendously valuable for product people: It can help you... - [Leading without Being the Boss: Tips for Product People](https://www.romanpichler.com/podcast/leading-without-being-the-boss/): As the person in charge of the product, you have a rewarding but challenging job. A key challenge is leading... - [10 Product Roadmapping Mistakes to Avoid](https://www.romanpichler.com/podcast/product-roadmapping-mistakes-to-avoid/): The product roadmap is a great product management tool. But it can cause significant issues when it is not used... - [5 Tips for Stocking the Product Backlog](https://www.romanpichler.com/podcast/stocking-the-product-backlog/): The product backlog is a simple yet powerful tool to capture tactical product decisions and direct the work of the... - [Roman's Product Strategy Model](https://www.romanpichler.com/podcast/my-product-strategy-model/): Making the right strategic decisions is crucial to achieve product success. If it’s not clear, for example, what a product’s... - [Empathy in Product Management](https://www.romanpichler.com/podcast/empathy-in-product-management/): I was recently asked at a product management conference what superpower product people should have. I didn’t have to think... - [What Should a Head of Product Do?](https://www.romanpichler.com/podcast/what-should-a-head-of-product-do/): Becoming a head of product is a career aspiration for many product managers and product owners. But what exactly should... - [Six Common KPI Mistakes to Avoid](https://www.romanpichler.com/podcast/six-common-kpi-mistakes/): Key performance indicators (KPIs) are metrics that measure how well your product is doing. As useful as they are to... - [Product Teams in Scrum](https://www.romanpichler.com/podcast/product-teams-in-scrum/): Scrum is a powerful framework that connects the person in charge of the product with the individuals designing and building... - [10 Tips for Effective Product Management Meetings](https://www.romanpichler.com/podcast/10-tips-for-effective-product-management-meetings/): Meetings are essential to align the stakeholders and development team members and make the right product decisions. But we’ve all... - [Six Qualities of a Great Product Vision](https://www.romanpichler.com/podcast/six-qualities-of-a-great-product-vision/): The product vision can be a powerful tool to align stakeholders and development teams. When used effectively, it acts as... - [Why Product Owners Need Effective Scrum Masters](https://www.romanpichler.com/podcast/why-product-owners-need-effective-scrum-masters/): When you consider who is an important partner for you as the person in charge of the product, your thoughts... - [A Learning Roadmap for Product People](https://www.romanpichler.com/podcast/a-learning-roadmap-for-product-people/): Working in product management can be very rewarding. But it can also be very challenging. One of the reasons is... - [Four Product Success Factors](https://www.romanpichler.com/podcast/four-product-success-factors/): Our ultimate goal as product people is to achieve sustained product success: to ensure that our products do a great... - [Dealing with an Underperforming Development Team](https://www.romanpichler.com/podcast/dealing-with-an-underperforming-development-team/): As the person in charge of the product, you rely on the development team to do a good job. But... - [Seven Product Backlog Mistakes to Avoid](https://www.romanpichler.com/podcast/seven-product-backlog-mistakes-to-avoid/): The product backlog is a simple yet powerful tool to capture and revise detailed product decisions and direct the work... - [Three Qualities of Great Product Roadmaps](https://www.romanpichler.com/podcast/three-qualities-of-great-product-roadmaps/): The product roadmap can be an incredibly useful planning tool that aligns the stakeholders and development teams and communicates how... - [Product Vision FAQs](https://www.romanpichler.com/podcast/product-vision-faqs/): The product vision can be a powerful instrument to inspire and align stakeholders and development teams. But in practice, it... - [Tips for Becoming a Head of Product](https://www.romanpichler.com/podcast/tips-for-becoming-a-head-of-product/): Becoming a head of product and managing a group of product people is a significant career step. In this podcast... - [Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams](https://www.romanpichler.com/podcast/making-effective-product-decisions-tips-for-deciding-with-stakeholders-and-dev-teams/): I am a big fan of making decisions collaboratively, as it leverages the expertise of the stakeholders and dev teams;... - [Five Product Owner Myths Busted](https://www.romanpichler.com/podcast/five-product-owner-myths-busted/): The product owner is a role which is often misunderstood and frequently misapplied. In this podcast episode, I address five... - [How to Choose the Right KPIs for Your Product](https://www.romanpichler.com/podcast/how-to-choose-the-right-kpis-for-your-product/): A key challenge of working with KPIs is to select the right indicators: There are so many different metrics to... - [Product Goals in Scrum](https://www.romanpichler.com/podcast/product-goals-in-scrum/): The 2020 edition of the Scrum Guide introduced a new type of goal, the product goal. This episode shares my... - [How Agile Has Changed Product Management](https://www.romanpichler.com/podcast/how-agile-has-changed-product-management/): As the Manifesto for Agile Software Development celebrates its 20th anniversary, I take a look at how agile practices have... - [5 Tips for Saying No to Stakeholders](https://www.romanpichler.com/podcast/5-tips-for-saying-no-to-stakeholders/): Saying no is a firm part of our job as product people: Trying to please everyone and taking on board... - [OKRs in Product Management](https://www.romanpichler.com/podcast/okrs-in-product-management/): OKRs—objectives and key results—have experienced a renewed popularity in recent years. Consequently, I am regularly asked if and how OKRs... - [The Product Strategy Cycle](https://www.romanpichler.com/podcast/the-product-strategy-cycle/): Despite its importance, product strategy is not always effectively practiced. One of the key issues I encounter in my work... - [10 Tips for Creating an Agile Product Roadmap](https://www.romanpichler.com/podcast/10-tips-for-creating-an-agile-product-roadmap/): The product roadmap is a powerful tool to describe how a product is likely to grow, to align the stakeholders,... - [Prioritising a Product Backlog When Everything is Important](https://www.romanpichler.com/podcast/prioritising-a-product-backlog-when-everything-is-important/): The product backlog is an essential product management tool: It captures detailed product decisions and directs the work of the... - [Common Product Vision Board Mistakes](https://www.romanpichler.com/podcast/common-product-vision-board-mistakes/): The product vision board is a simple yet powerful tool to capture the product vision and the product strategy. Despite... - [Are Feature Teams or Component Teams Right for Your Product?](https://www.romanpichler.com/podcast/are-feature-teams-or-component-teams-right-for-your-product/): Whenever you require more than a single development team to progress your product, you have choice: You can organise the... - [Stakeholder Management Tips for Product People](https://www.romanpichler.com/podcast/stakeholder-management-tips-for-product-people/): As product people, we rely on the stakeholders to successfully progress our product. But effective stakeholder management can be challenging.... - [Six Types of “Product” Owners](https://www.romanpichler.com/podcast/six-types-of-product-owners/): Nearly 20 years after the publication of the first Scrum book, the product owner role is still riddled with misunderstandings.... - [Dealing with Difficult Emotions in Product Management](https://www.romanpichler.com/podcast/dealing-with-difficult-emotions-in-product-management/): As product people, we make tough decisions and sometimes, we have to work with challenging people. It is therefore no... - [How to Overcome 6 Key Product Leadership Challenges](https://www.romanpichler.com/podcast/how-to-overcome-6-key-product-leadership-challenges/): Products are developed, provided, and enhanced by people, and effectively leading them is crucial to achieve product success. But leading... - [Leveraging Software Platforms](https://www.romanpichler.com/podcast/leveraging-software-platforms/): Software platforms can be powerful tools to grow a product portfolio and create new revenue streams. However, successfully using them... - [10 Tips for Writing Good User Stories](https://www.romanpichler.com/podcast/10-tips-for-writing-good-user-stories/): User stories are probably the most popular agile technique to capture product functionality: Working with user stories is easy. But... - [Product Manager vs. Product Owner](https://www.romanpichler.com/podcast/product-manager-vs-product-owner/): For many years, people have debated what the difference between the product manager and the product owner role is, if... - [Elements of an Effective Product Strategy](https://www.romanpichler.com/podcast/elements-of-an-effective-product-strategy/): Creating a successful product requires attention to the details, from getting the user interaction and the visual design right to... - [Tips for Creating A Compelling Product Vision](https://www.romanpichler.com/podcast/tips-for-creating-a-compelling-product-vision/): Creating and managing a successful product requires a lot of time and energy. In order to be fully committed, you... # # Detailed Content ## Pages - Published: 2024-05-28 - Modified: 2024-05-28 - URL: https://www.romanpichler.com/cookie-policy/ Please wait while the policy is loaded. If it does not load, please click here. - Published: 2023-11-21 - Modified: 2023-11-21 - URL: https://www.romanpichler.com/tools-2/ Templates - Published: 2022-04-20 - Modified: 2023-07-18 - URL: https://www.romanpichler.com/podcast/interviews-with-roman/ In addition to hosting his own podcast, Roman regularly joins others for discussions about product management. Below are a selection of these conversations. - Published: 2022-03-08 - Modified: 2025-07-07 - URL: https://www.romanpichler.com/essential-articles/ This page provides you with quick access to some of the key articles Roman has written. They are grouped into seven topics: product leadership, product vision and strategy, product roadmaps, product roles, product management processes, product backlog, and learning and development for product professionals. Happy reading! - Published: 2022-03-07 - Modified: 2026-03-30 - URL: https://www.romanpichler.com/training-courses/product-owner-masterclass-course/ Product Owner MasterClass Training | Roman Pichler Coaching Workshops Schedule of Public Workshops Product Strategy & Roadmap Workshop Product Leadership Workshop In-house Workshops Workshop FAQs Books All of Roman’s Books Strategize, 2nd Edition How to Lead in Product Management Agile Product Management with Scrum Scrum Blog See All Blog Posts FAQs Articles Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Essential Articles Videos Podcast See All Podcast Episodes Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Tools All Tools The Product Vision Board GO Product Roadmap The Persona Template Product Canvas Sprint Goal Template Strategy Stack Product Strategy Framework Goal-Setting Framework KPI Selection Framework Feedback Framework Product Management Framework About About Roman Talks Contact Product Owner MasterClass Successfully Discover and Deliver Products with Scrum This training course teaches you to successfully discover and deliver great products with Scrum. This includes understanding the relationship between Scrum and product discovery, collecting user feedback, guiding development teams and aligning stakeholders, scaling the product owner role, systematically connecting the product backlog to strategic objectives, and proactively managing the development effort. Roman delivers his master class as instructor-led workshops with a mix of lectures, discussions, hands-on exercises, and plenty of Q&A. This will allow you to get your questions answered by him and benefit from his 20 years of experience in teaching and coaching Scrum product owners. Additionally, you will be able to transfer theory into practice during the course and apply the learnings to your own work. Please see below for a detailed agenda and student testimonials. You can find out more about Roman’s training approach, payment options, and discounts by visiting the Training FAQs. If you would like this course to be taught for your company or if you have any questions related to the course, please get in touch. Upcoming Classes There are no public Product Owner MasterClasses scheduled at present. Please send an email to training@romanpichler.com if you want Roman to teach the class for your team or to get notified when a public class becomes available. Topics Understand Scrum's Role in Product Innovation Understand how Scrum can help you execute the product strategy, discover the right features and UX, and deliver a product that fulfils its strategic objectives. Apply Scrum at the right stages of the product life cycle to maximise value creation. Be clear on the product strategy work that is required to successfully apply Scrum. Apply the Product Owner Role Effectively Understand the role’s authority and empowerment, its responsibilities and duties, as well as desirable capabilities. Distinguish different ownership levels including product, feature, component, and portfolio. Be clear on the distinction between a Scrum product owner and a product manager and the product owner in SAFe. Address Scrum Master challenges including a Scrum Master role that is vacant and a Scrum Master who is not able to do an effective job. Successfully guide and work with the development team; empower the team and hold people accountable for meeting shared goals. Form Effective Product Teams in Scrum Understand how product teams fit in Scrum teams and what benefits they offer. Find the right team members, including development representatives and Scrum Master. Effectively influence and collaborate with the stakeholders. Learn what it takes to build high-performing product teams. Know how to form product teams in a scaled environment. Connect the Product Backlog to Strategic Outcomes and Objectives Understand the relationship between OKRs and the product backlog. Effectively use product goals to direct, focus, and stock the product backlog even in a scaled environment. Get the relationship between the product backlog and the product roadmap right; choose the right roadmapping approach and format to support an agile way of working. Choose the product backlog size and level of detail that is right for your product and select the right prioritisation techniques. Get the relationship between user journeys and the product backlog right Discover the Right Features and User Experience Understand how to best engage with users and customers in Scrum and learn about research techniques. Move beyond product demos; choose the right methods to validate product increments and gather user feedback and data. Effectively analyse the feedback and data, derive new insights, and update the product backlog. Keep the product backlog and the product roadmap in synch. Avoid common product discovery and backlog mistakes. Successfully Guide Development Teams Leverage the sprint planning meeting: Use shared and actionable... - Published: 2021-12-17 - Modified: 2025-12-10 - URL: https://www.romanpichler.com/tools/romans-product-management-framework/ Roman's Product Management Framework | Roman Pichler Consulting & Coaching Workshops Schedule of Public Workshops Product Strategy & Roadmap Workshop Product Leadership Workshop In-house Workshops Workshop FAQs Books All of Roman’s Books Strategize, 2nd Edition How to Lead in Product Management Agile Product Management with Scrum Scrum Blog See All Blog Posts FAQs Articles Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Essential Articles Videos Podcast See All Podcast Episodes Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Tools All Tools The Product Vision Board GO Product Roadmap The Persona Template Product Canvas Sprint Goal Template Strategy Stack Product Strategy Framework Goal-Setting Framework Feedback Framework KPI Selection Framework Product Management Framework About About Roman Talks Contact Download the Tool Roman's Product Management Framework Roman’s Product Management Framework is a simple yet powerful tool that defines what product management is. It provides six core and six supporting knowledge areas. The former are particularly important to do a great job as a product manager or a product owner. The framework is optimised for the creation and the management of digital products using lean and agile techniques such as Lean Startup and Scrum. Download your copy now to precisely define your role and to see which skills you may be lacking. Learn how to work with the tool Consulting & Coaching If you need help to define product management roles in your organisation or to create a learning and development program for product managers and product owners, then get in touch! Contact Roman Articles Read Roman’s articles related to the product management framework to better understand how apply it. Read Roman's Blog EmailThis field is for validation purposes and should be left unchanged. Download the Tool Please fill out the following form and submit the data. We will then send you an email with the download link. Please check your spam/junk folder if you don’t receive the message. Why do we ask you for this information?First Name*Last Name*Email* Job TitlePlease select...Business AnalystCEOConsultantDesignerDeveloperHead of ProductProduct ManagerProduct OwnerProject ManagerScrumMaster/Agile CoachStudentOtherPlease StateCompanyCountryPlease select...AfghanistanAlbaniaAlgeriaAmerican SamoaAndorraAngolaAntigua and BarbudaArgentinaArmeniaAustraliaAustriaAzerbaijanBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBosnia and HerzegovinaBotswanaBrazilBruneiBulgariaBurkina FasoBurundiCambodiaCameroonCanadaCape VerdeCayman IslandsCentral African RepublicChadChileChinaColombiaComorosCongo, Democratic Republic of theCongo, Republic of theCosta RicaCôte d'IvoireCroatiaCubaCyprusCzech RepublicDenmarkDjiboutiDominicaDominican RepublicEast TimorEcuadorEgyptEl SalvadorEquatorial GuineaEritreaEstoniaEthiopiaFijiFinlandFranceGabonGambiaGeorgiaGermanyGhanaGreeceGreenlandGrenadaGuamGuatemalaGuineaGuinea-BissauGuyanaHaitiHondurasHong KongHungaryIcelandIndiaIndonesiaIranIraqIrelandIsraelItalyJamaicaJapanJordanKazakhstanKenyaKiribatiNorth KoreaSouth KoreaKuwaitKyrgyzstanLaosLatviaLebanonLesothoLiberiaLibyaLiechtensteinLithuaniaLuxembourgMacedoniaMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMauritaniaMauritiusMexicoMicronesiaMoldovaMonacoMongoliaMontenegroMoroccoMozambiqueMyanmarNamibiaNauruNepalNetherlandsNew ZealandNicaraguaNigerNigeriaNorwayNorthern Mariana IslandsOmanPakistanPalauPalestinePanamaPapua New GuineaParaguayPeruPhilippinesPolandPortugalPuerto RicoQatarRomaniaRussiaRwandaSaint Kitts and NevisSaint LuciaSaint Vincent and the GrenadinesSamoaSan MarinoSao Tome and PrincipeSaudi ArabiaSenegalSerbia and MontenegroSeychellesSierra LeoneSingaporeSlovakiaSloveniaSolomon IslandsSomaliaSouth AfricaSpainSri LankaSudanSudan, SouthSurinameSwazilandSwedenSwitzerlandSyriaTaiwanTajikistanTanzaniaThailandTogoTongaTrinidad and TobagoTunisiaTurkeyTurkmenistanTuvaluUgandaUkraineUnited Arab EmiratesUnited KingdomUnited StatesUruguayUzbekistanVanuatuVatican CityVenezuelaVietnamVirgin Islands, BritishVirgin Islands, U.S.YemenZambiaZimbabweThis field is hidden when viewing the formTool Choice Product Vision Board GO Product Roadmap Product Management Framework Product Canvas The Persona Template Sprint Goal Template Product Scorecard GO Portfolio Roadmap Product Owner Guide Decision Making Chart Product Vision Board Version* Standard Extended Sign up to news from Roman! I am happy to hear about new content, new talks and training courses, and more. Sign up for great new content from Roman Hear about his latest product management work including new articles, videos, podcast episodes, and more. Email Expert Consulting & Coaching for Product Leaders About Roman Contact Roman Ask Roman to Coach You and Your Team Ask Roman to Give a Talk Attend Roman’s Training Product Leadership Workshop Product Strategy & Roadmap Training In-house Training Workshop FAQs Learn More Roman’s Books Roman’s Blog Roman’s Videos Roman’s Podcast Roman’s Tools Follow Roman LinkedIn YouTube Instagram Facebook RSS Feeds Blog Podcast Pichler Consulting Limited Privacy Policy Sitemap - Published: 2021-12-17 - Modified: 2026-03-30 - URL: https://www.romanpichler.com/tools/the-go-product-roadmap/ GO Product Roadmap | Roman Pichler Coaching Workshops Schedule of Public Workshops Product Strategy & Roadmap Workshop Product Leadership Workshop In-house Workshops Workshop FAQs Books All of Roman’s Books Strategize, 2nd Edition How to Lead in Product Management Agile Product Management with Scrum Scrum Blog See All Blog Posts FAQs Articles Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Essential Articles Videos Podcast See All Podcast Episodes Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Tools All Tools The Product Vision Board GO Product Roadmap The Persona Template Product Canvas Sprint Goal Template Strategy Stack Product Strategy Framework Goal-Setting Framework KPI Selection Framework Feedback Framework Product Management Framework About About Roman Talks Contact Download the Tool The GO Product Roadmap Unlike traditional, feature-based product roadmaps, the GO Product Roadmap is goal-oriented (hence the name). Its goals describe outcomes or benefits such as user acquisition, activation, and retention, which form the backbone of the plan. This shifts the conversation from debating features to creating value, making smart investment decisions, and aligning stakeholders and development teams. 🔥 The GO Product Roadmap now comes with a handy checklist to help you effectively apply the tool! Learn how to work with the tool Workshops You can learn more about working with the GO product roadmap by attending Roman’s Product Strategy and Roadmap workshop. You will learn how to build an effective goal-oriented, outcome-based roadmap that is connected to the product strategy and product roadmap, supported by the stakeholders and dev teams, and regularly reviewed and updated. Attend the Workshop Book Roman’s book Strategize: Product Strategy and Product Roadmap Practices for the Digital Age features the GO product roadmap, and it provides more information on how to effectively work with product roadmaps. Read the Book More Information on Strategize Video The following video provides an introduction to the GO product roadmap. Articles Read Roman’s articles related to the GO Product Roadmap to better understand how to use the tool.​ Read the Articles CommentsThis field is for validation purposes and should be left unchanged. Download the Tool Please fill out the following form and submit the data. We will then send you an email with the download link. Please check your spam/junk folder if you don’t receive the message. Why do we ask you for this information?First Name*Last Name*Email* Job TitlePlease select...Business AnalystCEOConsultantDesignerDeveloperHead of ProductProduct ManagerProduct OwnerProject ManagerScrumMaster/Agile CoachStudentOtherPlease StateCompanyCountryPlease select...AfghanistanAlbaniaAlgeriaAmerican SamoaAndorraAngolaAntigua and BarbudaArgentinaArmeniaAustraliaAustriaAzerbaijanBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBosnia and HerzegovinaBotswanaBrazilBruneiBulgariaBurkina FasoBurundiCambodiaCameroonCanadaCape VerdeCayman IslandsCentral African RepublicChadChileChinaColombiaComorosCongo, Democratic Republic of theCongo, Republic of theCosta RicaCôte d'IvoireCroatiaCubaCyprusCzech RepublicDenmarkDjiboutiDominicaDominican RepublicEast TimorEcuadorEgyptEl SalvadorEquatorial GuineaEritreaEstoniaEthiopiaFijiFinlandFranceGabonGambiaGeorgiaGermanyGhanaGreeceGreenlandGrenadaGuamGuatemalaGuineaGuinea-BissauGuyanaHaitiHondurasHong KongHungaryIcelandIndiaIndonesiaIranIraqIrelandIsraelItalyJamaicaJapanJordanKazakhstanKenyaKiribatiNorth KoreaSouth KoreaKuwaitKyrgyzstanLaosLatviaLebanonLesothoLiberiaLibyaLiechtensteinLithuaniaLuxembourgMacedoniaMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMauritaniaMauritiusMexicoMicronesiaMoldovaMonacoMongoliaMontenegroMoroccoMozambiqueMyanmarNamibiaNauruNepalNetherlandsNew ZealandNicaraguaNigerNigeriaNorwayNorthern Mariana IslandsOmanPakistanPalauPalestinePanamaPapua New GuineaParaguayPeruPhilippinesPolandPortugalPuerto RicoQatarRomaniaRussiaRwandaSaint Kitts and NevisSaint LuciaSaint Vincent and the GrenadinesSamoaSan MarinoSao Tome and PrincipeSaudi ArabiaSenegalSerbia and MontenegroSeychellesSierra LeoneSingaporeSlovakiaSloveniaSolomon IslandsSomaliaSouth AfricaSpainSri LankaSudanSudan, SouthSurinameSwazilandSwedenSwitzerlandSyriaTaiwanTajikistanTanzaniaThailandTogoTongaTrinidad and TobagoTunisiaTurkeyTurkmenistanTuvaluUgandaUkraineUnited Arab EmiratesUnited KingdomUnited StatesUruguayUzbekistanVanuatuVatican CityVenezuelaVietnamVirgin Islands, BritishVirgin Islands, U.S.YemenZambiaZimbabweThis field is hidden when viewing the formTool Choice Product Vision Board GO Product Roadmap Product Management Framework Product Canvas The Persona Template Sprint Goal Template Product Scorecard GO Portfolio Roadmap Product Owner Guide Decision Making Chart Product Vision Board Version* Standard Extended Sign up to news from Roman! I am happy to hear about new content, new talks and training courses, and more. Sign up for great new content from Roman Hear about his latest product management work including new articles, videos, podcast episodes, and more. Email Expert Consulting and Coaching for Product Leaders and Product Teams About Roman Contact Roman Ask Roman to Coach You and Your Team Ask Roman to Give a Talk Roman’s Workshops Product Leadership Workshop Product Strategy & Roadmap Workshop In-house Workshops Workshop FAQs Learn More Roman’s Books Roman’s Blog Roman’s Videos Roman’s Podcast Roman’s Tools Follow Roman LinkedIn YouTube Instagram RSS Feeds Blog Podcast © 2026 Pichler Consulting Limited Privacy Policy Sitemap - Published: 2021-12-17 - Modified: 2026-03-30 - URL: https://www.romanpichler.com/tools/the-descision-making-chart/ The Decision Making Chart | Roman Pichler Coaching Workshops Schedule of Public Workshops Product Strategy & Roadmap Workshop Product Leadership Workshop In-house Workshops Workshop FAQs Books All of Roman’s Books Strategize, 2nd Edition How to Lead in Product Management Agile Product Management with Scrum Scrum Blog See All Blog Posts FAQs Articles Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Essential Articles Videos Podcast See All Podcast Episodes Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Tools All Tools The Product Vision Board GO Product Roadmap The Persona Template Product Canvas Sprint Goal Template Strategy Stack Product Strategy Framework Goal-Setting Framework KPI Selection Framework Feedback Framework Product Management Framework About About Roman Talks Contact Download the Tool The Decision Making Chart As the person in charge of the product, you make a myriad of decisions—from determining the product strategy and creating the product roadmap to deciding the detailed functionality of your product. But do you make all these decisions effectively? And do you secure the necessary buy-in? This infographic helps you make better decisions. It visualises five common decision rules and shows when to apply them. Learn how to work with the tool Workshops You can learn more about making effective product decisions by attending Roman’s Product Leadership Workshop. It teaches you how to effectively apply the decision rules shown on the chart and how to secure strong support for your decisions. Attend the Workshop Book Roman’s book How to Lead in Product Management shares valuable decision-making tips for product people and discusses decision rules like consent and unanimous agreement in detail. Buy the Book More Information on Roman's book Articles Read Roman’s articles related to the Decision Making Chart to better understand how to use it. Read the Articles LinkedInThis field is for validation purposes and should be left unchanged. Download the Tool Please fill out the following form and submit the data. We will then send you an email with the download link. Please check your spam/junk folder if you don’t receive the message. Why do we ask you for this information?First Name*Last Name*Email* Job TitlePlease select...Business AnalystCEOConsultantDesignerDeveloperHead of ProductProduct ManagerProduct OwnerProject ManagerScrumMaster/Agile CoachStudentOtherPlease StateCompanyCountryPlease select...AfghanistanAlbaniaAlgeriaAmerican SamoaAndorraAngolaAntigua and BarbudaArgentinaArmeniaAustraliaAustriaAzerbaijanBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBosnia and HerzegovinaBotswanaBrazilBruneiBulgariaBurkina FasoBurundiCambodiaCameroonCanadaCape VerdeCayman IslandsCentral African RepublicChadChileChinaColombiaComorosCongo, Democratic Republic of theCongo, Republic of theCosta RicaCôte d'IvoireCroatiaCubaCyprusCzech RepublicDenmarkDjiboutiDominicaDominican RepublicEast TimorEcuadorEgyptEl SalvadorEquatorial GuineaEritreaEstoniaEthiopiaFijiFinlandFranceGabonGambiaGeorgiaGermanyGhanaGreeceGreenlandGrenadaGuamGuatemalaGuineaGuinea-BissauGuyanaHaitiHondurasHong KongHungaryIcelandIndiaIndonesiaIranIraqIrelandIsraelItalyJamaicaJapanJordanKazakhstanKenyaKiribatiNorth KoreaSouth KoreaKuwaitKyrgyzstanLaosLatviaLebanonLesothoLiberiaLibyaLiechtensteinLithuaniaLuxembourgMacedoniaMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMauritaniaMauritiusMexicoMicronesiaMoldovaMonacoMongoliaMontenegroMoroccoMozambiqueMyanmarNamibiaNauruNepalNetherlandsNew ZealandNicaraguaNigerNigeriaNorwayNorthern Mariana IslandsOmanPakistanPalauPalestinePanamaPapua New GuineaParaguayPeruPhilippinesPolandPortugalPuerto RicoQatarRomaniaRussiaRwandaSaint Kitts and NevisSaint LuciaSaint Vincent and the GrenadinesSamoaSan MarinoSao Tome and PrincipeSaudi ArabiaSenegalSerbia and MontenegroSeychellesSierra LeoneSingaporeSlovakiaSloveniaSolomon IslandsSomaliaSouth AfricaSpainSri LankaSudanSudan, SouthSurinameSwazilandSwedenSwitzerlandSyriaTaiwanTajikistanTanzaniaThailandTogoTongaTrinidad and TobagoTunisiaTurkeyTurkmenistanTuvaluUgandaUkraineUnited Arab EmiratesUnited KingdomUnited StatesUruguayUzbekistanVanuatuVatican CityVenezuelaVietnamVirgin Islands, BritishVirgin Islands, U.S.YemenZambiaZimbabweThis field is hidden when viewing the formTool Choice Product Vision Board GO Product Roadmap Product Management Framework Product Canvas The Persona Template Sprint Goal Template Product Scorecard GO Portfolio Roadmap Product Owner Guide Decision Making Chart Product Vision Board Version* Standard Extended Sign up to news from Roman! I am happy to hear about new content, new talks and training courses, and more. Sign up for great new content from Roman Hear about his latest product management work including new articles, videos, podcast episodes, and more. Email Expert Consulting and Coaching for Product Leaders and Product Teams About Roman Contact Roman Ask Roman to Coach You and Your Team Ask Roman to Give a Talk Roman’s Workshops Product Leadership Workshop Product Strategy & Roadmap Workshop In-house Workshops Workshop FAQs Learn More Roman’s Books Roman’s Blog Roman’s Videos Roman’s Podcast Roman’s Tools Follow Roman LinkedIn YouTube Instagram RSS Feeds Blog Podcast © 2026 Pichler Consulting Limited Privacy Policy Sitemap - Published: 2021-12-17 - Modified: 2026-03-30 - URL: https://www.romanpichler.com/tools/product-vision-board/ The Official Product Vision Board | Roman Pichler Coaching Workshops Schedule of Public Workshops Product Strategy & Roadmap Workshop Product Leadership Workshop In-house Workshops Workshop FAQs Books All of Roman’s Books Strategize, 2nd Edition How to Lead in Product Management Agile Product Management with Scrum Scrum Blog See All Blog Posts FAQs Articles Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Essential Articles Videos Podcast See All Podcast Episodes Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Tools All Tools The Product Vision Board GO Product Roadmap The Persona Template Product Canvas Sprint Goal Template Strategy Stack Product Strategy Framework Goal-Setting Framework KPI Selection Framework Feedback Framework Product Management Framework About About Roman Talks Contact Download the Tool The Official Product Vision Board The Product Vision Board, first created by Roman in 2011, helps you describe, visualise, and validate your product vision and product strategy. It captures the target group, needs, key features, and business goals. It comes with a handy checklist to help you effectively apply the tool. The extended board contains additional business model elements including competitors, revenue sources, cost factors, and channels. Learn how to work with the tool Workshops You can learn more about working with the Product Vision Board, setting an inspiring vision, and creating an effective product strategy by attending Roman’s Product Strategy and Roadmap workshop. Attend the Workshop Book Roman’s book Strategize: Product Strategy and Product Roadmap Practices for the Digital Age features the Product Vision Board and explains how you can use it to capture and validate your product strategy. Buy the Book More Information on Strategize Video Articles Read Roman’s articles on product vision and strategy to understand how you can apply the Product Vision Board.​ Read the Articles CompanyThis field is for validation purposes and should be left unchanged. Download the Tool Please fill out the following form and submit the data. We will then send you an email with the download link. Please check your spam/junk folder if you don’t receive the message. Why do we ask you for this information?First Name*Last Name*Email* Job TitlePlease select...Business AnalystCEOConsultantDesignerDeveloperHead of ProductProduct ManagerProduct OwnerProject ManagerScrumMaster/Agile CoachStudentOtherPlease StateCompanyCountryPlease select...AfghanistanAlbaniaAlgeriaAmerican SamoaAndorraAngolaAntigua and BarbudaArgentinaArmeniaAustraliaAustriaAzerbaijanBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBosnia and HerzegovinaBotswanaBrazilBruneiBulgariaBurkina FasoBurundiCambodiaCameroonCanadaCape VerdeCayman IslandsCentral African RepublicChadChileChinaColombiaComorosCongo, Democratic Republic of theCongo, Republic of theCosta RicaCôte d'IvoireCroatiaCubaCyprusCzech RepublicDenmarkDjiboutiDominicaDominican RepublicEast TimorEcuadorEgyptEl SalvadorEquatorial GuineaEritreaEstoniaEthiopiaFijiFinlandFranceGabonGambiaGeorgiaGermanyGhanaGreeceGreenlandGrenadaGuamGuatemalaGuineaGuinea-BissauGuyanaHaitiHondurasHong KongHungaryIcelandIndiaIndonesiaIranIraqIrelandIsraelItalyJamaicaJapanJordanKazakhstanKenyaKiribatiNorth KoreaSouth KoreaKuwaitKyrgyzstanLaosLatviaLebanonLesothoLiberiaLibyaLiechtensteinLithuaniaLuxembourgMacedoniaMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMauritaniaMauritiusMexicoMicronesiaMoldovaMonacoMongoliaMontenegroMoroccoMozambiqueMyanmarNamibiaNauruNepalNetherlandsNew ZealandNicaraguaNigerNigeriaNorwayNorthern Mariana IslandsOmanPakistanPalauPalestinePanamaPapua New GuineaParaguayPeruPhilippinesPolandPortugalPuerto RicoQatarRomaniaRussiaRwandaSaint Kitts and NevisSaint LuciaSaint Vincent and the GrenadinesSamoaSan MarinoSao Tome and PrincipeSaudi ArabiaSenegalSerbia and MontenegroSeychellesSierra LeoneSingaporeSlovakiaSloveniaSolomon IslandsSomaliaSouth AfricaSpainSri LankaSudanSudan, SouthSurinameSwazilandSwedenSwitzerlandSyriaTaiwanTajikistanTanzaniaThailandTogoTongaTrinidad and TobagoTunisiaTurkeyTurkmenistanTuvaluUgandaUkraineUnited Arab EmiratesUnited KingdomUnited StatesUruguayUzbekistanVanuatuVatican CityVenezuelaVietnamVirgin Islands, BritishVirgin Islands, U.S.YemenZambiaZimbabweThis field is hidden when viewing the formTool Choice Product Vision Board GO Product Roadmap Product Management Framework Product Canvas The Persona Template Sprint Goal Template Product Scorecard GO Portfolio Roadmap Product Owner Guide Decision Making Chart Product Vision Board Version* Standard Extended Sign up to news from Roman! I am happy to hear about new content, new talks and training courses, and more. Sign up for great new content from Roman Hear about his latest product management work including new articles, videos, podcast episodes, and more. Email Expert Consulting and Coaching for Product Leaders and Product Teams About Roman Contact Roman Ask Roman to Coach You and Your Team Ask Roman to Give a Talk Roman’s Workshops Product Leadership Workshop Product Strategy & Roadmap Workshop In-house Workshops Workshop FAQs Learn More Roman’s Books Roman’s Blog Roman’s Videos Roman’s Podcast Roman’s Tools Follow Roman LinkedIn YouTube Instagram RSS Feeds Blog Podcast © 2026 Pichler Consulting Limited Privacy Policy Sitemap - Published: 2021-12-17 - Modified: 2026-03-30 - URL: https://www.romanpichler.com/the-persona-template/ The Persona Template | Roman Pichler Coaching Workshops Schedule of Public Workshops Product Strategy & Roadmap Workshop Product Leadership Workshop In-house Workshops Workshop FAQs Books All of Roman’s Books Strategize, 2nd Edition How to Lead in Product Management Agile Product Management with Scrum Scrum Blog See All Blog Posts FAQs Articles Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Essential Articles Videos Podcast See All Podcast Episodes Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Tools All Tools The Product Vision Board GO Product Roadmap The Persona Template Product Canvas Sprint Goal Template Strategy Stack Product Strategy Framework Goal-Setting Framework KPI Selection Framework Feedback Framework Product Management Framework About About Roman Talks Contact Download the Tool The Persona Template Personas are a powerful technique to capture our knowledge about the users and customers of a product. But some persona descriptions are too detailed and bloated; others lack important information. Roman’s persona template is simple yet effective: It helps you create powerful personas that contain just the right information; and it is optimised for an agile way of working where starting with provisional personas is often the preferred approach. The template captures the persona’s picture and name; the persona’s details including demographics, lifestyle, and job-related information; and the persona’s goal: the benefits to be achieved or the problems to be solved, and the reason why the persona would want to use or purchase the product. Learn how to work with the tool Workshops You can learn more about personas by attending Roman’s Product Strategy and Roadmap workshop, where you will learn what it takes to select and describe the right target group for your product. Attend the Workshop Book I discuss personas in my book Strategize: Product Strategy and Product Roadmap Practices for the Digital Age. While the discussion is brief, it shows you how you can use personas to develop a winning product strategy. Buy the book More Information Video You can find out more about the Persona Template by watching Roman’s video over in the video section of the site. Articles You can find more information on personas by reading articles on Roman’s Blog. Read the Articles URLThis field is for validation purposes and should be left unchanged. Download the Tool Please fill out the following form and submit the data. We will then send you an email with the download link. Please check your spam/junk folder if you don’t receive the message. Why do we ask you for this information?First Name*Last Name*Email* Job TitlePlease select...Business AnalystCEOConsultantDesignerDeveloperHead of ProductProduct ManagerProduct OwnerProject ManagerScrumMaster/Agile CoachStudentOtherPlease StateCompanyCountryPlease select...AfghanistanAlbaniaAlgeriaAmerican SamoaAndorraAngolaAntigua and BarbudaArgentinaArmeniaAustraliaAustriaAzerbaijanBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBosnia and HerzegovinaBotswanaBrazilBruneiBulgariaBurkina FasoBurundiCambodiaCameroonCanadaCape VerdeCayman IslandsCentral African RepublicChadChileChinaColombiaComorosCongo, Democratic Republic of theCongo, Republic of theCosta RicaCôte d'IvoireCroatiaCubaCyprusCzech RepublicDenmarkDjiboutiDominicaDominican RepublicEast TimorEcuadorEgyptEl SalvadorEquatorial GuineaEritreaEstoniaEthiopiaFijiFinlandFranceGabonGambiaGeorgiaGermanyGhanaGreeceGreenlandGrenadaGuamGuatemalaGuineaGuinea-BissauGuyanaHaitiHondurasHong KongHungaryIcelandIndiaIndonesiaIranIraqIrelandIsraelItalyJamaicaJapanJordanKazakhstanKenyaKiribatiNorth KoreaSouth KoreaKuwaitKyrgyzstanLaosLatviaLebanonLesothoLiberiaLibyaLiechtensteinLithuaniaLuxembourgMacedoniaMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMauritaniaMauritiusMexicoMicronesiaMoldovaMonacoMongoliaMontenegroMoroccoMozambiqueMyanmarNamibiaNauruNepalNetherlandsNew ZealandNicaraguaNigerNigeriaNorwayNorthern Mariana IslandsOmanPakistanPalauPalestinePanamaPapua New GuineaParaguayPeruPhilippinesPolandPortugalPuerto RicoQatarRomaniaRussiaRwandaSaint Kitts and NevisSaint LuciaSaint Vincent and the GrenadinesSamoaSan MarinoSao Tome and PrincipeSaudi ArabiaSenegalSerbia and MontenegroSeychellesSierra LeoneSingaporeSlovakiaSloveniaSolomon IslandsSomaliaSouth AfricaSpainSri LankaSudanSudan, SouthSurinameSwazilandSwedenSwitzerlandSyriaTaiwanTajikistanTanzaniaThailandTogoTongaTrinidad and TobagoTunisiaTurkeyTurkmenistanTuvaluUgandaUkraineUnited Arab EmiratesUnited KingdomUnited StatesUruguayUzbekistanVanuatuVatican CityVenezuelaVietnamVirgin Islands, BritishVirgin Islands, U.S.YemenZambiaZimbabweThis field is hidden when viewing the formTool Choice Product Vision Board GO Product Roadmap Product Management Framework Product Canvas The Persona Template Sprint Goal Template Product Scorecard GO Portfolio Roadmap Product Owner Guide Decision Making Chart Product Vision Board Version* Standard Extended Sign up to news from Roman! I am happy to hear about new content, new talks and training courses, and more. Sign up for great new content from Roman Hear about his latest product management work including new articles, videos, podcast episodes, and more. Email Expert Consulting and Coaching for Product Leaders and Product Teams About Roman Contact Roman Ask Roman to Coach You and Your Team Ask Roman to Give a Talk Roman’s Workshops Product Leadership Workshop Product Strategy & Roadmap Workshop In-house Workshops Workshop FAQs Learn More Roman’s Books Roman’s Blog Roman’s Videos Roman’s Podcast Roman’s Tools Follow Roman LinkedIn YouTube Instagram RSS Feeds Blog Podcast © 2026 Pichler Consulting Limited Privacy Policy Sitemap - Published: 2021-12-17 - Modified: 2023-07-30 - URL: https://www.romanpichler.com/romans-books/agile-product-management-with-scrum/ Creating Products that Customers Love  Agile Product Management with Scrum explains how product owners can create successful products with Scrum. The book describes a broad range of agile product management practices, including making agile product discovery work, taking advantage of emergent requirements, creating the minimal marketable product, leveraging early customer feedback, and working closely with the development team. Benefitting from Roman's extensive experience, you’ll learn how Scrum product ownership differs from traditional product management and how to avoid and overcome the common challenges that Scrum product owners face. The book has been translated into several languages, including Chinese, German, Japanese, Korean, Polish, Portuguese, and Russian. - Published: 2021-12-17 - Modified: 2025-03-03 - URL: https://www.romanpichler.com/romans-books/how-to-lead-in-product-management/ Practices to Align Stakeholders, Guide Development Teams, and Create Value Together Reading this book will help you become a better and inspiring product leader. Benefitting from Roman’s extensive experience, you will learn how to align stakeholders and guide development teams even in challenging circumstances, avoid common leadership mistakes, and grow as an individual and leader. Written in an engaging and easily accessible style, it offers a wealth of practical tips and strategies. Through helpful examples, the book illustrates how you can directly apply the techniques to your work. The book is available as a paperback and Kindle on Amazon, as an ebook on Google Play Books and on Apple Books, and as an audiobook on Audible. It has also been translated into German. - Published: 2021-12-17 - Modified: 2022-02-11 - URL: https://www.romanpichler.com/romans-books/scrum/ Applying Agile Project Management Successfully Roman’s first book, published in December 2007, provides a comprehensive yet concise guide to applying Scrum successfully. It's full of practical tips to help the reader understand and implement Scrum. The book is written in German. "I've known and worked with Roman for years with Scrum, so the book is full of practical advice. This book not only faithfully documents Scrum, it also provides a state of the art view of the most current thinking about using Scrum. This book is a solid addition to the compendium of books to aid the Scrum practitioner. " Ken Schwaber, co-creator of Scrum - Published: 2021-12-17 - Modified: 2026-07-17 - URL: https://www.romanpichler.com/romans-books/strategize/ Product Strategy and Product Roadmap Practices for the Digital Age AI is transforming how digital products are conceived, built, and delivered—but it hasn't made product strategy less important. The opposite is true: As AI accelerates product development and lowers the cost of building features, deciding what to build, who to build it for, and how to create lasting customer value has become the defining competitive advantage. Using a wide range of proven techniques and tools, Strategize explains how to create effective strategies and actionable roadmaps to help you maximise your chances of building successful products. Written in an engaging and no-nonsense style, Strategize offers practical advice and concrete examples so that you can apply the practices directly to your products. Comprehensive and insightful, the book will enable you to make the right strategic decisions in today’s dynamic age. If you work as a product manager, product builder/AI product manager, Scrum product owner, product portfolio manager, Head of Product, Chief Product Officer (CPO), or product coach, then this book is for you. Strategize is also available in German! - Published: 2019-09-18 - Modified: 2026-03-28 - URL: https://www.romanpichler.com/consulting-and-coaching/ Coaching Programs Roman offers tailored coaching and consulting to help product leaders and their teams develop winning strategies, foster effective collaboration, and deliver successful products. Drawing on decades of hands-on experience in product leadership and strategy, Roman works directly with you to address your actual challenges—whether it's leveraging AI in product management, defining a clear product vision, creating a winning strategy, or embracing a product-focused way of working. Here are examples of how he has helped his clients: Creating effective product strategies at BP, SAI Global, and WorldFirst Building actionable product and portfolio roadmaps at Zeiss Meditec, FT. com and Philips Lighting Establishing the right product portfolio management approach at Siemens Industrial Solutions Leveraging the product operating model at L&G, Alliance, Lloyds Bank, and Sainsbury’s "Roman brought his deep expertise in product management and a thoughtful, structured approach to help us transition from traditional feature-based roadmaps to outcome-based ones. He worked with senior leadership, ensuring alignment and buy-in across the organization. He also provided hands-on training and one-on-one coaching to our product management team, equipping them with the tools and confidence to apply the new approach effectively. Roman didn’t just deliver a framework—he helped drive real change. I highly recommend Roman to any organization looking to elevate their product management practices and embed outcome-driven thinking into their strategy and execution. " —Bob Gibson, Vice President, Head of Product & Solutions, Ophthalmic Diagnostics Devices, ZEISS Meditec Inc. "Roman delivered a highly engaging and interactive product strategy workshop for us. He was able to get us all on the same page and provide us with some extremely practical tools for driving our product strategy forward. " —Paula Davis, VP of Product Strategy at SAI Global "Roman has been an amazing support for all of us at World First! he's helped us handle the product vision and roadmapping challenges we face. Making the complex abundantly clear, he's a real inspiration. Thank you, Roman! " —Rebecca Watkin, Product Lead at WorldFirst Do you have a product management challenge you need help with, or do you want to increase the effectiveness of your product teams? Then please get in touch. Contact Roman - Published: 2019-07-16 - Modified: 2022-10-06 - URL: https://www.romanpichler.com/roman-pichlers-product-owner-masterclass-thank-you/ Thank you for registering. Roman is looking forward to seeing you! You will shortly receive a confirmation email with the training details. Don't hesitate to contact us if you have any questions or concerns. - Published: 2019-07-11 - Modified: 2026-06-08 - URL: https://www.romanpichler.com/talks/ Invite Roman to speak at your next conference, corporate event, or internal product summit. As an internationally recognised authority on product strategy, leadership, and agility, Roman delivers engaging, insight-rich talks that inspire product professionals. Organisations that have benefited from his talks include the following: Roman offers his talks as a presentation followed by Q&A and as interactive ask-me-anything (AMA) sessions that are focused on a specific topic like establishing the right product roles or effectively using product roadmaps. Yesterday our product team and a group of stakeholders had the exciting opportunity to learn from Roman Pichler on all things Product Roadmaps, having an outcome-based approach, OKRs and how this links to Product Strategy and Vision. It was a really insightful talk, which will help us improve how we work. Thanks Roman for sharing your knowledge with us! Aimee Graham, Product Lead at NHS Business Services Authority To better understand how Roman delivers his talks, please take a look at his YouTube channel. Contact Roman discuss how you can benefit from one of his talks. - Published: 2019-06-12 - Modified: 2025-12-12 - URL: https://www.romanpichler.com/privacy-policy/ Please wait while the policy is loaded. If it does not load, please click here. - Published: 2019-06-12 - Modified: 2023-04-09 - URL: https://www.romanpichler.com/sitemap/ Pages About Roman Coaching and Consulting Company-internal Talks Cookie Policy Essential Articles Expert Coaching and Training in Product Management Get in touch Keep up to date with the latest from Roman Privacy Policy Product Management Videos Roman Pichler’s Agile Product Strategy and Roadmap Course Roman Pichler’s Product Management Blog Roman Pichler’s Product Owner Master Class Roman’s Books Agile Product Management with Scrum How to Lead in Product Management Scrum Strategize, 2nd Edition Roman’s Product Management Podcast Podcast Interviews with Roman Roman’s Product Management Vlog Sitemap test Thank you Thank you The Persona Template Tools Tools GO Product Roadmap Roman’s Product Management Framework The Decision Making Chart The Official Product Vision Board The Product Canvas The Sprint Goal Template Training Courses Product Leadership Training Product Owner MasterClass Product Strategy & Roadmap Training FAQs Workflow Inbox - Published: 2019-06-10 - Modified: 2026-07-09 - URL: https://www.romanpichler.com/training-courses/product-strategy-roadmap/ Product Strategy & Roadmap Workshops Coaching Workshops Schedule of Public Workshops Product Strategy & Roadmap Workshop Product Leadership Workshop In-house Workshops Workshop FAQs Books All of Roman’s Books Strategize, 2nd Edition How to Lead in Product Management Agile Product Management with Scrum Scrum Blog See All Blog Posts FAQs Articles Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Essential Articles Videos Podcast See All Podcast Episodes Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Tools All Tools The Product Vision Board GO Product Roadmap The Persona Template Product Canvas Sprint Goal Template Strategy Stack Product Strategy Framework Goal-Setting Framework KPI Selection Framework Feedback Framework Product Management Framework About About Roman Talks Contact Product Strategy and Roadmap Workshop Develop a Winning Product Strategy, Build an Impactful Roadmap, and Maximise the Value of Your Product Portfolio This hands-on workshop teaches you how to create a winning product strategy and a compelling product roadmap that create real impact and drive the development of a successful product. In the age of AI, making the right strategic choices matters more than ever: An effective strategy creates clarity. It guides and empowers teams, and it helps solve real user problems and create lasting value. It reduces the risk of building something fast that nobody wants or needs. Roman’s workshop equips you with the right tools to make effective strategic choices, and it shares plenty of real-life examples. During the workshop, you will be able to transfer theory into practice and create a vision, product strategy, and outcome-based roadmap for your own product. Due to the small class size, you’ll have plenty of opportunities to get your questions directly answered by Roman. The workshop is based on Roman’s decade-long experience of helping product leaders and product teams create effective strategies and roadmaps. It is inspired by his book Strategize and teaches his latest insights, together with new tools and techniques that help you make the right strategic choices even in turbulent times. What you will learn Create a successful product strategy and proactively evolve it across the product life cycle. Leverage AI to identify strategic opportunities, adapt the strategy, and ensure your product is effectively differentiated. Build an outcome-based product roadmap that implements the strategy and directs the product backlog. Systematically connect product strategy, OKRs, and KPIs. Develop an effective product portfolio strategy and connect the company, portfolio, and product strategies. Collaborate on strategic decisions with key stakeholders and secure their buy-in. Who the workshop is for The workshop is ideal for people who want to make better strategic product and portfolio decisions. This includes product managers, product builders, AI product managers, product owners, product portfolio managers, founders, and product executives, like a Head of Product and Chief Product Officer (CPO). How the workshop is delivered Roman delivers the workshop through a mix of lectures, discussions, hands-on exercises, and plenty of Q&A. This will allow you to transfer theory into practice, get your questions answered by him, and benefit from his extensive experience in crafting effective product strategies and roadmaps. Agenda, testimonials, and more information Please see below for a detailed agenda and student testimonials. You can find out more about Roman’s approach, payment options, class size, and discounts in the FAQs section below. If you have any questions or would like this workshop to be delivered in-house, please get in touch. Upcoming Workshops November 10, 2026 13:00 - 18:00 November 11, 2026 13:00 - 18:00 November 12, 2026 13:00 - 17:30 Online , Time zone: GMT / UTC (GMT+0) X Ticket price: £1,100-£1,250 (plus VAT) Register Agenda Create an Inspiring Vision and Effective Product Strategy Understand the relationship between business strategy, product vision, product strategy, product roadmap, and product backlog using Roman’s Strategy Stack and Product Strategy Model. Formulate an inspiring product vision and capture an effective product strategy with the Product Vision Board. Get the value proposition, market segmentation, and product differentiation right. Understand the relationship between business strategy, product portfolio strategy, and product strategy. Learn who needs to be involved in creating an effective product strategy and how to secure their buy-in. Know how AI can assist you in crafting an effective strategy. Validate the Product Strategy to Maximise Product Success Apply a risk-driven, iterative approach to validate the strategy: Identifying the key risks using desirability, viability, feasibility, and ethicality. Learn how AI can help you validate strategic decisions. Select... - Published: 2019-05-31 - Modified: 2026-06-25 - URL: https://www.romanpichler.com/training-courses/product-leadership/ Product Leadership Workshop Coaching Workshops Schedule of Public Workshops Product Strategy & Roadmap Workshop Product Leadership Workshop In-house Workshops Workshop FAQs Books All of Roman’s Books Strategize, 2nd Edition How to Lead in Product Management Agile Product Management with Scrum Scrum Blog See All Blog Posts FAQs Articles Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Essential Articles Videos Podcast See All Podcast Episodes Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Tools All Tools The Product Vision Board GO Product Roadmap The Persona Template Product Canvas Sprint Goal Template Strategy Stack Product Strategy Framework Goal-Setting Framework KPI Selection Framework Feedback Framework Product Management Framework About About Roman Talks Contact Product Leadership Workshop Successfully Manage Stakeholders, Build High-Performing Product Teams, and Become an Inspiring Product Leader Level up your leadership skills! This collaborative workshop teaches you how to successfully manage stakeholders, build high-performing product teams, and become an inspiring product leader. With the rise of AI, strong leadership has never been more important. It ensures that teams stay focused on user value, business outcomes, and ethical boundaries—not just adding new tech. In a small-group setting, you will learn proven product leadership techniques and tools that you can immediately apply to increase your influence and authority, achieve greater alignment, set the right goals, secure strong buy-in to product decisions, and successfully deal with challenging people. What’s more, the workshop is not just theory: You’ll apply some of the learnings to your specific leadership challenges. This includes working on your leadership style, improving the goals and outcomes you set, and addressing a recent disagreement. The workshop is based on Roman’s extensive experience of coaching product leaders and product teams. It is inspired by his book How to Lead in Product Management and teaches his latest insights, together with new tools and techniques. Who the workshop is for The workshop is ideal for product professionals who want to get better at leading others and take on a senior product role. This includes product managers, product owners, and product executives, like a Head of Product and Chief Product Officer. How the workshop is delivered Roman delivers the workshop through a mix of lectures, discussions, hands-on exercises, and plenty of Q&A. This will allow you to transfer theory into practice, get your questions answered by him, and benefit from his decade-long experience in working with product leaders. Agenda, testimonials, and more information Please see below for a detailed agenda and student testimonials. You can find out more about Roman’s approach, payment options, workshop size, and discounts in the FAQs section below. If you have any questions or would like this course to be taught in-house, please get in touch. Upcoming Workshops October 13, 2026 13:00 - 18:00 October 14, 2026 13:00 - 18:00 October 15, 2026 13:00 - 17:30 Online , Time zone: BST (GMT+1) X Ticket price: £1,100-£1,250 (plus VAT) Register Agenda Increase Your Influence and Strengthen Your Authority Understand how emergent and assigned leadership applies to different product roles. Learn how to effectively influence people and encourage change using the Behavioural Change Stairway model. Become aware of the empowerment level you and the product team members currently have and learn how you can increase your authority. Apply the Right Leadership Styles Understand common leadership behaviours with their strengths and weaknesses. Become aware of your preferred leadership style. Learn how to select the right leadership approach for a given situation. Build High-Performing Product Teams Staff the team with the right people and organise the team around a product. Choose the right level of empowerment and autonomy for the team. Drive innovation and creativity in your team. Learn how psychological safety and stable team composition influence team dynamics and motivation. Set the Right Goals and Align Stakeholders and Teams Set the right outcomes using Roman’s goal-setting framework. Effectively capture goals using the product vision, product strategy, and product roadmap. Understand how OKRs can be effectively used in product management. Determine if your current goal-setting approach including the goals you use is effective and how it can be improved. Make Effective Decisions and Secure Strong Support Learn how decision rules help you make effective decisions and when each rule is best used. Understand when and how to involve stakeholders and dev team members in decisions, when to decide on your own, and when to delegate. Use the right decision-making process to develop an... - Published: 2019-05-30 - Modified: 2026-04-02 - URL: https://www.romanpichler.com/training-courses/ Product Management Training Courses with Roman Pichler Coaching Workshops Schedule of Public Workshops Product Strategy & Roadmap Workshop Product Leadership Workshop In-house Workshops Workshop FAQs Books All of Roman’s Books Strategize, 2nd Edition How to Lead in Product Management Agile Product Management with Scrum Scrum Blog See All Blog Posts FAQs Articles Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Essential Articles Videos Podcast See All Podcast Episodes Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Tools All Tools The Product Vision Board GO Product Roadmap The Persona Template Product Canvas Sprint Goal Template Strategy Stack Product Strategy Framework Goal-Setting Framework KPI Selection Framework Feedback Framework Product Management Framework About About Roman Talks Contact Become Great at Product Strategy and Product Leadership No matter if you are a product manager, product builder, product owner, or product leader, strategy and leadership skills are crucial to succeed in your job and advance your career. Attending Roman’s instructor-led workshops will equip you with the strategy and leadership tools and techniques you really need. The hands-on practical exercises, engaging discussions, and small group size, combined with Roman’s rich experience and thought-leadership in product management, make his workshops truly special. For more information on the workshops, click the “Course details” link below. To learn more about Roman’s overall approach, payment options, and class sizes, visit the FAQs page. Please get in touch if you have any questions or would like Roman to deliver the workshop in-house. Upcoming Public Workshops Product Strategy and Product Roadmap Workshop > Make the Right Strategic Decisions to Build a Successful Product June 16, 2026 13:00 - 18:00 June 17, 2026 13:00 - 18:00 June 18, 2026 13:00 - 17:30 Online , Time zone: BST (GMT+1) X Register Course details Product Leadership Workshop > Become a Successful and Inspiring Product Leader October 13, 2026 13:00 - 18:00 October 14, 2026 13:00 - 18:00 October 15, 2026 13:00 - 17:30 Online , Time zone: BST (GMT+1) X Register Course details Product Strategy and Product Roadmap Workshop > Make the Right Strategic Decisions to Build a Successful Product November 10, 2026 13:00 - 18:00 November 11, 2026 13:00 - 18:00 November 12, 2026 13:00 - 17:30 Online , Time zone: GMT / UTC (GMT+0) X Register Course details Sign up for great new content from Roman Hear about his latest product management work including new articles, videos, podcast episodes, and more. Email Expert Consulting and Coaching for Product Leaders and Product Teams About Roman Contact Roman Ask Roman to Coach You and Your Team Ask Roman to Give a Talk Roman’s Workshops Product Leadership Workshop Product Strategy & Roadmap Workshop In-house Workshops Workshop FAQs Learn More Roman’s Books Roman’s Blog Roman’s Videos Roman’s Podcast Roman’s Tools Follow Roman LinkedIn YouTube Instagram RSS Feeds Blog Podcast © 2026 Pichler Consulting Limited Privacy Policy Sitemap - Published: 2019-05-24 - Modified: 2026-05-11 - URL: https://www.romanpichler.com/tools/ Product Management Tools, Frameworks & Infographics Coaching Workshops Schedule of Public Workshops Product Strategy & Roadmap Workshop Product Leadership Workshop In-house Workshops Workshop FAQs Books All of Roman’s Books Strategize, 2nd Edition How to Lead in Product Management Agile Product Management with Scrum Scrum Blog See All Blog Posts FAQs Articles Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Essential Articles Videos Podcast See All Podcast Episodes Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Tools All Tools The Product Vision Board GO Product Roadmap The Persona Template Product Canvas Sprint Goal Template Strategy Stack Product Strategy Framework Goal-Setting Framework KPI Selection Framework Feedback Framework Product Management Framework About About Roman Talks Contact Templates Product Vision Board Capture your vision and product strategy with this popular and powerful tool. More Information & Download GO Product Roadmap Build a goal-oriented, outcome-based product roadmap that aligns the stakeholders and guides the product team.​ More Information & Download Persona Template Create powerful personas that help you make the right product decisions, choose the right UX, and select the right features. More Information & Download Product Canvas Create a product with a great user experience and the right features with this innovative alternative to a traditional, linear product backlog. More Information & Download Sprint Goal Template Formulate effective, outcome-based sprint goals that guide the work of the development teams. More Information & Download Frameworks & Infographics Roman's Strategy Stack Connect business, portfolio, product and technology strategy and assign clear ownership. More Information & Download Product Strategy Framework Make effective strategic decisions that guide everyone involved in developing and providing a product. More Information & Download Goal-Setting Framework Use the right product-related goals to align individuals and teams and help everyone move forward together. More Information & Download KPI Selection Framework Roman’s KIP selection framework helps you choose the indicators that really matter for your product. More Information & Download Feedback Framework Roman’s feedback framework helps you constructively address issues and encourage people to change their behaviours. More Information & Download Product Management Framework Roman’s product management framework helps you understand key product management building blocks. More Information & Download x Get great new content from Roman Hear about his latest product management work including new articles, videos, podcast episodes, and more. Email Expert Consulting and Coaching for Product Leaders and Product Teams About Roman Contact Roman Ask Roman to Coach You and Your Team Ask Roman to Give a Talk Roman’s Workshops Product Leadership Workshop Product Strategy & Roadmap Workshop In-house Workshops Workshop FAQs Learn More Roman’s Books Roman’s Blog Roman’s Videos Roman’s Podcast Roman’s Tools Follow Roman LinkedIn YouTube Instagram RSS Feeds Blog Podcast © 2026 Pichler Consulting Limited Privacy Policy Sitemap - Published: 2019-05-22 - Modified: 2025-09-08 - URL: https://www.romanpichler.com/contact/ We love to hear from you, answer your questions, and discuss how we can help you! To contact Roman, please fill in the form below or send an email to info@romanpichler. com. - Published: 2019-05-22 - Modified: 2026-06-01 - URL: https://www.romanpichler.com/about-roman/ Roman Pichler is an internationally recognised product management expert, author, and keynote speaker and a trusted advisor and coach. For 20 years, he's advised executive teams and helped product leaders develop winning product strategies, foster effective leadership, and successfully apply innovative product management practices. These include using AI to make better strategic decisions, developing an effective portfolio strategy approach, and helping companies fully leverage a product-led way of working. Roman is the author of four influential books, including Strategize and How to Lead in Product Management. He writes an award-winning product management blog, and he shares practical insights on his podcast and YouTube channel. His product management frameworks and tools—including the Product Vision Board, GO Product Roadmap, and Strategy Stack—are used by product teams worldwide. He regularly speaks at conferences and has given talks at Mind the Product, Industry Europe, Product Management Festival, Leading the Product, Product Elevation, Scrum Gathering, Scrum Day Europe, and many more. To learn from Roman's expertise, attend his Product Leadership and Product Strategy and Roadmap workshops. Contact him if you would like to benefit from his coaching and consulting work, help you solve your product management challenges, deliver in-house workshops, or give an inspiring talk at your company. You can find out more about Roman and his background below. - Published: 2019-05-21 - Modified: 2025-12-12 - URL: https://www.romanpichler.com/ Expert Consulting & Coaching in Product Strategy & Leadership | Roman Pichler Coaching Workshops Schedule of Public Workshops Product Strategy & Roadmap Workshop Product Leadership Workshop In-house Workshops Workshop FAQs Books All of Roman’s Books Strategize, 2nd Edition How to Lead in Product Management Agile Product Management with Scrum Scrum Blog See All Blog Posts FAQs Articles Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Essential Articles Videos Podcast See All Podcast Episodes Product Leadership Product Vision and Strategy Product Roadmap Product Roles Product Management Processes Product Backlog & User Stories Stakeholder Management Tools All Tools The Product Vision Board GO Product Roadmap The Persona Template Product Canvas Sprint Goal Template Strategy Stack Product Strategy Framework Goal-Setting Framework Feedback Framework KPI Selection Framework Product Management Framework About About Roman Talks Contact Expert Consulting and Coaching for Product Leaders and Product Teams Workshops Become great at product strategy and leadership by attending Roman’s collaborative, hands-on workshops. View all workshops Blog Articles Read Roman’s award-winning blog with more than 200 articles on product strategy, product leadership, and agility. Check out Roman’s blog Videos Watch Roman’s free product management video tutorials and learn about product leadership, product strategy, product roadmap, and more. Watch the tutorials Books Read Roman’s books, benefit from his advice, and become better at product management. Read Roman's books Learn from a Leading Expert Roman Pichler is an internationally renowned product management expert specialising in product strategy, leadership, and agility. For nearly 20 years, he has shaped the thinking of thousands of product leaders and helped his clients successfully apply modern product management practices. Roman is the author of four influential books and the creator of several widely used product management frameworks, including the Product Vision Board. He has published more than 200 thoughtful articles grounded in practice, not hype. More about Roman Contact Roman Sign up for great new content from Roman Hear about his latest product management work including new articles, videos, podcast episodes, and more. Email Expert Consulting and Coaching for Product Leaders and Product Teams About Roman Contact Roman Ask Roman to Coach You and Your Team Ask Roman to Give a Talk Roman’s Workshops Product Leadership Workshop Product Strategy & Roadmap Workshop In-house Workshops Workshop FAQs Learn More Roman’s Books Roman’s Blog Roman’s Videos Roman’s Podcast Roman’s Tools Follow Roman LinkedIn YouTube Instagram RSS Feeds Blog Podcast Pichler Consulting Limited Privacy Policy Sitemap ## Posts - Published: 2026-07-13 - Modified: 2026-07-13 - URL: https://www.romanpichler.com/blog/how-to-create-an-inspiring-product-vision/ - Categories: Product Vision and Strategy - Tags: ai, alignment, emotion, product vision board “If you are working on something exciting that you really care about, you don’t have to be pushed. The vision pulls you,” Steve Jobs once said. Creating such forward momentum is a key benefit that a product vision should offer. Unfortunately, I’ve seen many visions that failed to move people. In this article, I explain how you can create a truly inspirational vision that engages and motivates people. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/2530019/c1e-44vqt869j5b8r9zj-1px0191vc1nq-hhzsb8. mp3 Before You Start: Know What a Product Vision Is and Why You Need One A product vision describes the ultimate reason for building the product and the positive change it should bring about. It’s best captured as a BHAG—a big, hairy, audacious goal. An example of a vision for an app that helps people reduce the risk of developing type-2 diabetes might be “help people eat healthily,” or even shorter, “healthy eating. ” As the example shows, a vision is best expressed as a concise statement or slogan. I generally encourage teams to use a product vision. Why? An effective vision inspires people. It creates a meaningful purpose and shows how their work connects to the bigger picture—how it helps make a positive impact. This motivates the individuals and encourages them to move forward together. Additionally, a big, aspirational vision acts as the product’s North Star: It provides continued guidance for the product team, no matter how much the product’s market grows and its UX, features, and technologies change. But using such a vision is not enough. You also need to determine the approach to realise it and achieve product success: In other words, you need a product strategy, as Figure 1 illustrates. Figure 1: Product Strategy Framework with Vision and Product Vision Board Figure 1 shows my product strategy framework, in which the vision plays a fundamental role. It guides the strategy, which, in turn, directs the product roadmap and backlog. Additionally, it shows the tool I have developed to capture the vision and strategy—the Product Vision Board. To learn more about the framework and the template, read the articles The Product Strategy Framework and The Product Vision Board. Connecting Company, Portfolio, and Product VisionEstablished businesses often use a company vision and a product portfolio vision in addition to the product vision. Take Microsoft as an example. Its overall aspiration is “empower every person and every organization on the planet to achieve more. ”The vision for its 365 portfolio, formally known as Office, might be described as “enable individuals and organisations to get things done. ” If you use several visions in your company, make sure that they are connected. The company vision should guide the portfolio visions, which should direct the product visions. This facilitates consistent decision-making and alignment. Capture the Product's True Purpose In my coaching work and workshops, I often see visions that state what the product should look like and do or what business goals it should achieve. While there is, per se, nothing wrong with such a product vision, it is not particularly inspiring. If implementing features and chasing business benefits is all we do, it’s hard to care and stay motivated, especially when the going gets tough—for example, when development progress is unexpectedly slowed down, or the market response to the latest release is less positive than anticipated. To craft a truly inspiring vision, you need to state the product’s ultimate purpose. To discover it, ask why the product exists. What positive change will it have achieved in five to ten years? What impact will the product have on the world and especially on the people who come in touch with it? How will it have changed their lives for the better? “(... ) the secret to high performance our deep-seated desire to (... ) to live a life of purpose,” as Daniel Pink writes in his book Drive. Such a purpose-driven vision generates strong motivation for everyone working on the product. It gives their work meaning and helps them understand how they make a positive impact through their work. Let’s make this more concrete and look at the following sample vision: “Build an AI coding assistant with autonomous agent capabilities and automatic testing and debugging. ” This vision statement seems to be well thought out—it envisions the new product. But therein lies the problem: It’s a solution-focused vision, not a purpose-driven one. I would therefore rework it and use the following phrase instead: “Empower people to create software at the speed of thought. ” This vision resonates much more with me. It gives me a purpose—to enable people to create—and motivates me. Additionally, it does not talk about the target group and features. This has two benefits: First, it makes the vision more stable. A product’s market, features, and business goals will change, but the vision should stay stable and provide continued guidance across its entire life cycle. Second, it... - Published: 2026-06-08 - Modified: 2026-06-10 - URL: https://www.romanpichler.com/blog/emotional-intelligence-in-product-management/ - Categories: Product Leadership - Tags: ai, conflict, emotion, empathy, self-leadership, stakeholders, teamwork, trust As product management becomes increasingly data-driven and AI-powered, one human capability is growing in importance: emotional intelligence. In this article, you'll discover why emotional intelligence is a critical complement to data, analytics, and AI, how it helps product managers and product leaders create better products and build stronger relationships, and why it may have a greater impact on product success than intellectual ability alone. You'll also learn practical techniques for strengthening your emotional intelligence—from increasing self-awareness and self-management to developing empathy, active listening, and conflict-resolution skills. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/2486369/c1e-rgw1iok5r0i7vn50-0v0jzrvpur79-kea2td. mp3 What Exactly is Emotional Intelligence? One of the big advancements product management has experienced is the ability to collect and analyse large amounts of user data. This has helped product managers better understand how users actually use their products, make data-informed decisions, and continuously improve their offerings. AI has taken this to a new level, giving us even more powerful capabilities, including customer insight mining, sentiment analysis, and trend analysis. We can now use tools that extract actionable information from user data, infer how a user might be feeling about the product, and identify emerging patterns in customer behaviour. But as powerful as it is, AI is not enough. It is virtually impossible to offer a successful product without another form of intelligence: Emotional Intelligence, or EI for short. It refers to our ability to recognise, understand, and manage our own feelings while also being attuned to the emotions of others. Goleman’s framework, shown in Figure 1, is a popular approach to describing emotional intelligence more precisely. Figure 1: Goleman's Emotional Intelligence Framework Let’s take a closer look at the four elements in Figure 1. Self-Awareness means understanding our emotions and how they affect us. That’s sometimes easier said than done. It can be tempting to suppress feelings that are not aligned with our self-view. For example, if you regard yourself as kind and rational, you might find it hard to accept that, like all human beings, you experience anger at times. But being mindful of our feelings, what triggers them, and how we deal with them is the basis for increasing EI. Self-Management is the ability to lead ourselves and to constructively deal with difficult emotions like anxiety, aversion, and anger. This allows us to stay calm in stressful situations—for example, during a difficult stakeholder conversation—and respond prudently, rather than acting out our feelings and possibly saying things we’ll later regret. Social Awareness includes the capacity to empathise with others and to read a group’s emotional currents and power relationships. Empathising means understanding another person’s feelings and needs, taking their perspective, and reaching out to them with an open, warm-hearted attitude—whether we like them and agree with their views or not. It’s the foundation for building effective relationships and successfully working with stakeholders and team members, as well as understanding user and customer needs. Relationship Management requires the ability to make and evolve meaningful connections with others. Strong relationships are built on trust. When people trust each other, collaboration becomes easier. When they trust you, they are more likely to follow your advice. But relationships aren’t always harmonious, and people don’t always agree. Relationship management, therefore, also includes the capability of dealing with disagreements and conflicts constructively. IQ vs EQIQ, or intelligence quotient, is widely recognised as a measure of intellectual capability. IQ tests are designed to assess various aspects of mental functioning, including a person's logical reasoning ability, memory capacity, and spatial awareness. Contrast this with EQ, or emotional quotient, which measures the ability to understand and manage emotions. It determines a different kind of intelligence, which can have a bigger impact on success at work than an individual's intellectual capabilities. Over the years, I’ve seen plenty of product managers who were smart and had excellent product knowledge but exhibited low EI. Consequently, they struggled to influence and align people and achieve product success. How Does EI Help Product Managers and Product Leaders? Developing emotional intelligence offers four specific benefits to product people: it helps us create better products and collaborate more effectively with stakeholders and team members; it strengthens our ability to guide others; and it improves our mental well-being. Let’s look at those benefits in more detail. Better Products At the heart of product management aren’t frameworks, technologies, and business models. While these are undoubtedly important, product management is about people: creating real value for users, customers, and our organisations. That’s virtually impossible to achieve without developing a deep understanding of the user and customer needs. Without the right insights, we risk throwing stuff against the wall and seeing what sticks, pushing out prototype after prototype, or feature after feature, hoping that one of them will finally resonate with people. This approach not only burns time and money. It can leave users frustrated and damage the brand. Increasing our emotional intelligence helps us empathise with users and customers more effectively, better understand their needs, and discover opportunities for innovation, thereby increasing the likelihood of... - Published: 2026-05-11 - Modified: 2026-05-11 - URL: https://www.romanpichler.com/blog/romans-product-strategy-framework-v3/ - Categories: Product Vision and Strategy - Tags: empowerment, GO product roadmap, product team, product vision board, stakeholders, validation One of the biggest mistakes I see product managers make is making decisions in isolation: Deciding on strategy without considering how it impacts product discovery and delivery, or determining UX and features without letting strategy guide those choices. Great products, however, aren’t built by separating strategy from execution. They’re created by connecting them. That’s exactly why I developed my product strategy model—a simple but powerful way to link product vision, strategy, roadmap, and backlog. This article describes the framework in its latest, revised version. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/2459592/c1e-kom3bdq2xmfg8xnk-rkgo1w05s6q-atqbmm. mp3 The Framework and its Elements Figure 1 shows the product strategy model with its four elements: product vision, product strategy, product roadmap, and product backlog. Figure 1: Roman’s Product Strategy Framework The elements form a hierarchy with the vision at the top and the backlog at the bottom. Let’s take a closer look at the elements. PRODUCT VISION The product vision describes the product’s purpose, the ultimate reason for creating it, and the positive change it should bring about. You can think of the vision as the product’s North Star, guiding teams, stakeholders, and management. Like the star, it should be stable and change little across the product life cycle. My preferred way to capture the vision is to use a short statement or a slogan that inspires and galvanises people. PRODUCT STRATEGY The product strategy communicates the approach chosen to realise the vision and to make the product successful. You can think of it as guardrails that guide product discovery and discovery. For a digital product, it often looks at the next 12-24 months, depending on the amount of innovation and uncertainty present. Coming up with a strategy requires you to make four important choices: Determining the market or market segment: Who is the product for? Who are the users and customers? Selecting the needs the product should address: Why would people want to use it? What problem does it address, which benefit does it offer, or which job does it help people do? Choosing effective standout features: What sets the product apart from alternatives? What are its distinctive or unique features? Setting clear business goals: How does the product benefit your company? Does it, for example, generate revenue, reduce costs, or increase productivity? Making these choices requires you to say no to ideas and suggestions. While this can be hard, it is a necessary part of strategic decision-making. A product that tries to please everyone risks not doing a good job for anybody. What’s more, a new or significantly changed strategy must be validated to maximise the chances of achieving product success. This is best done by systematically addressing its biggest assumptions and risks, as I explain in more detail in the article Product Strategy Discovery. PRODUCT ROADMAP With a validated product strategy in place, you are in a great position to build a product roadmap that describes how the strategy will be implemented and communicates the specific benefits the product will achieve. An effective roadmap is built on product outcomes or product goals. These describe the positive impacts the product should make, for example, acquiring new users and increasing engagement. The roadmap may also contain additional elements like time frames, selected coarse-grained features, and metrics. A time frame states when an outcome should be achieved, the features sketch the output required to realise an outcome, and the metrics help you understand if an outcome has been accomplished. All outcomes on the product roadmap must be aligned with the product strategy—they must help meet the user/customer needs and business goals. This connects the two framework elements. It ensures that the product strategy guides roadmapping decisions and that the roadmap and its outcomes implement the strategy. To achieve this, I’ve found two methods helpful: deriving them directly from the needs and business goals stated in the product strategy and determining them using key performance indicators (KPIs). I describe the two approaches in more detail in the article Get the Outcomes on Your Product Roadmap Right. PRODUCT BACKLOG An outcome-based roadmap provides a great basis for discovering what to build and deriving the product backlog. To do this, simply copy the next outcome into the backlog together with its features. Then add further items that are required to meet the outcome. These may include epics, user stories, workflow diagrams/user journeys, and non-functional requirements (NFRs). If you build prototypes to describe the product’s design and functionality, then use these instead of traditional backlog items. Make sure, though, that they are guided by the outcome you've chosen. If you follow this approach, the product backlog is guided by the product strategy and roadmap. Strategic decisions form the basis for deciding what to build. As a side benefit, you’ll end up with a focused, concise backlog instead of an unrealistic wish list. Such a backlog is easier to manage and change. But it requires the courage to say no to ideas and feature requests that don’t help achieve the selected product... - Published: 2026-04-15 - Modified: 2026-04-17 - URL: https://www.romanpichler.com/blog/product-managers-product-builders/ - Categories: Product Roles - Tags: ai, empowerment, product delivery, product discovery, product manager, product owner Is it a good thing when product managers are hands-on and use AI to build prototypes and generate code? Will it increase productivity and job satisfaction? Will it deliver better products faster? Or will it result in poorly designed applications full of technical debt that nobody wants and needs? Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/2422651/c1e-djkntoo605twr0n2-8d89x819codx-b3y3wn. mp3 Once Upon a Time in Product Land My first experience of working in product management was mixed. I loved the actual work, especially determining the value a product should create and discovering its features. But I was put off by the heavyweight waterfall-based processes: Product managers conducted market research, built detailed feature-based roadmaps, wrote comprehensive requirements specifications, and handed them off to the development teams. In sum, they created lots of paperwork but hardly engaged with product delivery. That was in 2001. Around the same time, I started to apply agile frameworks, which offered a radically different approach: Instead of communicating via detailed documents, product people would collaborate with one or more dev teams to jointly discover and deliver the right product—to learn faster, speed up development, and deliver better products. Maybe I was young and naive, but I was optimistic that an agile way of working would change product management for the better. And the early agile adoptions I was involved in largely succeeded in applying this new collaborative product management approach. But the wider agile practices spread, the less this was the case. Product owners morphed into backlog managers, user story writers, and Jira ticket jockeys. The stories stopped being a promise for a conversation and turned into elaborate requirements. Product backlogs grew bigger and bigger, and features were no longer discovered and described collaboratively. The organisational inertia had beaten the new ways of working. Innovation, autonomy, and cross-functional collaboration were stifled by red tape. With new, powerful AI tools being available, I see organisations challenge the traditional product manager role again and expect product people to be more hands-on and help co-create the actual products. But is this a good thing? Will it deliver better products faster? To answer this question, let’s start by exploring what a product builder is. What is a Product Builder? A product builder is a product manager who actively participates in the creation of a product—for example, by crafting mock-ups, prototyping features, or vibe coding—rather than solely directing others. It’s a new, emerging role employed by companies like Amazon and LinkedIn, and it’s sometimes also referred to as an AI product manager. Some regard the role as a paradigm shift, a fundamental change in the way product managers work: they (co-) create rather than plan and coordinate. The co-creation element distinguishes the product builder from other “modern” approaches, including agile development and continuous discovery. In Scrum, a product owner discovers features together with the developers and guides product delivery by reviewing product increments. In continuous discovery, a product manager forms a product team—or product trio—with a tech lead and a designer. Jointly, they discover the right features and guide product delivery. When product managers make hands-on contributions to their actual products, they require skills which are traditionally associated with design and engineering. These include the ability to create effective UI prototypes, as well as to architect, vibe-code, and test a software application, using tools like Loveable and Claude Code. This enlarges the skill set product managers require, which makes the role even more challenging. That’s especially true when a product builder acts as a full-stack product manager who engages in product strategy in addition to product discovery and delivery. What are the Pros and Cons of the Product Builder Role? To determine whether being a product builder is helpful, let’s look at its benefits and drawbacks. What’s exciting about the role is its promise for positive change: helping product managers break free from spending most of their time influencing people and orchestrating work at best, and being a feature broker and backlog administrator at worst. More specifically, the approach can offer the following three benefits: Higher productivity and job satisfaction: When product managers take on some of the tasks traditionally associated with designers and programmers, more can potentially be achieved with smaller teams. Additionally, working as a product builder can give individuals a sense of achievement and be more satisfying than planning work and creating documents. Faster decisions and shorter time to market: Being actively involved in product delivery can reduce communication overhead and eliminate waiting and delays. Instead of writing user stories, a product builder may develop a prototype and use it to validate ideas and collect feedback. Better products: A deep involvement in product delivery can avoid a strategy-execution chasm, result in better collaboration with designers and engineers, and lead to products that offer the right user experience... - Published: 2026-03-09 - Modified: 2026-03-09 - URL: https://www.romanpichler.com/blog/get-the-outcomes-on-your-product-roadmap-right/ - Categories: Product Roadmap - Tags: ai, GO product roadmap, KPIs, product goal, product manager, stakeholders, sustainable pace Product outcomes define the specific value a product creates—for users, customers, and the business. When applied correctly, they align stakeholders, create focus, and give development teams clear direction. But getting them right isn’t easy. Too often, product teams choose outcomes that are vague, oversized, or worse, features dressed up as goals. The result? Confusion, misalignment, and roadmaps that look strategic but fail to drive meaningful impact. In this article, I’ll address these issues and provide practical advice to help you define the right outcomes that help you achieve product success. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/2388112/c1e-68k7u71kg8uk4zvx-ww726q5ds9o-u7nzoj. mp3 A Brief Introduction to Outcomes and Outcome-based Product Roadmaps Traditionally, a product roadmap is a feature-based plan that assigns capabilities like registration, search, and reporting to a timeline. Such a roadmap essentially states when a piece of functionality will be delivered. This can be reassuring for customers and stakeholders. But unfortunately, it has several drawbacks, including the following two: A feature-based roadmap can make it hard to secure agreement, as stakeholders compete to get their features implemented. In the worst case, this results in a Frankenstein product—a collection of unrelated features with a terrible value proposition and a horrible user experience. The features are sometimes regarded as a commitment rather than a part of a high-level plan that is likely to change. This limits your ability to experiment and learn, to discover the best way to address the user and customer needs and create value for the business. These drawbacks are avoided by using a different approach: an outcome-based, goal-oriented product roadmap. As the name suggests, this plan focuses on product outcomes, which are also referred to as product goals and objectives. Examples are acquiring customers, increasing engagement, and reducing cost. What’s more, using outcomes makes it easier to align stakeholders and guide development teams, and it helps discover the right product functionality and direct the product backlog. Figure 1 shows what an outcome-based roadmap may look like using my GO Product Roadmap template, which you can download for free together with a handy checklist from my website. Figure 1: An Outcome-based Product Roadmap Out of the five elements in Figure 1, the goal is the most important one, as it describes the customer/business outcome you want to achieve with your product. Strictly speaking, all other elements are optional. While the GO Product Roadmap still uses selected, coarse-grained features, these must support their outcomes. Goals come first, features second. What about OKRs? OKRs, objectives and key results, are a goal-setting method originally developed at Intel in the 1970s. The objective describes what you want to achieve. The key results state the specific criteria that have to be fulfilled to meet the objective. If you use OKRs for your product, you can simply view the objective as the outcome. The advice I share in the remainder of this article will therefore help you set the right objectives. Identify the Right Product Outcomes As the outcomes on a product roadmap play such an important role, it is crucial to choose the right ones. To achieve this, I’ve found two methods helpful: deriving them directly from the needs and business goals in the product strategy and determining them with the help of key performance indicators (KPIs). Let’s look at the two techniques in more detail. Derive the Outcomes from the Needs and Business Goals in the Product Strategy To make the discussion more concrete, let’s use an example. Say that I want to offer a new healthy-eating app. Its product strategy states that the user need is to “reduce the risk of developing type-2 diabetes,” and the main business goal is to “create a new revenue source. ” Let’s also assume that the business model I have chosen is freemium, giving away a free basic version and generating revenue through subscriptions. With this information in place, I can ask myself what the first, concrete step to meet the needs and the business goals is. My answer might be, “help users understand their eating habits and acquire an initial user base. ” What I have done here is break down the two higher-level goals stated in the strategy into a more specific outcome. Applying this method not only helps determine the right product goals. It also connects the product roadmap to the product strategy—the former is literally derived from the latter. To put it differently, the strategy forms the foundation for identifying the right product outcomes. Figure 2 illustrates this approach. Figure 2: Needs and Business Goals Help Discover Product Outcomes If I can see further than the initial offering, or MVP, I would derive additional outcomes. These might include assisting users in improving their dietary habits and expanding the user base, as well as supporting users in achieving greater fitness and generating revenue through subscriptions. Together, these goals form a meaningful narrative. They describe how the product is likely to evolve in the coming months: Each outcome is a step towards realising the overarching needs and business goals, thereby helping implement... - Published: 2026-02-02 - Modified: 2026-04-20 - URL: https://www.romanpichler.com/blog/succeeding-with-the-product-operating-model/ - Categories: Product Leadership - Tags: ai, business strategy, empowerment, GO product roadmap, product discovery, product manager, product vision board, stakeholders, sustainable pace This article explains how you can successfully implement the product operating model—based on my experience of helping companies introduce and improve a product-centric way of working over the past 15 years. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/2345645/c1e-w4g9tv4gvri84xdv-5z335pgxu1md-s9igiq. mp3 Products? What Products? Back in 2009, a group of handpicked individuals had gathered in a conference room, looking at me expectantly, as I kicked off the very first product management workshop for the IT department of a large insurance company. But when I asked the attendees what products they managed, they looked confused and said, “What do you mean? We don’t manage products. We run projects. ” At the time, there was no common awareness that the software assets created in-house could be viewed and managed as products. A product was exclusively thought of as a commercial offering, like an insurance policy. What’s more, teams often worked on multiple software assets within a single project, and the projects were comparatively short. This made it hard to determine the business impact. Clear ownership and accountability were lacking. But there were plenty of hand-offs, loss of knowledge, and misalignment. Luckily, things changed for the better, as the company started to employ a product-led way of working, which is also known as the product operating model or product model, for short. Instead of running temporary projects, work is organised around products. These are owned by enduring product teams who are responsible for achieving the desired customer/user and business benefits. Over the past fifteen years, I’ve helped a range of organisations in different sectors, including media, financial services, retail, education, transportation, and government, establish a product-centric way of working by enabling product people and teams, coaching Heads of Product, and advising executive leaders. I’ve found that implementing the model can offer several tangible benefits, including improved customer centricity, better financial performance, increased innovation, and higher team motivation and job satisfaction. However, I’ve also learnt that successfully implementing it is not easy. It requires significant organisational changes and executive leadership in addition to new roles and skills. To help you succeed with your product operating model implementation, I’ve described my learnings in the remainder of this article. Projects vs. ProductsMoving from a project-focused environment to a product-centric way of working is a major change for most companies. Traditionally, software is built through a series of separate, comparatively short projects, which are led by a project manager. Success is often defined by delivering the project on time, on scope, and on budget. Contrast this with products, which are (digital) assets that create value for users and/or customers and the business. They often exist for many years and have a different life cycle compared to projects. Products are only successful if they create the desired value. Additionally, they are managed by product managers with the help of cross-functional product teams. This does not mean, however, that projects are no longer needed when you embrace a product-led way of working. They are still valuable, for instance, to manage a data migration effort, achieve regulatory compliance, and implement organisational changes, like establishing the product operating model. What changes, though, is the default way to manage work: instead of running projects, you focus on products. Succeeding with the Product Operating Model Let me start by giving you an overview of the four aspects that must be addressed to succeed with the implementation of the model. These are: organisation, people, processes, and tools, as shown in Figure 1. Figure 1: Four Aspects of a Successful Product Operating Model Implementation Out of the four aspects, organisation is the most important one, followed by people. You can, for example, implement an awesome product discovery process and build amazing Opportunity Solution Trees. But if the necessary organisational changes aren't taking place and product teams aren’t effectively set up and adequately empowered, you won’t be able to fully establish the product model and reap all its benefits. Instead, you are likely to end up with a halfway house between the old and the new world, where product managers struggle to do a good job and create the desired value, as they lack the necessary skills and organisational support. Organisation I have seen no major change initiative succeed that didn’t have executive leadership and a clear vision for change. Introducing the product model is no exception. It has a profound impact that goes beyond the IT/technology department, affecting other parts of the organisation, including marketing, sales, finance, support, and HR. Let me give you four examples: New roles, learning and development programs, and career paths will have to be introduced. A new product management organisation with a new head will have to be created, and the IT/technology... - Published: 2026-01-12 - Modified: 2026-02-26 - URL: https://www.romanpichler.com/blog/how-to-create-a-product-strategy-for-an-existing-product/ - Categories: Product Vision and Strategy - Tags: ai, business model, GO product roadmap, product goal, product vision board, stakeholders, validation Every product has a strategy. But not all product strategies are clearly articulated, let alone communicated and understood. This can lead to confusion and misalignment: Different people have different ideas about what the actual strategy is and disagree on which features should be implemented. But it doesn’t have to be this way. In this article, I describe a clear, five-step process that helps you build an effective strategy for an existing product and create clarity and alignment. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/2319917/c1e-xkzrs9jwomhkd084-qd142n9rhz0z-0qsv2a. mp3 Product Strategy in a Nutshell Let me start by briefly reminding you of what a product strategy is and why it matters. A product strategy is a cohesive set of choices that acts as a decision-making framework to achieve product success. To do so, it should answer the following questions: Who is the product for? Who are the users and customers? Why would people want to use it? What problem does it address, which benefit does it offer, or which job does it help people accomplish? How will the product benefit your business? Will it, for example, generate revenue, reduce costs, or increase productivity? What sets it apart from alternatives? What are its standout features? An effective product strategy provides guardrails to make the right choices and decide what to build. It aligns stakeholders and development teams, and it enables you to set the right outcomes/OKRs and deliver the right features. The reverse is also true: Without a clear strategy, product teams usually struggle to decide what features to build. In the worst case, they throw stuff against the wall and hope that something will stick, or they are driven by stakeholder requests, which risks creating a Frankenstein product—a product with a terrible value proposition and horrible user experience. Step 1: Clearly Describe the Current Product Strategy It’s not uncommon in my experience that the product strategy only exists in the mind of a senior manager, like the Head of Product or the CEO, or that it is tacitly known by the product team members. But a strategy that hasn’t been clearly articulated is difficult to work with, communicate, and evolve. In the worst case, people disagree about what it is, and misalignment occurs. The first step, therefore, is to effectively state the current product strategy. To do this, choose a suitable tool, like my Product Vision Board shown in Figure 1. Figure 1: A Template to Capture the Product Strategy I designed the Product Vision Board as a thinking and communications tool that helps you ask the right questions and capture important strategic product decisions. Its top section states the product vision, which describes the ultimate reason for offering the product. The bottom four sections describe the product strategy. The leftmost captures the target group, the users and customers of the product. The next section states the customer and user needs—the main problem the product addresses or the primary benefit it creates. The third section describes the product’s standout features. These are the capabilities that set it apart from competing offerings and encourage people to use it instead of alternatives. The last section finally shares the business goals, the business benefits the product offers, for example, generating revenue or reducing costs. You can download the Product Vision Board together with a checklist that helps you successfully apply it from my website for free, and you can learn more about how to use it by watching the following video: https://youtu. be/rtbWVxYEgNA While it is very helpful for the person in charge of the product to clearly describe the current product strategy, it is even better to involve the key stakeholders and development team representatives and run a collaborative workshop. This allows you to align people and ensure that everyone has the same understanding of what the strategy is. To jointly capture the strategy, print out the Product Vision Board and bring adhesive notes for an on-site workshop, or use an electronic version for an online session. Many collaboration tools, including Miro and Lucid, offer implementations of the Product Vision Board. Ask the workshop attendees to describe the vision, target group, needs, stand-out features, and business goals on separate notes. Next, invite people to share their views, starting with the vision. Once all notes have been read out and added to the board, summarise those that are similar. Then discuss any conflicting statements. Use data whenever possible to resolve issues. All workshop attendees should at least consent to the strategy and not object to its content to ensure strong enough buy-in and alignment. Consider using a dedicated facilitator to moderate the workshop, for instance, the team coach or Scrum Master. This allows you, the person in charge of the product, to focus on shaping the product strategy instead of having to ensure that everybody is heard and nobody dominates. Step 2: Assess the Current Strategy Once you’ve captured the current product strategy, objectively assess it. Even if your product... - Published: 2025-12-08 - Modified: 2025-12-08 - URL: https://www.romanpichler.com/self-managing-product-teams/ - Categories: Product Leadership, Product Roles - Tags: empowerment, product team, product vision board, self-organisation, stakeholders, teamwork Product teams play a key role in solving user problems and achieving product success. But who should lead the team and manage its work? The Head of Product, the product manager, or someone else? In this article, I explain why product teams should be self-managing. I describe the benefits this approach offers and what it takes to succeed at self-management. Listen to the audio version of this article: document. createElement('audio'); https://episodes. castos. com/5e296c8fcbc2e2-83044581/2274937/c1e-pndmf1rddptqd4r2-mkw5k6n1idm3-ehsv1o. mp3 What is a Self-Managing Product Team? A product team is a group of people who work together, have ownership of a product, and are responsible for making the product successful. Traditionally, the team is led by a senior manager, like the Head of Product, or by a product manager. They set product goals/OKRs, coordinate the work of the team members, and ensure the team is on track. While this approach works, there is a better way: using self-managing product teams. On such a team, leadership is shared amongst the members. They are collectively responsible for progressing the product and meeting agreed outcomes. Consequently, they collaborate to identify and manage the necessary tasks and improve their way of working. Figure 1 illustrates the two approaches. Figure 1: Manager-led vs. Self-Managed Product Team Self-managed product teams can be more effective than manager-led ones, as they offer the following three benefits: Better decisions: “None of us is as smart as all of us,” Ken Blanchard rightly noted. Empowering the team to own their work, set product goals, and determine what needs to be done leads to better decisions and increases the chances of offering a successful product. Increased productivity and motivation: Owning the work and deciding what to do leads to more productive and motivated teams. As Steve Jobs once said, it doesn’t make sense to hire smart people and then tell them what to do. Reduced workload for the Head of Product or product manager: Asking the team to manage their work allows the individual to focus on their core responsibilities. It prevents them from becoming overworked, turning into a bottleneck, and delaying decisions. But Does Self-Management Actually Work? If you have applied agile practices, you are likely to be familiar with the concept of self-managing development teams. But you might also have had bad experiences and doubt that the approach actually works. I have certainly seen my fair share of teams that struggled to self-manage. Some suffered from slow and long-winded decision-making processes, while others underperformed and lacked accountability. In some cases, the teams never became truly self-managing. They always had to rely on an individual to tell them what to do. However, I have also seen plenty of teams succeed at self-management. What distinguished them from those who struggled? The successful teams had been set up effectively and received the support they needed. Self-management doesn’t happen by chance, and telling a team to self-manage isn’t enough. For many organisations, self-management is still comparatively new—it has to be encouraged and learned. To help you establish successful self-managing product teams, I’ve put together six practical tips, which I’ll discuss in the remainder of this article. Tip #1: Choose the Right Team Design How teams are set up has a profound impact on their performance, as research by the late Harvard professor and team expert J. Richard Hackman shows. Figure 2: Hackman’s 60-30-10 Rule Applied to Product Teams As Figure 2 illustrates, the biggest influence on team performance, about 60%, is the team’s design. This includes ensuring that the right people join the product team, that the team’s goals and authority are clear, and that the team receives the right support. The second biggest influence comes from the team launch, roughly 30%. This includes helping the team members bond and establishing shared ways of working. The third factor, team coaching, finally, has a comparatively small impact, about 10% according to Hackman. This does not mean, however, that it is unimportant. The opposite is true, as I’ll explain later. While Hackman’s insights are generally applicable, getting the team design right is especially important for self-managing product teams. Why? The lack of a single leader means that shortcomings in the design are even harder to compensate for than on a manager-led team: There is no one who tells people what to do and sorts out problems for the team. To put it differently, if you want product teams to self-manage successfully, you must put the right foundations in place and ensure that the teams are set up effectively, as I explain in more detail in the article Setting up Product Teams for Success. A key consideration when designing a team is to choose the right level of authority, as shown in Figure 3. The minimum empowerment a product team requires is owning the product discovery and delivery decisions. This allows the members to set specific product goals/outcomes, determine the features and... - Published: 2025-11-03 - Modified: 2026-04-28 - URL: https://www.romanpichler.com/blog/how-to-use-ai-to-create-a-product-strategy/ - Categories: Product Vision and Strategy - Tags: ai, product discovery, product vision board, validation AI has significantly impacted product management. But so far, most product teams have used it to create new features and discover and deliver products faster. While helpful, this approach overlooks the area that most determines product success: strategy. In this article, I’ll explain how to move beyond execution and use AI as a strategic partner—helping you create a product strategy that achieves lasting success. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/2183177/c1e-5q54u1x2mqiq4n83-rkpgg2q5hkk9-ydlv7e. mp3 Why Product Strategy Matters Now More Than Ever I’ve worked in tech for nearly 30 years, and I can’t remember a time when the industry was more dynamic than it is today. Even the Internet craze in the late 1990s seems lame in comparison. Given that we now have powerful AI tools available that can analyse huge amounts of customer data and allow us to create full-blown prototypes faster than ever, you might be wondering if you still need a product strategy. While a lot has changed over the years, one thing remains the same: If you don’t know where you want to go, you will struggle to choose the right path and move forward effectively. The product strategy captures what you want to achieve and how you might get there. Think of it as a set of specific choices that guide product discovery and product delivery. Such a strategy should answer the following questions: Who is the product for? Who are the users and customers? Why would people want to use it? What problem does it address, which benefit does it offer, or which job does it help people do? How will the product benefit your business? Will it, for example, generate revenue, reduce costs, or increase productivity? What sets it apart from alternatives? What are its standout features? While having an effective product strategy has always been important, it’s even more crucial in the age of AI. Here is why: The product strategy provides guardrails to make the right choices and decide what to build: There are a million ways to use AI and add it to a product, but not all of them make sense, of course. A product strategy helps teams discover how AI can actually serve their users and business. It helps them decide, for example, what experiments to run and what features to test. Without a strategy, you risk throwing stuff against the wall and seeing what sticks—trying out idea after idea and hoping that at least one will eventually be successful. It keeps teams and stakeholders aligned: Developers, designers, and stakeholders often have different ideas about what a product should do. The product strategy keeps everyone moving in the same direction, avoiding confusion and wasted effort. The strategy avoids tech for tech’s sake: It’s easy to get caught up in building something just because it’s cool and everyone else does it. A good strategy encourages teams to ask: Does AI truly benefit the users, and does it create a positive impact on the business? It guides responsible and ethical use of AI: With AI, issues like bias, privacy, and environmental impact matter more than ever. An effective product strategy addresses ethical risks and helps create a product that uses AI responsibly. If strategy still matters, how can we leverage AI to create a winning product strategy that achieves lasting success? Put the Right Foundations in Place Over the years, I’ve had an on-and-off relationship with running. There were times in my life when running was my main endurance exercise, and there were years when I didn’t run at all. Currently, I am enjoying running again, and I’d love to run faster and further. It’s tempting, then, to buy new super-trainer shoes. But footwear alone won’t make me a better runner. To run at a higher pace for longer and stay injury-free, I’ll have to take a more holistic approach, reflect on how I run, and improve my running technique. The same applies to product strategy and AI. I wish I could tell you that with AI, making the right strategic decisions will be a breeze, that AI can do most, if not all, strategic thinking for you, and that you can easily prompt-engineer and vibe code your way to success. But that’s not the case. While AI can help you make better strategic decisions and reduce the time and cost required, you still need to know what decisions have to be taken and how to make them—just like I have to understand what a good running technique looks like to take full advantage of my new running shoes. The good news is that this puts you in control: You decide how to use AI, rather than being tool-led. While every product, team, and organisation is different, I’ve worked hard over the past 15 years to develop a strategy approach that is generally applicable. Figure 1 visualises this approach. Figure 1: Product Strategy... - Published: 2025-10-06 - Modified: 2025-12-03 - URL: https://www.romanpichler.com/blog/stakeholder-management-tips/ - Categories: Product Leadership, Stakeholder Management - Tags: decision-making, empathy, product goal, product vision board, sprint goal, stakeholders Stakeholder management is as important as it is challenging: Without the support of the stakeholders, it is virtually impossible to achieve product success. Aligning them, however, can be tricky. In the worst case, you experience endless meetings, conflicting opinions, and bad compromises. But it doesn’t have to be this way. This article offers five practical measures to help you succeed with stakeholder management. Listen to the audio version of this article: document. createElement('audio'); https://episodes. castos. com/5e296c8fcbc2e2-83044581/2158765/c1e-68k7uopw43ck4zvx-347zzpj2t6k9-51rbyc. mp3 Focus on the Right Stakeholder The first step in succeeding with stakeholder management is to engage the right people in the right way. That’s sometimes easier said than done. Especially in bigger companies, a large number of individuals can take an interest in a product. But working with a big stakeholder group can be challenging: Involving everyone can take up a lot of time and make securing buy-in very difficult. You should therefore focus your stakeholder management effort and identify the key stakeholders. To do this, carry out a stakeholder analysis using a tool like the Power-Interest Grid, shown in Figure 1. Figure 1: Power-Interest Grid As its name suggests, the grid analyses the stakeholders and divides them into four groups by considering their power and interest: players, subjects, context setters, and crowd. Once you’ve established the four groups, decide how to engage with them. The stakeholders you should focus on and closely align with are the players—these are your key stakeholders. Earn their trust, communicate with them regularly, and involve them in important product decisions, as I explain in more detail later. Interacting with the other groups is still important, but should require significantly less effort. My advice is to consult with the context setters, who often are senior stakeholders, like a head of development. Engage the subjects, for example, by sharing the product roadmap and collecting their feedback on new features and releases. Finally, keep the crowd informed, for instance, by sending them quarterly updates. Build Trustful Connections Trust is the magic ingredient in stakeholder management: When people trust you, they are more likely to agree with you and follow your lead. To build trust with stakeholders, follow the five recommendations below. Show that you have the right product management competence. You should know the market/domain, including user and customer needs, the competitive landscape, and relevant trends. Additionally, you should be able to methodically solve product management challenges, for example, being able to create an effective product strategy, build an actionable product roadmap, and select the right KPIs. Empathise with the stakeholders and take an interest in their needs and motivations. Make time to get to know the individuals, for example, by having coffee together; practise active listening and listen with the intention to understand. Act with integrity. Be truthful and do what you say. Share successes and issues honestly. Don’t sugarcoat problems and don’t overstate achievements. Be accountable and take ownership of your actions and their results. Don’t promise something that you cannot keep, and deliver on your promises. Be willing to apologise for a mistake. Encourage continuity. An individual should be a key stakeholder for an extended period of time—at least for 12 months, as a rule of thumb. This helps build trust; it reduces handoffs, delays, and loss of knowledge; and it increases productivity. Bear in mind that building trust takes time, consistency, and patience. Don’t think of it as a quick, one-off effort. Make it a part of your stakeholder management work, and continuously look for opportunities to foster trust and strengthen relationships. Set the Right Outcomes To deliver a successful product, you must align the stakeholders and move forward together. Establishing the right outcomes will help you with this. While every product, team, and organisation are unique, I find that product teams generally benefit from using the four types of outcomes captured in Figure 2. Figure 2: Four Types of Outcomes The first outcome in Figure 2 is the vision. It describes the ultimate purpose for creating the product and the positive change it should bring about. The second element is the user, customer, and business goals. They state the needs a product should address, and the business benefits it should offer. I recommend capturing the outcomes in the product strategy using, for example, my Product Vision Board. With user, customer, and business goals in place, you can take the next step and determine the right product goals. These are the specific outcomes, or objectives, the product should create, for example, increase conversion or reduce churn. They typically cover a two to three-month time frame and may be shown on an outcome-based roadmap like my GO Product Roadmap. In many ways, the product goal is the most important outcome to achieve stakeholder alignment. If everyone supports the current goal, deciding whether a feature should be implemented becomes comparatively easy: If it helps you achieve the outcome, accept it. Otherwise,... - Published: 2025-09-08 - Modified: 2025-09-16 - URL: https://www.romanpichler.com/blog/product-strategy-okrs-and-kpis/ - Categories: Product Vision and Strategy - Tags: GO product roadmap, KPIs, OKRs, product vision board Product strategy, OKRs, and KPIs are popular product management frameworks. But how can they be applied successfully together? What comes first, strategy, OKRs, or KPIs? Can OKRs describe or replace strategy? And what should you do when a senior stakeholder tells you what OKRs and KPIs to use? Read on to find out my answers. Listen to the audio version of this article: document. createElement('audio'); https://episodes. castos. com/5e296c8fcbc2e2-83044581/2135499/c1e-gj41tm0ppwhwv0kd-8dq11z5wimqk-rahtdm. mp3 The Big Picture Product strategy, objectives and key results (OKRs), and key performance indicators (KPIs) are three distinct frameworks. When applied properly, they reinforce each other, as Figure 1 shows. Figure 1: Product Strategy, OKRs, and KPIs The product strategy in Figure 1 describes the approach chosen to make a product successful. It forms the basis for selecting the right objectives, and the OKRs state how the strategy will be implemented. Strategy and objectives help choose the right indicators. The metrics then help determine if the strategy is working and the objectives are met. Let’s look at the three frameworks and their relationships in more detail. Product Strategy The product strategy is essentially a decision-making framework. You can think of it as a consistent set of choices that guide product discovery and delivery by answering the following four questions: Who is the product for? Who are the users and customers? Why would people want to use and buy it? What problem does it address, or what benefit does it offer? What kind of product is it? Why would people choose it over alternatives? What are the business goals? What benefits does the product create for the company that develops and provides it? What a product strategy is not, at least in my mind, is a set of objectives. While you may want to capture user and customer needs, as well as business goals, in your strategy, these are usually not measurable and time-bound. For example, the need, which a healthy-eating app addresses, might be to reduce the risk of developing type 2 diabetes. To put it differently, a product strategy is more than a collection of OKRs. It provides the basis for discovering the right objectives. If you are looking for a tool to capture the product strategy, try my Product Vision Board, shown in Figure 2. You can download it, together with a handy checklist, from my website, and you can find guidance on how to use it in the article The Product Vision Board. Figure 2: A Tool to Capture the Product Vision and Strategy OKRs Objectives and key results, or OKRs for short, are a goal-setting method originally developed at Intel in the 1970s. The objective describes what you want to achieve. The key results state the criteria that have to be fulfilled to meet the objective. OKRs are great to capture product goals, the specific outcomes a product should create. For instance, an objective for the first version of an app that reduces the risk of developing type-2 diabetes might be to help users understand their eating habits and acquire an initial user base. As this example shows, product-related OKRs can help you state how you intend to execute the strategy. In other words, an objective should be a step towards meeting the needs and business goals. Conversely, if you lack an effective product strategy, you will struggle to discover the right objectives and key results. As mentioned before, the strategy is the basis for setting the right product-related OKRs. Therefore, don’t blindly accept objectives put forward by senior stakeholders. Use the product strategy to determine which ones you should pursue and which ones you should discard—at least for the time being. If you work with a product roadmap, you can include your OKRs in the plan. Figure 3 illustrates how this can be done. Figure 3: OKRs and the GO Product Roadmap Figure 3 shows the elements of the GO Product Roadmap, an outcome-based roadmap which I have developed and which you can download for free from my website. The goal corresponds to the objective, and the date or time frame, features, and metrics can be regarded as key results, as I explain in more detail in the article OKRs and Product Roadmaps. Does this mean that you should or even have to use OKRs to successfully manage your product? No, it doesn’t. What you should use are outcome-based goals that state the specific benefits your product should create or the problems it should address. If OKRs help you with this, that’s great. If they don’t, don’t worry. KPIs Key performance indicators, finally, are metrics that measure how much value a product is creating. Examples of common KPIs include monthly recurring revenue (MRR), customer satisfaction score (CSAT), and daily active users (DAU). Note that KPIs are different from OKRs. As mentioned before, the latter state the outcomes you want to create... - Published: 2025-07-07 - Modified: 2025-08-18 - URL: https://www.romanpichler.com/blog/5-product-vision-mistakes-you-should-avoid/ - Categories: Product Vision and Strategy - Tags: alignment, emotion, product life cycle, product vision board, stakeholders The product vision can be a powerful vehicle for creating a shared purpose, inspiring people, and galvanising them. Unfortunately, I have seen many visions that did not fulfil their potential, as they suffered from a number of mistakes. In this article, I discuss five common issues and explain how you can avoid and correct them. Listen to the audio version of this article: document. createElement('audio'); https://episodes. castos. com/5e296c8fcbc2e2-83044581/2082332/c1e-78qvu99620a502pn-8dq48vx0f99w-ipqzup. mp3 Confusing Vision with Strategy For a product vision to be effective, it is best captured by a simple, easy-to-understand statement or slogan. For example, the vision for a presentation tool like Microsoft PowerPoint or Google Slides might be “inform and inspire people. ” What the product vision shouldn’t be, though, is a strategic decision-making framework. It shouldn’t capture elements like the target group, value proposition, and business goals. This would not only detract from its main objective, but it would also cause it to overlap with the product strategy and make it unstable. A product’s target group and value proposition will change as it develops, grows, and serves a larger audience with more diverse needs. Its business goals are likely to change, too. Initially, the objective might be to acquire users and start generating revenue. But at a later stage, it might shift to maximising profitability. Keeping the vision free from strategic decisions provides it with a clear focus and stability. No matter how much the product and its strategy change, the vision offers continued inspiration and guidance, much like the North Star has been a vital navigational reference for centuries, helping travellers find their way. I therefore recommend that you clearly distinguish between a product vision and a product strategy. Use the former to state the ultimate reason for offering the product and the latter to describe the approach you’ve chosen to realise the vision and achieve product success. A useful tool for this is my Product Vision Board, shown in Figure 1. You can download the template together with a handy checklist from my website. Figure 1: Product Vision Board In Figure 1, the vision is captured at the top, and the strategy is described in the bottom four sections of the canvas: target group, needs, product, and business goals. This allows you to show the vision and strategy in one place while describing them separately. Tying the Vision to a Product Idea or Business Objective The second mistake I see product teams make is to state the solution and/or a business goal in the vision. Take a vision like “be the number one slideware product in the UK” for a presentation software like PowerPoint. Referring to the actual product (slideware) and a business goal (number one in the UK) creates two problems. First, it makes the vision unstable. As mentioned above, products change across their life cycle. Take PowerPoint, for instance, which changed from a humble presentation tool to a product that offers real-time cloud-based collaboration and AI-powered content and design creation. Second, such a vision fails to provide a meaningful purpose, as it does not state the underlying reason for offering the product. It will consequently struggle to inspire the product team members. I therefore recommend that you use the vision to capture the positive change you want to bring about and the ultimate reason for providing the product, without referring to the solution and business goals. Focus on the why, not the what. To do this, ask yourself what the world will look like when the product has achieved its purpose. How will it have improved people's lives? What will have changed for the better? Using a Vision that Fails to Inspire People “If you are working on something exciting that you really care about, you don’t have to be pushed. The vision pulls you,” Steve Jobs once said. Creating such a forward momentum is one of the benefits a product vision should offer. Unfortunately, I’ve seen many visions that failed to move and unite people. To address this issue, apply the following two recommendations: First, involve the key stakeholders and development team members in setting the vision and ensure that everyone is happy with the result. A great way to do this is to run a collaborative workshop and co-create the vision. Applied correctly, this approach maximises the chances of finding a product vision everyone supports. Such a vision is especially valuable when problems and conflicts occur. It reminds people of why they do what they are doing and what unites them. Second, look for a vision that speaks to people, that generates a positive emotional response. It should ignite their imagination and make them excited about working on the product. Choose words that resonate with people and inspire meaningful action. Does the vision make people feel enthusiastic, proud, or happy, for example? If that’s not the case, adapt the... - Published: 2025-06-09 - Modified: 2026-03-26 - URL: https://www.romanpichler.com/blog/strategy-and-product-teams/ - Categories: Product Leadership, Product Roles, Product Vision and Strategy - Tags: business strategy, empowerment, portfolio management, product team, product vision board Strategy and product teams are both key to achieving product success. But what exactly do we mean by strategy? Which one is most relevant for product teams? To what extent should the teams shape strategic decisions? And what role does the head of product play? These are the questions I discuss in this article. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/2060185/c1e-kom3bgjmkzfg8xnk-z32gz3v8a4x-zyibhh. mp3 What is Strategy? Strategy derives from the ancient Greek word strategos, which means army leader or general. For centuries, the term was primarily used in a military context to describe how battles were fought. Today, there is an abundance of strategies—think of business, marketing, sales, technology, operations, and, of course, product strategy, for example. Fortunately, only a few strategies are important for product teams. These are captured in Figure 1. Figure 1: The Strategy Stack The Strategy Stack in Figure 1 consists of five layers and seven elements. These are the business strategy, which is also referred to as corporate strategy, the product portfolio strategy, the technology strategy, and the product strategy, as well as the product roadmap, the technology roadmap, and the product backlog. The backlog is not a strategic plan, but I’ve added it to the stack to show how strategic decisions can be translated into tactical ones. Note that I’ve ordered the elements according to their importance, with the most important at the top. As a consequence, higher-level strategies guide lower-level ones. For example, the business strategy guides the portfolio strategy, which directs the product strategy. The latter, in turn, drives the product roadmap, which directs the product backlog. This creates alignment and ensures that the decisions across the different layers are consistent. Product Strategy and Ownership Out of the four strategies shown in Figure 1, the product strategy is most significant for a product team. It describes the approach chosen to achieve product success. To do this, I find it helpful to describe the following four elements: The target group—the users and customers who should benefit from the product. The needs—the problem the product should help solve for the users and customers, or the benefit it should offer. The business goals—the benefits the product should generate for the company that’s developing and providing it. The standout features—those aspects that make it special and set it apart from competing offerings. If you are looking for a tool to capture the product strategy, try my Product Vision Board, which you can download for free together with a handy checklist from my website. Figure 2: The Product Vision Board Traditionally, the product strategy is owned by the head of product, the person in charge of the product management group. Sometimes, the role is also called Chief Product Officer and VP or Director of Product Management, depending on the size and structure of the organisation. Having a single individual in charge of the strategy can offer consistent decision-making and close alignment: Different product teams are guided by the head of product’s decisions. However, this approach has several drawbacks, too, including the following four: Slow decisions: The head of product can become a bottleneck, especially when the portfolio grows and more products are added. Consequently, decisions might be delayed, and product teams might not be able to quickly progress their products. Being overworked: The head of product can become overworked. As a people manager, they have to look after the individual product people and the entire product management group. Consequently, they can experience stress, reduced productivity, and, in the longer term, health issues. Strategy-execution chasm: If the product team members don’t fully understand or sufficiently buy into the product strategy, a strategy-execution chasm can open up, and the strategy is not effectively translated into detailed product decisions. The UX and product features may therefore not align with the strategy. Lack of in-depth knowledge: The head of product might be too far removed from the day-to-day product management work to fully understand the impact of strategic product decisions. At the same time, this can make it difficult to leverage insights from the product discovery and delivery work to adapt and evolve the product strategy—think of user feedback you collect on early product increments, for example. In the worst case, the wrong strategic decisions are taken. Empowering Product Teams to Make Strategic Decisions If having the head of product in charge of product strategy is not always effective, then what’s the alternative? My recommendation is to empower product teams to own the strategies of their products. Consequently, a product team is given the authority to create and evolve the product strategy over time. This offers three key benefits: Fast decision-making and strategy-execution alignment: The product strategy, discovery, and delivery work are now carried out by the same people. This speeds up the decision-making process and maximises the chances that strategic decisions... - Published: 2025-05-12 - Modified: 2025-06-09 - URL: https://www.romanpichler.com/blog/innovation-ambition-matrix/ - Categories: Product Vision and Strategy - Tags: innovation, portfolio management What do incremental enhancements of a legacy app and the development of a new AI product have in common? Both have to create value and innovate to some extent. In this article, I discuss the Innovation Ambition Matrix, a tool that helps you understand your product’s innovation type and, based on it, make the right strategic decisions and optimise your product portfolio. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/2038569/c1e-5q54u1gvk0tq4n83-0vkv3wpzi48-l1pmtj. mp3 Overview of the Matrix The Innovation Ambition Matrix, which was developed by Bansi Nagji and Geoff Tuff, considers the newness of the product on its horizontal axis and the newness of the market on the vertical axis. This allows us to distinguish three different innovation types: core, adjacent, and disruptive, as Figure 1 shows. Figure 1: The Innovation Ambition Matrix Note that Nagji and Tuff use the term transformational instead of disruptive. Some people also refer to core innovations as incremental and to adjacent ones as evolutionary. Core Innovations Core innovations optimise existing products for established markets. They draw on the skills and assets your company already has in place, and they make incremental changes to current products. These initiatives are truly core to your business, as they generate today’s revenues. Most of your company’s products are likely to be in this category—unless you work for a start-up. Examples of core innovations include Microsoft Windows and Microsoft 365, formerly known as Office. Both are major revenue sources for the company. The longer-term growth potential of core products, however, is low, and so is the amount of risk and uncertainty present. If you think of the product life cycle and its stages, then core innovations typically correspond to mature products. Adjacent Innovations Adjacent innovations take something your company does well into a new space—for instance, offering an existing product in a market that’s new to the company or creating a new product for a market you already serve. Take, for example, the Apple Watch and the Google Chrome browser. In both cases, the companies entered existing markets—wearables and web browsers, respectively—with a new product. Disruptive Innovations Adjacent innovations provide you with the benefit of leveraging existing assets. This makes the challenge of innovating successfully more manageable, at least to a certain extent. Unfortunately, they also have a significant disadvantage. They address an existing market, and their growth prospects are limited by your ability to grow the market and capture more market share—that is, to attract more users and customers. To experience higher long-term growth, your company has to invest in disruptive innovations. Apple, for instance, disrupted the mobile phone market with the original iPhone; Nintendo did the same in the games console market with its Wii; and Amazon disrupted the retail book market with its online store. The Innovation Ambition Matrix and Product Strategy Once you know your product’s innovation type, you can use it to understand the strategy work required and make the right strategic decisions. Core Innovations As they are crucial to generating the necessary profits, you should protect your core products. Focus on incrementally enhancing features, fixing bugs, and optimising the existing business model. Since the amount of uncertainty is low, the strategizing effort is comparatively small. You should therefore focus on continuous strategizing: Spend a few hours per week to review the product performance using the appropriate KPIs, carry out competitor research, discover relevant trends, and hold quarterly strategy workshops to look at bigger development and adjust the product strategy. Adjacent Innovations Things are different when it comes to adjacent products. To succeed with them, you’ll have to carry out product strategy discovery, research the market, develop a thorough understanding of the user and customer needs, as well as the competitive landscape and relevant trends. Additionally, you may have to investigate new technologies and review whether the current business model needs to be adapted. You must therefore be able to take informed risks and feel safe to experiment and make mistakes. As the amount of risk and uncertainty present is considerably higher than in core innovations, you require more time to discover an effective product strategy, often several weeks to a couple of months. Disruptive Innovations As important as disruptive products are for enabling future growth and securing the long-term prosperity of your business, most established companies struggle to leverage them effectively. Here is why: To achieve disruption, a company must do things differently and disrupt itself, at least to a certain extent. It has to discontinue some of the practices that have helped it become successful, acquire new skills, find new business models, and often embrace, and in some cases develop, new technologies. Think of the touch screen for the iPhone and the motion controller for the Wii, for example. The effort to create an effective product strategy is therefore even higher than for adjacent innovations. It may take you several months to find... - Published: 2025-04-07 - Modified: 2026-05-11 - URL: https://www.romanpichler.com/blog/ai-and-product-strategy/ - Categories: Product Vision and Strategy - Tags: ai, decision-making, empathy, ethics, innovation AI has significantly impacted software-based products and has started to change how product management is practised. But how is it affecting product strategy? Can AI-powered tools lead to better strategies? Can they even make strategic product decisions on their own? In this article, I discuss the benefits and limitations of using AI to create a product strategy, as well as the foundations you should put in place to take full advantage of AI tools. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/2007708/c1e-12nzi59j18h62qwg-gp32m97jf6-pyqt3q. m4a AI Strategy Benefits My research shows that AI can help you make better strategic decisions faster, at least for certain products. Below are four examples of how this can be achieved. Note that I’ve decided not to state the names of the tools I found, partly as the AI landscape is changing rapidly and partly as you should research and select the tools that work best in your context rather than trusting my judgment. Market Research AI-based tools can discover user and customer trends using predictive analytics. This can help you create a new strategy and evolve an existing one. It assumes, though, that enough good-quality data is available to make reasonably reliable predictions. This is unlikely to be the case for disruptive innovations, as I discuss below, as well as specialised products with a comparatively small user base, like tailored IT solutions. Customer Insights and Idea Generation AI tools can analyse market data, customer feedback, and emerging trends to suggest new products and features, assuming that enough relevant data is available. For example, you can use an AI tool to analyse support tickets to discover and address common issues. You might even ask a chatbot like ChatGPT to come up with ideas to understand if you have missed any opportunities. Product Differentiation AI tools can help you make your product stand out from the crowd and offer a clear reason for people to choose it over alternatives. This can be achieved in two ways: First, data mining can identify opportunities for differentiation, assuming that the relevant data exists. Second, offering AI-enabled product features, including a personalised user experience and user-specific recommendations, can give your product a unique advantage. Take Spotify’s DJ and TrainerRoad’s TrainNow features, for instance. The former is a virtual assistant who recommends favourite songs and allows listeners to discover new music. TrainerRoad is an indoor cycling app that offers personalised training plans. Its TrainNow feature suggests a workout for users who do not follow a structured plan but want to train whenever they feel like it and still get the right workout recommendation. Product Performance and KPIs AI tools can continuously monitor how much value a product is creating and recommend improvements. This helps you understand if the current strategy is still valid or if it needs to be adapted. This, in turn, can facilitate continuous strategising and maximise the chances of proactively responding to opportunities and threats. What about Product Roadmap Generation? You might have noticed that I didn’t list the creation of product roadmaps as an AI benefit, even though several tools offer it. There are two reasons for this: First, the AI-generated roadmaps I came across during my research were feature-based, which is a roadmapping approach I don’t recommend. Second, it wasn’t clear to me if and to what extent the roadmap elements were guided by an overall product strategy. This is necessary, though, to ensure that the roadmap is aligned with the strategy and that user needs and business goals are translated into more specific outcomes. AI Strategy Limitations While it can be of great help, AI is no silver bullet. You should be aware of the following five limitations when using AI tools to discover and evolve a product strategy. Data Dependency and Risk of Biases As mentioned earlier, AI tools require enough good-quality data to generate helpful results. If you don’t have sufficient data available or if the data quality is not right, if, for example, it contains cognitive biases, you are unlikely to benefit from using AI tools. In the worst case, you get the wrong results and make the wrong decisions. Probability vs. Accuracy Generative AI tools give the most likely answers, not necessarily the correct ones. Their predictions are based on degrees of confidence rather than absolute certainty. Consequently, you should consider if AI-generated results are likely to be good enough. As a rule of thumb, the higher the impact of a decision is, and the harder it is to reverse it, the more certainty you require. Additionally, you should review AI-generated answers rather than blindly trusting a tool, even if the results sound very convincing. For example, while researching AI tools for this article, I used several chatbots, including Perplexity. Reading the references used by the latter, I found that most of the time, the bot did a great job at extracting and summarising information—but not always. Hard to Apply Disruptive Products AI’s data... - Published: 2025-03-03 - Modified: 2025-05-01 - URL: https://www.romanpichler.com/blog/setting-up-product-teams-for-success/ - Categories: Product Leadership, Product Roles - Tags: empowerment, head of product, product team, teamwork Product teams are key in enabling product-led growth and offering successful products. In this article, I explain what product teams really need to do a great job and how you can best support the teams you work with. I also offer a comprehensive questionnaire in the article so you can design successful product teams and get them off to a great start, or if they are up and running, provide the prerequisites that might be missing. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1984590/c1e-djknt60n1mawr0n2-1p4jz8qwcdp9-drsxgn. mp3 Product Teams: Benefits and Challenges A product team is a group of people who collaborate effectively, have ownership of a product, and are responsible for achieving product success. Product teams have become popular for a good reason: “None of us is as smart as all of us,” as Ken Blanchard once said. In other words, it is very difficult for a product person to make all decisions by themselves, even if they are very experienced. What’s more, product people rely on others to help them progress their products. This includes UX designers, developers, and testers, as well as marketers, sales reps, and customer support team members: They design, build, market, sell, and support the products. Bringing the right people together allows you to leverage their collective expertise, make the best possible decisions, and create alignment. Unfortunately, it’s not uncommon for product teams to struggle. I’ve met teams who lacked the right team members and skills, were not empowered to effectively progress their products, and suffered from frequent changes to the team composition, to name just a few issues. Consequently, their products had a weak value proposition, offered a poor user experience, and didn’t generate the desired business benefits. In sum, the teams and their products underperformed. A common leadership response is to offer coaching—trying to help the team perform better—and, in some cases, start managing the team. Despite being well-intended, this can hurt morale and further hamper productivity. Additionally, it can leave the leader exhausted and overworked. But it doesn’t have to be this way. The 60-30-10 Rule Research by the late Harvard professor J. Richard Hackman suggests that the biggest impact on a team’s performance derives from its design, not from real-time coaching interventions. This insight is captured by the 60-30-10 rule shown in Figure 1. Figure 1: Hackman’s 60-30-10 Rule Applied to Product Teams Figure 1 distinguishes three ways in which the performance of product teams can be affected: team design, team launch, and team coaching. The biggest influence on team performance, about 60%, is the team's design, according to Hackman. This includes ensuring that the right people join the product team, that the team’s goals and authority are clear, and that the team receives the right support from the organisation, as I explain in more detail in the next section. The second biggest influence comes from the team launch, roughly 30%. This includes helping the team members bond and establishing shared ways of working. Team coaching, finally, has a comparatively small impact on team performance, about 10% according to Hackman. This does not mean that it is unimportant. The opposite is true. Product teams can greatly benefit from having a qualified coach. But developing a team is like growing a plant: If it’s been put in the wrong place, if the requirements for growth are not met, then you can water and fertilise it as much as you want. It may never fully develop. In the worst case, it will wither and die. Team Design The team design comprises the necessary prep work for having a great team. This includes answering the following set of questions. What are the team’s purpose and goals? What are its responsibilities? What level of empowerment is required? Which roles and skills, both task-oriented and social, are required to meet the goals and fulfil the responsibilities? Who should join the team? Which support does the team need from the organisation? Who is the (executive) sponsor? Who is the team coach? Which tools and environment does the team require? Does the team need a team room or other facilities? The questions above are a subset of a comprehensive questionnaire I have developed to help you get the team design right. You can download it by clicking on Figure 2. Figure 2: Team Design Questionnaire While you have to, of course, determine which team design is right for you, I generally recommend forming product teams that contain the person in charge of a product, a UX designer, architect/programmer, and tester, as well as key business stakeholders, like a marketer and sales rep, and a team coach. I also advocate empowering product teams to make strategic product decisions, as I explain in more detail in the article Building High-Performing Product Teams. Getting the team design right can be tricky, as you might lack the authority to establish all enabling conditions—to determine the team’s purpose, choose the members, ensure the necessary organisational support, and... - Published: 2025-02-07 - Modified: 2025-02-07 - URL: https://www.romanpichler.com/blog/product-portfolio-roadmap/ - Categories: Product Roadmap - Tags: GO Portfolio Roadmap, GO product roadmap, OKRs, planning, portfolio management, portfolio team As helpful as they can be, product roadmaps are not always enough. To closely align a group of products and ensure that they all move in the same direction, you’ll benefit from a portfolio roadmap. In this article, I explain what a product portfolio roadmap is. I show how you can use the template below to build your own outcome-based portfolio roadmap. I discuss how you can connect your portfolio roadmap to the portfolio strategy and use it to direct the product roadmaps, and I describe who should be involved in developing the plan. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1968647/c1e-gj41t3871qfwv0kd-47d74wk6tjxk-vzc4wo. mp3 What is a Portfolio Roadmap and Do You Need One? What do Microsoft 365 and Netflix have in common? Neither is a singular atomic product. Microsoft 365 is a product portfolio, a suite that contains productivity tools like Word, PowerPoint, and Excel. The Netflix app appears to be a product bundle, a collection of smaller, specialised products, including movies, series, games and live events. In both instances, I’d recommend using an overall portfolio or bundle strategy in addition to the individual product strategies. Take Microsoft 365 again as an example. If I were in charge of the suite, I’d use a portfolio strategy that guides and aligns the strategies of Word, PowerPoint, and Excel. But wouldn’t it make sense to harmonise not only the product strategies but also align the product roadmaps? And if that’s the case, wouldn’t it be helpful to use a dedicated roadmap that states the overall outcomes the portfolio or bundle should create? This is where product portfolio roadmaps come in. A portfolio roadmap states how you intend to implement the portfolio strategy and the outcomes the portfolio should create. You’ll benefit from such a plan when you manage a cohesive portfolio like Microsoft 365 or a product bundle like Netflix. Let’s make this more concrete and look at an example. How Can You Capture a Portfolio Roadmap? Imagine it’s the year 2019, and you’re in charge of Microsoft 365. To ensure everybody is clear on how the tool suite will develop over the coming years and the outcomes it should achieve, you create the portfolio roadmap shown in Figure 1. Figure 1: Sample Outcome-based Product Portfolio Roadmap If you are familiar with my work on outcome-based roadmaps, you’ll recognise the structure in Figure 1: It is based on my GO Product Roadmap template. The reason for this is simple. I’ve found that a portfolio roadmap benefits from having the same elements as a product roadmap. Consequently, you can apply my roadmapping approach not only to individual products but also to your portfolio. Having said this, there are two points I’d like to draw your attention to. First, the GO Portfolio Roadmap is built on outcomes—it’s an outcome-based, goal-oriented plan. Its goals describe the user and customer benefits the entire portfolio should create and the positive business impact it should achieve. They are its most essential element. Any feature shown on the roadmap must help meet the corresponding outcome. Consequently, you should determine the goals before you consider any features. Second, a portfolio roadmap is more coarse-grained than a product roadmap. The goals are larger, and the time frames are usually bigger. This is due to the nature of the entities we’re dealing with: A product portfolio is more sizeable than a single product. To create your own GO Portfolio Roadmap, download and adapt the GO Product Roadmap template or recreate it in your favourite tool. Please make sure, though, that you state the author and source of the template as well as the CreativeCommons license on your portfolio roadmap, as I did in Figure 1. If you haven’t worked with the GO Product Roadmap, then you’ll benefit from reading the article The GO Product Roadmap and watching the video below. https://youtu. be/NBNsnKPbah0 If you use OKRs—objectives and key results—you can view the goals in Figure 1 as objectives and the time frames, features, and metrics as key results—similar to the relationship I describe in the article OKRs and Product Roadmaps. How Does the Portfolio Roadmap Direct the Product Roadmaps? A product portfolio roadmap, like the one in Figure 1, guides the product roadmaps by establishing higher-level outcomes and time frames, which the individual products have to adhere to. Figure 2 illustrates this relationship. Figure 2: The Portfolio Roadmap Guides the Product Roadmap Take Microsoft 365 again as an example. The portfolio roadmap in Figure 1 states “Allow users to easily access standalone apps and increase the attractiveness of the suite” as the portfolio goal for 2020. This means that all products, including Word, PowerPoint, and Excel, will have to contribute to this goal in the time frame stated. The product teams hence have to figure out what their specific contributions will have to be. The Word team, for example, would identify the impact on their roadmap and adjust the plan accordingly. To put it differently, meeting the product goals must help achieve the portfolio objectives. As a consequence, a product roadmap is no... - Published: 2025-01-20 - Modified: 2026-05-11 - URL: https://www.romanpichler.com/blog/product-strategy-system/ - Categories: Product Vision and Strategy - Tags: GO product roadmap, product team, product vision board, stakeholders, validation When it comes to product strategy, people often focus on templates, tools, and frameworks. While these matter, they are only a small part of what’s needed to develop a successful strategy. In this article, I take a holistic approach and discuss product strategy from a system perspective. I consider people, processes, and principles in addition to tools, I share the strategy system I have developed and explain how you can take advantage of it. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1945790/c1e-o07nbvk3goud5mkg-ww68r7mwhxo2-6v9xah. mp3 A Product Strategy System The product strategy system in Figure 1 consists of four main parts: people, processes, principles, and tools. Like any system, it is a collection of interconnecting parts that function as a whole. To put it differently, an effective product strategy approach must involve the right people, use the right processes, apply the right tools, and follow helpful principles. Additionally, the different parts have to fit together and support each other. Having said this, the system in Figure 1 captures the specific product strategy approach I’ve created. Figure 1: A Product Strategy System You can use the model in Figure 1 to review and improve your current product strategy approach. To do so, ask yourself the following questions: Are the right people involved in determining the product strategy? Are they properly empowered and adequately qualified? Are the right processes used? Are the right tools applied? Do they support each other? Do you follow helpful principles that guide the strategy work? If so, what are they? Additionally, you can use the model to build your own strategy system. Be aware, though, that a change in one area, like adopting a continuous strategizing process, may impact other elements, including the people involved in the strategy work. Therefore, ensure that your system is consistent—that its components are carefully chosen and fit together well. Let’s now take a closer look at the four main elements of the strategy system in Figure 1, starting with People, the most important one. People To make the right strategic product decisions, it’s crucial to involve the right people and understand who has the final say on strategic product decisions. I am a big advocate of empowering product teams to not only own product discovery but also the product strategy. Additionally, I like to engage the key business stakeholders and form an extended product team, as shown in Figure 2. This leverages their expertise, creates strong alignment, and maximises buy-in. Figure 2: The People Involved in the Strategy Work The team in Figure 2 consists of the person in charge of the product, a UX designer (for end-user-facing products), an architect/programmer, and a tester, as well as the key business stakeholders. The latter are the individuals whose expertise and support you require to make the right product decisions and successfully implement them. Additionally, the group contains a coach who facilitates teamwork and helps the members practise collaborative decision-making. Note that the product person in Figure 2 has to be empowered to lead the strategizing effort and have the final say if no agreement can be reached. This ensures consistent decision-making and prevents the team from getting stuck in endless arguments. If extended product teams own the product strategies, what’s the role of the head of product, also called Chief Product Officer and Director/VP of Product Management, in making strategic decisions? There are two effective ways in which the individual can be involved. First, as a coach who offers strategy and leadership guidance to the person in charge of the product. Second, as a product portfolio manager who ensures that an effective portfolio strategy is available, which directs the product strategies. Processes With the right people on board, we can take the next step and discuss how the strategy work can be carried out. I find it helpful to distinguish two processes: product strategy discovery and continuous strategizing. Product Strategy Discovery As its name suggests, product strategy discovery is about finding an effective product strategy—be it for a brand-new product or an existing one whose current strategy is no longer valid. It’s consequently not only relevant to developing an initial offering (MVP) but also to achieving product-market fit and extending the product lifecycle. A great way to discover an effective product strategy is to capture your initial ideas, using a tool like my Product Vision Board, and then systematically correct and refine them. Figure 3 illustrates how this can be done. Figure 3: Product Strategy Validation Start the process by identifying the biggest strategy risk. Then, determine how to address it, for instance, by interviewing target customers or creating a throwaway prototype. Next, collect the relevant data. Finally, evaluate the data, generate new insights, and decide what to do: Should you persevere with the current strategy, pivot and significantly change it, or kill the innovation initiative? For a more detailed discussion, please see my article Product Strategy Discovery. Don’t forget to involve the members of... - Published: 2024-12-02 - Modified: 2025-09-25 - URL: https://www.romanpichler.com/blog/how-to-leverage-conflict-in-product-management/ - Categories: Product Leadership, Stakeholder Management - Tags: conflict, emotion, empathy, innovation, stakeholders It may not be pleasant to experience, but conflict is necessary to innovate successfully. Without competing ideas, it's virtually impossible to create great products. Unfortunately, many conflicts are handled poorly; they are hidden or result in personal attacks. In this article, I explain how you can skilfully navigate conflict and use it as a source of creativity and innovation for your products. Listen to the audio version of this article: document. createElement('audio'); https://episodes. castos. com/5e296c8fcbc2e2-83044581/1912171/c1e-78qvu41vzpt502pn-jpj6m56kc7nx-wxbmmz. mp3 Why Conflict Matters Conflict is often seen as something bad that should not occur. But in fact, it’s perfectly normal. It commonly happens when people with different perspectives, needs, and goals engage. This is especially true in product management. As product people, we work with individuals from various business units or departments with different views and ideas. Think of the salespeople, marketers, and customer support team members, as well as the UX designers, architects, programmers, and testers you might interact with. What’s more, innovation relies on conflict. How can you create something new and amazing when everybody quickly agrees? In the worst case, you practise design by committee, broker a weak compromise, and agree on the smallest common denominator. But that’s hardly a recipe for achieving product success. Innovation requires diverging ideas and passionate arguments; it requires the willingness to experience and resolve conflict. Additionally, effective collaboration and teamwork rely on the ability to leverage conflict. Otherwise, teams will find it difficult to perform well and become truly productive, closely-knit units. What Gives Conflict a Bad Name Sadly, conflict is often poorly handled, especially at work. Most disputes I have witnessed were not dealt with properly; many were never resolved. Often, the conflict is suppressed or ignored—it’s swept under the carpet. Say you strongly disagree with the way a senior stakeholder talks to you and requests a new feature. But instead of addressing the issue, you pretend that all is well. Other times, the conflict escalates and turns into a verbal fight, in which the more senior, powerful person typically wins. In both cases, the conflict has turned toxic. It leaves behind a trail of bad feelings and mistrust. Relationships are damaged, and effective collaboration is difficult, if not impossible, to achieve. What's more, suppressing the negative emotions, which are usually present in a conflict, increases your stress levels and can harm your mental health. Resolving Conflict with Non-Violent Communication So, how can you deal with disputes constructively? How can you have good, healthy conflicts? One way to achieve this is to use Non-Violent Communication (NVC), a conflict resolution framework developed by Marshall Rosenberg. It consists of the four components shown in Table 1: Table 1: The Four Components of Non-Violent Communication The framework in Table 1 offers a structure to break down conflict into its key elements and address them step by step. You start by sharing each other’s perspectives. Then, you explore the feelings that are present and connect them to underlying, unmet needs. Following this process builds trust and understanding. It puts you in the position to make a request and address the root cause of the conflict. Conflict resolution is therefore not about winning, retaliating, or putting the other person in their place. It’s about establishing a dialogue, developing a shared perspective on what happened, agreeing on the changes required, re-establishing trust, and rebuilding the relationship. To put it differently, if you believe that you are right and the other person is entirely to blame, and if you are not prepared to change your own behaviour, if required, then you won’t be able to apply the NVC framework; resolving the conflict will not be possible. The Non-Violent Communication framework might be simple, but it can be hard to put in practice. The following tips will help you effectively use it. Step 1: Observations The best way to start the process is to schedule a meeting with the other person so you can have a focused and confidential conversation. Clearly state what you saw happening and what you heard the individual say. Avoid criticism, judgment, or blame. Stick to the facts and purely state your observations. As Oren Jay Sofer writes in his book Say What You Mean, “The less blame and criticism are in our words, the easier it will be for others to hear us and to work toward a solution. ” However, sharing your observations is only part of what needs to happen. The other, sometimes more challenging aspect is to attentively listen while refraining from quickly criticising or dismissing what you hear. This does not mean that you have to agree with the other person. But it allows you to understand their perspective, which is a prerequisite for resolving the dispute. To succeed with step one, make sure that you don’t engage in a blame game. Don’t label the other person, for example, as difficult, mean, bad, or selfish.... - Published: 2024-11-11 - Modified: 2026-04-29 - URL: https://www.romanpichler.com/blog/the-product-strategy-and-the-product-life-cycle/ - Categories: Product Vision and Strategy - Tags: product life cycle, product vision board, validation Developing a winning product strategy is hard. Keeping the strategy relevant and achieving continued product success is even harder. In this article, I discuss how you can use the product lifecycle model to address this challenge. I explain how the model can help you make the right strategic choices, focus and evolve the product strategy, and effectively grow the product. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1882185/c1e-35zvt57072hw461n-z39wo9rvhpv1-1sberv. mp3 A Brief Introduction to the Product Lifecycle Model As its name suggests, the product lifecycle model describes how a product develops over time. It assumes that it has a life much like a living being. A product is born or launched; it then develops, grows, and matures. At some point, it declines and eventually dies. Consequently, the model shown in Figure 1 has five stages: development, introduction, growth, maturity, and decline. Figure 1: The Product Lifecycle Model with Key Events and Chasm Take Apple’s iPod as an example. The product was launched in 2001 as the company’s first consumer music gadget in a market, which at the time was dominated by products like the Nomad Jukebox from Creative Labs. Making the iPod Windows-compatible and launching iTunes helped the product bridge the chasm shown in Figure 1, achieve product-market fit, and enter the growth stage in 2004. iPod sales reached their peak in 2008, which also marked the start of the maturity stage. In 2009, sales started to decline. In 2014, Apple discontinued the original iPod and in 2022, the company finally retired the entire product line. But that’s not the only way the life of a product can unfold. Instead of accepting maturity and letting your product age gracefully, you can try to rejuvenate it and extend its life cycle. Figure 1 therefore contains a second, smaller life cycle, which piggybacks onto the first one. Products can, in fact, benefit from repeated life cycle extensions. Take the iPhone as an example, which was first launched in 2007 and whose life has been prolonged multiple times, for instance, by offering new and enhanced features like Face ID as well as different models for different segments. In addition to the five stages, Figure 1 contains four important events in the life of a product: Launch: An initial product, the minimum viable product (MVP), becomes available. Product-market Fit (PMF): The product is ready to serve the mainstream market. Life Cycle Extension: The product’s life is prolonged, for example, by taking it to a new market. End of Life: The product is discontinued. While the curve in Figure 1 is roughly bell-shaped, your product’s actual trajectory may differ significantly: It may be much steeper or flatter. The life cycle model is hence not a predictive tool that forecasts the value a product will generate. It is a sense-making one that helps you understand where a product is in its life cycle. To leverage it, you have to define the value your product creates and track it over time. The former is done by discovering an effective product strategy; the latter is achieved by using the right key performance indicators (KPIs). While the product lifecycle model was originally developed for commercial, revenue- generating products, I find that it is also applicable to supporting products like a mobile banking and an internal software platform, as long as you choose the right metrics to measure value and track the progress of the product. Four Benefits for Making the Right Strategic Product Decisions The product lifecycle model offers four specific benefits to help you make the right strategic decisions for your product. Focus: The model helps you focus and adapt the strategy. For example, in the development stage, your strategy should help you get to launch. In the introduction stage, its focus should be to achieve PMF. Effort: The framework helps you gauge the likely strategising effort. In Development, the effort is particularly high, as you’ll have to discover an effective strategy. This may require several weeks of dedicated research and experimentation work. Contrast this with maturity, where the strategy is unlikely to experience significant changes. Mindset: The early life cycle stages require you to play an offensive game where you take the initiative, embrace an entrepreneurial mindset, and are willing to take informed risks. But once you’ve accepted maturity, you want to firm up your defence, protect the product’s position, and focus on efficiency. Innovation: Knowing at which life cycle stages their products are, enables organisations to balance their portfolios, invest early enough in new offerings, and retire declining products, as I describe in more detail in my article The Product Portfolio Matrix. Let’s now take a closer look at how the life cycle stages influence the product strategy and how the strategy might evolve across the life cycle. The Product Strategy in the Development Stage When you set out to create a new product,... - Published: 2024-10-07 - Modified: 2026-05-11 - URL: https://www.romanpichler.com/blog/when-you-should-not-use-a-product-roadmap/ - Categories: Product Roadmap - Tags: empowerment, GO product roadmap, product vision board, stakeholders The product roadmap is a popular product management tool that communicates how a product is likely to evolve. But despite its popularity, it’s not always applicable. In this article, I share three scenarios in which using a roadmap is not advisable. I explain why that is, what you can do instead to plan ahead, and which steps you can take to get closer to developing a realistic, actionable roadmap. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1852668/c1e-o07nbvorm5fd5mkg-gpkkz42vhmxk-ls0at4. mp3 You Can’t See Further than the Next Three Months A product roadmap should be a realistic forecast that states the specific value a product is likely to offer in the next 12 months. Creating such a forecast is not always feasible, especially when you work on a new, innovative product. If you can’t see further than the next three months, then do not use a product roadmap. Otherwise, your plan is likely to be wrong, which would lead to disappointed stakeholders and development teams. In the worst case, they’ll lose trust in your ability to guide them. Instead of building a roadmap, set a single, outcome-based goal for the next three months. The goal should state the positive impact you want to create for the users/customers and the business. An example for a healthy-eating product might be “help the users understand their eating habits and acquire an initial user base. ” Use the goal to determine which features have to be implemented to create the desired outcome, for example, offering a healthy-eating dashboard and seamless integration with leading smartwatches. A practical way to do this is to focus the product backlog on the goal you’ve chosen. Once you have achieved the goal, you will hopefully better understand how you can progress your product and be able to create a realistic roadmap. If that’s not the case, check that you have a validated product strategy, on which you can base the roadmap. You Lack a Validated Product Strategy A common cause of teams struggling to create a realistic product roadmap is a lack of a validated product strategy. Before I explain what I mean by validated, let me briefly describe what a product strategy is. A product strategy describes the approach you’ve chosen to achieve product success. It states the target group—the users and customers, their needs, the desired business goals, and the capabilities that will set the product apart from competing offerings. A handy tool to capture the strategy is my Product Vision Board, which you can download for free together with a helpful checklist from my website. A validated strategy is free of significant risks and assumptions. It is backed up by empirical evidence: You have relevant data to show that you have made the right strategic decisions and selected the right target group, needs, business goals, and standout features. Executing the strategy is therefore likely to result in a successful product. A great way to validate a product strategy is to follow an iterative, four-step process. As I explain this approach in more detail in the article Product Strategy Discovery, I’ll just provide an overview here. Start by selecting the biggest risk contained in the strategy—the uncertainty that must be addressed now so that you don’t make the wrong decisions and take the product down the wrong path. Second, determine how you can best address the risk you’ve chosen, for instance, by observing target users or building throwaway prototypes. Third, carry out the necessary work and collect the relevant data. Fourth, evaluate the results and use the newly gained insights to decide how to correct and refine the strategy. Follow this process until you’ve addressed all major risks. With a validated strategy in place, you are in a great position to build a realistic, actionable product roadmap. There are two reasons for this: First, having carried out the necessary strategy discovery work, you’ve acquired the relevant knowledge to make effective roadmapping decisions. Second, the strategy forms the basis for building an effective product roadmap. The needs and business goals stated in the strategy help you select the right roadmap goals. You may even be able to derive the outcomes on the roadmap directly from the product strategy by breaking the needs and business goals into more specific subgoals, as Figure 1 shows. Figure 1: The Product Strategy as the Foundation of the Product Roadmap Conversely, if you don’t have a validated strategy, you lack the basis for developing a realistic, actionable product roadmap. If that’s the case, stop and carry out the necessary strategy discovery work. Then continue building the roadmap. Stakeholders Dictate the Roadmap Content or View It as an Unchangeable Commitment In my coaching work, I sometimes meet stakeholders who insist on getting specific features onto the product roadmap and who expect that their features will be delivered as stated in the plan. Usually, there are two issues at play in this situation: First,... - Published: 2024-09-02 - Modified: 2026-04-14 - URL: https://www.romanpichler.com/blog/product-strategy-discovery/ - Categories: Essential Articles, Product Management Process, Product Vision and Strategy - Tags: business model, ethics, product discovery, product team, validation The product strategy is probably the most important artefact in product management. But how do you come up with an effective strategy in the first place? How can you minimise the risk of offering an unsuccessful product and instead maximise the chances of achieving success? In this article, I introduce product strategy discovery as a systematic, disciplined approach to help you develop a winning strategy for your product. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1827303/c1e-886vu9nxz2fr546q-wwz2mk03t4jz-a0cpbw. mp3 Product Strategy Discovery Explained What is product strategy discovery? In a nutshell, it’s about finding a problem worth solving. More precisely, it is the process of developing a product strategy whose implementation will likely create the desired value and impact. It applies to a brand-new product as well as an existing one whose current strategy is no longer valid, for example, as market conditions change. This means that strategy discovery is crucial not only to developing an initial offering (MVP) but also to achieving product-market fit and sustaining growth. Unlike product discovery, it is not primarily concerned with determining the right solution—finding the right features, and creating the right user experience. Instead, strategy discovery focuses on the problem space. It explores if a large enough group of people has a big enough problem that can and should be addressed. Strategy discovery therefore sets the scene for product discovery, as Figure 1 shows. Figure 1: Product Strategy Discovery and Product Discovery Now that we’ve clarified what product strategy discovery is, let’s get more concrete and discuss how you can practise it by following the three steps below. Step 1: Formulate an Initial Product Strategy Start by capturing the approach, which—you believe—will help you achieve product success. Describe the target customers and users, the needs you want to address, the value you want to create for the business, and the features that will set the product apart from competing offerings. A handy tool to formulate the strategy is my Product Vision Board, shown in Figure 2. Figure 2: The Product Vision Board as a Tool to Capture the Product Strategy You can download it for free together with a helpful checklist by clicking on the image above and you can learn more about applying it by watching the following video: https://youtu. be/rtbWVxYEgNA An effective way to create the initial strategy is to adopt a collaborative approach and invite the extended product team to a workshop. This helps you leverage the expertise of the team members, create alignment, and secure strong buy-in. It assumes, though, that the product team is empowered to make strategic product decisions, a topic I discuss in more detail in the article Building High-Performing Product Teams. While the initial strategy does not have to be perfect by any means, it has to be sufficiently specific so that you can uncover the assumptions and risks it contains. Apply the checklist I have created for the Product Vision Board to ensure that your strategy is detailed enough. For example, use relevant qualities like demographics and behavioural attributes to characterise the target group so you can tell if somebody is included or not. Capture the main reason why people would want to use the product when describing the customer and user needs. Clearly state the problem the target group wants to have solved, the benefit they want to attain, or the job they want to get done. If you struggle to detail the initial strategy, you may lack the necessary knowledge, or you might be mixing up the portfolio and product strategy. In the first case, pause the strategy discovery work and carry out just enough market discovery. This may include conducting surveys, interviewing users and customers, mapping the consumption chain, and performing competitor research and analysis. In the second case, clearly distinguish between a strategy for a single product and a portfolio, as I explain in the articles The Strategy Stack and Everything You Need to Know About Product Portfolio Strategy. Step 2: Correct and Refine the Product Strategy With an initial, good-enough strategy in place, you are ready to take the next step. While your strategy might sound compelling, chances are that it contains assumptions and risks. For example, the market you’ve chosen might be too small or too diverse, the need for the product might not be strong enough, or the technologies required might not be available. To maximise the chances of offering a successful product, you should systematically address these risks and correct and refine the product strategy before committing to it. To put it differently, you should validate the strategy. A great way to achieve this is to follow an iterative, risk-driven approach. Start by selecting the biggest risk contained in the strategy—the uncertainty that must be addressed now so that you don’t make the wrong decisions and take the product down the wrong path. Strategy risks are related to desirability, feasibility, viability, and ethicality.... - Published: 2024-08-12 - Modified: 2024-12-06 - URL: https://www.romanpichler.com/blog/stakeholders-on-the-product-team/ - Categories: Product Leadership, Product Roles, Stakeholder Management - Tags: product team, Scrum Master, stakeholders, teamwork A product team is a cross-functional group whose members work together to achieve product success. Most people would agree that the person in charge of the product, a UX designer, and one or more developers should be on the team. But if stakeholders should be included, is less clear. In this article, I discuss two types of product teams, core and extended ones. I explore the benefits and challenges of using a larger team that includes the key stakeholders, and I share practical tips to make this approach work. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1806515/c1e-00r1bjd27va691np-pk9rojd5ad80-zdulrp. mp3 The Core Product Team Product teams come in different shapes and sizes. But all product teams I have seen consisted of the person in charge of the product—the product manager or Scrum product owner—and development team members. Together, they form the core product team. Depending on the number and size of the development teams, you may want to include all development team members or ask the teams to nominate representatives to join the product team. Make sure, though, that the necessary skills are represented. For an end-user-facing digital product, this usually requires a UX designer, an architect/programmer, and a tester/QA engineer to be members of the product team, as Figure 1 shows. Figure 1: The Core Members of the Product Team The Extended Product Team Assembling a product team like the one in Figure 1 is great for carrying out product discovery and delivery work—for determining the right user experience and features and deciding how to best implement them. Such a team, however, lacks the expertise to make all product decisions, especially strategic ones. These require the relevant marketing, sales, support, legal, finance, and operations know-how—depending on the type of product and the company structure. To acquire the relevant knowledge, you have two choices. First, you can either have one-on-one conversations with your stakeholders. You might talk to the sales rep, for example, and ask them about the viability of using existing sales channels or get their feedback on a draft product roadmap. You’ll then repeat the process with the other stakeholders until you have acquired enough information or managed to create a roadmap everybody accepts. Alternatively, you can form an extended product team that includes stakeholders, as Figure 2 illustrates. Figure 2: Product Team with Stakeholders The stakeholders in Figure 2 share their expertise and contribute to product decisions in collaborative workshops, and they work with the other members to progress the product and achieve product success. For instance, you would discuss the viability of the sales channels in a product team meeting. Similarly, you would either co-create the product roadmap or discuss an initial version together with all product team members, as I explain in more detail in the article Maximising Stakeholder Buy-in to Product Strategy and Product Roadmap. Benefits and Challenges of Having Stakeholders on the Product Team Everything has its advantages and disadvantages, and that’s no different for extended product teams. Let’s start by looking at four major benefits they offer. Better Collaboration: By bringing people together, extended product teams foster strong cross-functional collaboration. They encourage a sense of we-are-in-this-together, break down cross-departmental barriers, and help remove silos. Better Alignment: Having stakeholders on the team creates a shared understanding, improves alignment, and brings clarity to what should and can be achieved. People hear each other’s ideas, requests, and concerns. They can better understand their mutual needs and empathise with each other. Better Decisions: You are likely to make better decisions as you leverage the collective wisdom of the group. This helps you come up with more creative solutions compared to talking to individual stakeholders. As an added benefit, you no longer have to act as a go-between to negotiate agreements. Better Buy-in: Having the stakeholders on the product team generates stronger buy-in to decisions. The individuals now actively contribute to them, participate in a collaborative decision-making process, and are therefore more likely to support the product strategy and product roadmap. However, adding stakeholders to the product team also has its challenges. Here are three common ones. HIPPO: Senior stakeholders might expect that they will make the key decisions. In the worst case, the HIPPO, the highest-paid person’s opinion, wins—no matter if the decision helps create the desired value for the users and the entire business. Design by Committee: Reaching agreements in a larger, more diverse team can be challenging, as the team members may have different ideas and diverging perspectives. This can result in tough decisions being avoided and weak compromises brokered. The team might use design by committee instead of working through the process of finding decisions that effectively progress the product and attract as much support as possible. Not Enough Time and Authority: The stakeholders might not have the time to attend product team meetings and carry out the necessary work. Additionally, they might lack the authority to represent their functions and make decisions on behalf of their departments/business units. Having looked into the benefits and drawbacks of extended product teams, let’s... - Published: 2024-07-08 - Modified: 2025-09-17 - URL: https://www.romanpichler.com/blog/stakeholder-buy-in-product-strategy-roadmap/ - Categories: Product Leadership, Product Vision and Strategy, Stakeholder Management - Tags: decision-making, stakeholders, teamwork The most amazing product strategy and product roadmap are ineffective if the stakeholders don’t support them. Without their buy-in, you’ll struggle to execute the strategy and find it hard to deliver the roadmap. But it doesn’t have to be this way. This article shares my tips to help you secure strong stakeholder buy-in to strategic product decisions, align people, and achieve product success together. Listen to the audio version of this article: document. createElement('audio'); https://episodes. castos. com/5e296c8fcbc2e2-83044581/1781633/c1e-44vqt4kvnos8r9zj-mk012087s05j-yolmzl. mp3 Involve the Right Stakeholders Stakeholders can form a large group, especially in bigger companies. They might include senior management, marketing, sales, service, operations, finance, and HR. Securing everyone’s buy-in would be impractical—it would most likely take too much time. You should therefore focus on the stakeholders whose input and support you really need. To achieve this, perform a stakeholder analysis using a tool like the Power-Interest Grid shown in Figure 1. Figure 1: The Power-Interest Grid The grid divides stakeholders into four groups: crowd, subjects, context setters, and players depending on how interested they are in your product and how much power they have. The individuals whose buy-in to strategy and roadmap decisions is crucial are the players: They are interested in your product, as they, for example, will have to market and sell it. They are also powerful: You need their expertise to make the right decisions and their support to successfully execute them. I refer to this group as key stakeholders. Keep the other groups in Figure 1 informed about changes in the product strategy and product roadmap, for example, by inviting subjects to bigger review/demo sessions and having one-on-ones with context setters. Secure the Right Level of Buy-in Not all strategic decisions are created equal. Some require more stakeholder support than others. Generally speaking, the bigger the impact of a decision is, the more buy-in it needs. Decisions related to a new or significantly changed strategy have a very high impact. Consequently, the key stakeholders should unanimously agree with them. Smaller strategy updates and product roadmapping decisions, however, are not as critical. Ensuring that everybody consents, and nobody disapproves is usually enough, as Table 1 shows. Decision TypeLevel of Buy-in RequiredCorresponding Decision RuleNew or significantly changed product strategyThe key stakeholders endorse the decisions. UnanimitySmaller strategy updates and new or changed product roadmapThe individuals don’t have any meaningful objections. ConsentTable 1: Decisions, Level of Buy-in, and Decision Rule When you decide by unanimity and consent, it can be hard to understand whether you have achieved the buy-in required. A great technique to uncover the current level of support is using an agreement scale like the one in Figure 2. Figure 2: An Agreement Scale The scale shows five gradients of agreement, ranging from wholehearted endorsement to serious disagreement. You can, of course, use more gradients if you wish to, but I find that in practice, the five options in Figure 2 are usually enough. With the scale in place, ask the players to express their agreement, for example, by dot-voting. Draw the scale on a whiteboard, be it a physical or virtual one, and invite people to put a dot underneath the appropriate number. The resulting picture nicely visualises the group’s level of agreement. When most people wholeheartedly endorse a new or reworked strategy and a few agree with minor reservations, you have achieved unanimity. Similarly, consent has been reached when nobody signals that they can’t support the strategy or roadmap and no one has serious disagreements. If there is no agreement, you have two options: either continue looking for a strategy or roadmap that attracts more support or change the decision rule. Say that you have already had several lengthy discussions with the stakeholders about a strategy change, but people still disagree. It might be best then if the person in charge decides, unblocks the process, and helps everyone to move forward. Co-create the Product Strategy and Roadmap The traditional way to engage the stakeholders and secure their support is to present them with a draft strategy and roadmap, collect their feedback, update the plans, and, if necessary, show them the updated version. This process can work when smaller changes are needed and the stakeholders’ perspectives are similar. But when bigger changes are required or the group is more diverse, the approach is not only time-consuming. It can be hard to reach the required level of buy-in without using design-by-committee, brokering a weak compromise, and agreeing on the smallest common denominator—which is hardly the foundation of a successful product. A better way is to co-create the product strategy and roadmap with the key stakeholders. This approach makes it easier to reach unanimity and consent without making weak compromises. Additionally, it frees you from resolving conflicting stakeholder views and ideas on your own. Instead, reaching an agreement is a collaborative effort. Stakeholders learn about their respective ideas, concerns, and interests. A great way to... - Published: 2024-06-10 - Modified: 2024-09-30 - URL: https://www.romanpichler.com/blog/how-to-get-started-with-outcome-based-product-roadmaps/ - Categories: Essential Articles, Product Roadmap - Tags: GO product roadmap, planning, product goal, stakeholders Outcome-based product roadmaps offer many benefits over traditional, feature-based ones including a strong focus on the value a product should create. But how can you introduce this new approach when an organisation is used to feature-based plans and stakeholders find it difficult to trust an outcome-based roadmap? To address this challenge, I introduce a four-step process in this article. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1759435/c1e-78qvu4v9xps502pn-04rzpmjwb64r-g2yxcb. mp3 Traditional vs Outcome-based Roadmaps Before I share the four steps, let me briefly describe the main differences between a traditional, feature- and an outcome-based product roadmap. A traditional roadmap is essentially a list of features, which are mapped onto a timeline. Such a plan might work if there is little uncertainty, change, and innovation present, and you can correctly predict what the product should look like and do. But in today’s fast-changing digital product space, that’s hardly ever the case. Using a feature-based roadmap that fixes the product functionality for the next, say, twelve months therefore risks creating a product that offers the wrong functionality and creates little value for the users and customers. Fortunately, a different roadmapping approach has emerged in recent years: outcome-based, goal-oriented product roadmaps like my GO Product Roadmap. Instead of determining features, you first and foremost consider the specific value the product should create—the outcomes it should achieve. These might include acquiring new users, reducing churn, increasing engagement, improving conversion, and reducing development time and cost by removing technical debt. To put it differently, instead of focussing on what needs to be delivered, you ask why it is worthwhile progressing the product. However, I find in my coaching work that management and business stakeholders can be very attached to feature-based plans and expect to see roadmaps that state when a feature will be delivered. In such a situation, it can be a big ask to let go of detailed, feature-based plans and trust an outcome-based, goal-oriented product roadmap. If you find yourself in a similar situation, then apply the four steps, which are shown in the infographic below and explained in the remainder of this article. (You can download the infographic by clicking on it. ) Step 1: Set an Outcome-based Goal for the Next Three Months To get started, set a single, outcome-based goal for the next three months. An example for an online shop might be “increase conversion by 5%. ” Make sure that the goal states the positive impact you want to make on the users/customers and the business. Avoid the pitfall of setting feature-based goals, such as “prioritise the search results” or “improve the search algorithm. ” Think why, not what. Additionally, ensure that the goal is specific and measurable so that you can clearly tell if it has been met. Make sure you involve the key stakeholders and development team representatives in the goal-setting process. This helps you leverage their knowledge, it creates transparency and strong alignment, and it maximises the chances that they will follow the goal. Aim to achieve consent. This means that nobody involved in the goal-setting process has any meaningful objections against the goal. A great way to engage the individuals is to invite them to a collaborative workshop, which may take place onsite or online. Ask a skilled facilitator to run the session especially when the attendees don’t know each other well and the level of trust is low. This frees you from having to facilitate and allows you to focus on setting the right goal. Step 2: Use the Outcome to Determine the Features With a specific, measurable, and outcome-based goal in place, determine the features that have to be delivered to meet the goal. A practical way to achieve this is to focus the product backlog on the outcome. Start by removing any backlog items, which are not required to create the desired outcome. Delete or archive them. Then determine how the product has to change to meet the goal. Does the user experience have to be adapted? Do you have to add or change any functionality? Do you have to meet new or enhanced non-functional requirements including compliance standards? Are bug fixes and architecture refactoring work required to achieve the outcome? Decline any feature requests that do not help you meet the goal. Use the outcome as your decision tool and stick to it—unless it becomes invalid. Don’t make the mistake of accepting a feature to please a stakeholder or avoid a difficult conversation. Saying no is part and parcel of a product person’s job, as I discuss in more detail in the article 5 Tips for Saying No to Stakeholders. Step 3: Review the Approach At the end of the three months, review how the new approach has worked for you. What went well and what didn’t? Did you manage to meet the goal? How beneficial was using the... - Published: 2024-05-13 - Modified: 2024-06-10 - URL: https://www.romanpichler.com/blog/continuous-strategizing/ - Categories: Product Management Process, Product Vision and Strategy - Tags: KPIs, stakeholders As markets, products, and technologies change at an ever-faster pace, strategies that used to last for years are in danger of becoming quickly outdated if they are not being adapted. To help you with this challenge, proactively respond to change, and spot opportunities and threats early on, I discuss continuous strategizing in this article—an approach that looks at strategy as an ongoing process rather than periodical work. What's more, I offer practical advice on how you can implement the approach and ensure that your product strategy is truly adaptive. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1740293/c1e-78qvu44jr4s502pn-v0njn9w6ixk-x8zehv. mp3 Product Strategy and Change Strategy means different things to different people, so let me briefly share my definition. A product strategy describes the approach chosen to make a product successful. It achieves this by stating the product’s target users and customers, the value proposition, the business goals it should meet, and its standout features. Such a strategy facilitates effective product discovery and product delivery. To put it differently, it’s virtually impossible to determine the right features and capture the right user stories if you don’t know who the users are and why they would want to use the product. Despite its importance, product strategy is not always effectively practised. A common issue is seeing it as a fixed plan that simply needs to be followed once it’s been agreed. But this only works if the product and market are stable and experience little change. For digital products, this is hardly ever the case in my experience. New technologies alone introduce change and uncertainty—think of the Internet of Things, Blockchain, machine learning, and generative AI, for example. In environments that experience volatility, uncertainty, complexity, and ambiguity (VUCA), the idea that the product strategy is set in stone is fundamentally flawed. Borrowing from Dwight D. Eisenhower, we could say, “Strategy is worthless. Strategizing is everything. ” A Stream, Not Drops To avoid that the strategy becomes quickly outdated, I recommend establishing a continuous strategizing process. Rather than practising strategy in drips and drops, you should think of it as a firm part of the product team’s job, a workflow that needs to be attended to on an ongoing basis—much like continuous product discovery and product delivery. Figure 1: A Continuous Product Strategizing Process By connecting the strategy stream shown in Figure 1 to the product discovery and product delivery work, you ensure that the strategy guides the discovery and delivery activities. At the same time, insights from the development work are used to inform strategic decisions and help adapt the strategy. Let It Flow To help you successfully establish a continuous strategizing process, I’ve created the approach shown in Figure 2, which I’ll discuss below and in the following section. Figure 2: Establishing a Continuous Strategizing To establish a continuous strategizing process, you must allocate enough time so you can actually carry out the work. I find that spending one hour per day on continuous strategizing works very well for some people. Others prefer to carry out the necessary work once or twice per week. Whatever your preference is, spend at least half a day per week on product strategizing so you can spot opportunities and threats at an early stage. This way, you’ll avoid nasty surprises like a competitor leapfrogging you with a new product or killer feature, and you are more likely to notice early warning signs like declining sign-up rates, increasing churn, or a growing number of support calls. Additionally, schedule regular collaborative strategy reviews—at least once per quarter—and invite the key stakeholders and development team members to them. These reviews help you see bigger trends. By involving stakeholders and development team representatives you can leverage people’s expertise to assess and evolve the product strategy. What’s more, a collaborative approach helps you create alignment and secure buy-in. While I do recommend that you schedule the reviews well in advance, you should, of course, not wait for the next review if there are new developments that need to be urgently discussed. Instead, hold a collaborative review as soon as possible. To Adapt, or Not Adapt, That is the Question To determine if the strategy has to be adapted, I recommend using the five factors shown on the right-hand side of the diagram in Figure 2. Let’s take a look at them. Performance: What do the key performance indicators (KPIs) tell you about the value the product is creating? Does the data show positive, flat, or negative trends? What conclusions can you draw from the analysis? How can you increase the product performance? Are the indicators you are using still relevant, or should they be changed? Trends: Are there any new technology, regulatory, or social developments that will affect your product? Do they offer an opportunity to innovate, for instance, to add, enhance, or remove features? Development insights and product roadmap: Are there any significant learning from the product discovery and delivery work? Has the product roadmap changed? Do the changes indicate that the current product strategy has to be... - Published: 2024-04-15 - Modified: 2026-05-11 - URL: https://www.romanpichler.com/blog/okrs-and-product-roadmaps/ - Categories: Product Roadmap - Tags: GO product roadmap, OKRs, planning, product goal, stakeholders OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs on product roadmaps? What benefits does this approach offer and are there any drawbacks? These are the questions I’ll answer in this article. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1720268/c1e-vvn3u98xdmtd63jx-row495pws4o2-ogkz9o. mp3 What are OKRs? OKRs are a method for setting and tracking goals. The acronym stands for objectives and key results. The objective is the goal, which describes what you want to achieve. The key results state the specific criteria that have to be fulfilled to meet the objective. To make this more concrete, let’s look at an example: Objective: Grow the product management team. Key result 1: Three product managers are hired. Key result 2: The onboarding system is improved, and time-to-proficiency is reduced by 25%. Key result 3: The product management processes are adapted to preserve the productivity level of the team. As the example shows, OKRs are often written so that the objective is qualitative, and the key results are quantitative. Additionally, a small number of key results is commonly employed. Please note that I don’t claim to be an OKR expert. But I experienced OKRs first-hand at Intel—where they were originally invented—when I worked for the company in the late 1990s. What makes working with outcome-based goals like OKRs powerful—and for some organisations challenging—is that they state what needs to be achieved but not how. Rather than handing a list of tasks to people, objectives are agreed. The individuals then determine how they can be met. This helps empower teams and prevent micromanagement. What are Product Roadmaps? A product roadmap is an actionable plan that describes how a product is likely to evolve. Traditionally, it is a list of features that is mapped onto a timeline. Fortunately, in the last ten years, outcome-based, goal-oriented roadmaps have become more popular. Below is an example of how such a product roadmap might be captured and the elements it might contain. Figure 1: The GO Product Roadmap Figure 1 shows a specific goal-oriented roadmap template I developed, the GO Product Roadmap. You can download the template by clicking on the image above. Let’s take a quick look at the roadmap’s five elements. The most important one is the goal, and it’s positioned in the middle of the template on the third row. It describes the specific benefit or outcome the product should achieve. Sample goals are acquiring customers, increasing engagement, and future-proofing the product by removing technical debt. The other four elements offer additional information: The one on the first row captures the date or the time frame when a goal should be met, for example, in the third quarter of 2024. The second row gives you the option to state a name. This is useful when meeting the product goal results in a new major release or product version, for instance, iOS 17. 4 and Android 14. 0. The fourth row lists the product’s features. These are the outputs that are required to meet the goal. The fifth and final row captures the metrics to determine if a product goal has been met. You can learn more about the GO product roadmap by watching the video below. https://youtu. be/NBNsnKPbah0 Can You Combine OKRs and Roadmaps? OKRs and outcome-based product roadmaps both assume that setting specific goals helps people do a great job. This similarity allows you to combine the two approaches. To do so, you have two choices. You can either work with an outcome-based roadmap like the one in Figure 1 and view the goal as the objective and the other roadmap elements as the key results. Alternatively, you can create an OKR-based roadmap. Figure 2 shows what such a plan might look like. Figure 2: An OKR-based Product Roadmap The structure in Figure 2 offers the same information as the one in Figure 1 except for the name element. This becomes clearer when we use both templates side by side. Figure 3: Sample GO and GO-OKR Roadmap with a Single Goal Figure 3 contains an extract of a GO Product Roadmap for a new healthy-eating product. The initial offering—the MVP—should help the users understand their eating habits and acquire an initial user base. It should be available in the third quarter of 2024 and offer two key features. The MVP is regarded as a success if the product is one of the top 15 diabetes apps six weeks after its launch. The OKR-based roadmap shows virtually the same information. It first states the goal, followed by the target time frame, the key features, and the success measurement. As this example illustrates, you can happily combine OKRs and outcome-based product roadmaps, as long as the roadmap... - Published: 2024-03-12 - Modified: 2026-05-11 - URL: https://www.romanpichler.com/blog/the-strategy-stack/ - Categories: Essential Articles, Product Vision and Strategy - Tags: ai, business strategy, empowerment, strategy stack For any business to succeed, it is crucial to make the right strategic choices. To achieve this, you’ll benefit from using four different types of strategies: business, portfolio, product, and technology strategy. But that’s not enough. You’ll also have to successfully align the plans. To help you address these challenges, I have developed a new framework, the Strategy Stack, which I introduce in this article. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1685210/c1e-o07nbvw8qghd5mkg-7n5ddgq8b9m-c0txjp. mp3 Introduction My first product management job wasn’t exactly what you call a success story: I was part of a team that was called in to help with a new product development effort, and I ended up working with the lead product manager. While I learnt a lot in the process, the resulting product sadly failed. But this taught me an important lesson: There is no point in worrying about the product details if a sound product strategy is missing. Without the strategy, it’s virtually impossible to determine the right features and user experience: If we don’t understand who the users are and which problem the product should solve, how can we then identify the right functionality and capture the right user stories? As helpful as a product strategy is, it’s not enough. Most companies offer more than a single product. Instead, they provide a product portfolio, think of Microsoft Office/365 as an example. To maximise the value a portfolio creates and to align the strategies of its member products—for instance, Word, PowerPoint, and Excel—it is necessary to use a product portfolio strategy. If you stopped here, however, your strategic decisions would still be incomplete. To ensure that the portfolio and its products help the entire company move in the right direction, you need a business strategy that clearly articulates how the company wants to achieve its overall aspiration and create value for its users, employees, and shareholders. But that’s still not enough. To ensure that the right technologies are applied, you’ll benefit from using a technology strategy. Let’s take Microsoft as an example again. The company took the strategic decision to heavily invest in artificial intelligence and now uses AI to help Office users be more productive. While I hope that this makes sense to you, I find that in practice, the different strategies are sometimes confused. I have seen companies use a mixture of portfolio and product strategies instead of separate plans. Sometimes, this hybrid strategy even contains business strategy elements. This does not only lead to confusion and misunderstandings. It also makes it hard to manage and adapt the plan. To clearly distinguish, capture, and align the different strategies, you’ll benefit from using a framework. This is where my Strategy Stack comes in. Understanding the Strategy Stack The Strategy Stack is an end-to-end framework that offers three key benefits. First, it helps you understand which strategies a business needs. Second, it offers a strategy architecture: It puts the plans into context and shows how they can be aligned. Last but not least, the Strategy Stack helps you clarify who is responsible for the different strategies and assign clear ownership. Let’s take a closer look at the framework, which is shown in Figure 1. Click on the picture to download the stack. Figure 1: The Strategy Stack The Strategy Stack consists of five layers and seven elements. These are the business strategy, which is also referred to as corporate strategy, the product portfolio strategy, the technology strategy, and the product strategy, as well as the product roadmap, the technology roadmap, and the product backlog. The backlog is not a strategic plan, but I’ve added it to the stack to show how strategic decisions are translated into tactical ones. There are two aspects of the framework in Figure 1 I’d like to draw your attention to. First, I’ve ordered the elements according to their importance with the most important at the top. As a consequence, the business strategy guides the portfolio strategy, which directs the product strategy. The latter, in turn, drives the product roadmap, which directs the product backlog. This way, the decisions captured in the backlog are ultimately aligned with the business strategy. Similarly, the technology strategy is directed by the business strategy. As it occupies the same levels as the portfolio and product strategy, it influences them and, at the same time, is affected by them. Finally, the technology strategy guides the technology roadmap, which, in turn, impacts the product roadmap and conversely is impacted by the plan. Second, the framework in Figure 1 does not prescribe which methods and tools you should use to capture your decisions and create the artefacts it contains. Apply the ones that work best for you as long as you can effectively answer the question associated with each element. To capture the business strategy, I find Roger Martin’s approach useful, which I summarise in the article Why Product People... - Published: 2024-02-19 - Modified: 2024-06-13 - URL: https://www.romanpichler.com/blog/empowerment-levels-in-product-management/ - Categories: Essential Articles, Product Leadership, Product Roles - Tags: decision-making, empowerment, head of product, product manager, product owner, trust Being empowered can make all the difference in doing a great job. Sadly, not all product people have the authority they need. This observation is hardly new, though, and just wishing for more empowerment isn't enough. In this article, I explain what empowerment in product management really means. I help you determine how empowered you are, and I share specific tips to increase your empowerment. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1664966/c1e-z15nsmwj1vh18nm5-92kmn8p0umww-syoh5i. mp3 Introduction To discuss empowerment in product management, I find it helpful to distinguish three main levels of decision-making authority, product delivery, product discovery, and product strategy, as the model in Figure 1 shows. Figure 1: An Empowerment Model for Product People and Teams Level one represents the authority to decide how features are detailed and guide their implementation. Level two increases empowerment by adding the authority to determine the features and user experience the product should offer. Level three, finally, allows product people and teams to develop the product strategy including the value proposition and business goals. Before I discuss the three levels in more detail, let me briefly explain why I wrote this article. My intention is to help you better understand your current level of empowerment, decide if it is appropriate, and determine how you might strengthen your authority. If you manage a group of product people, for example, as the head of product, I hope that the article will help you determine if the group’s empowerment is sufficient. I certainly don’t intend to make anyone feel bad. At the same time, I believe that it is important to look at things the way they are. It’s the first step to bring about positive change. Level 1: Product Delivery If your job is to decide how features are implemented and if you work with one or two development teams to deliver them, then you are at level one. Here are four signs that this is the case: Stakeholders, management, or another, more strategic product role determine which features have to be provided and communicate them to you, for example, during a sprint review meeting or in the form of feature requests. The product backlog, or one of its subsets, and the release plan are the main artefacts you work with. You spend a significant amount of your time refining product backlog items, writing user stories, tracking the development progress, and talking to development team members. You are not in a position to decline feature requests. While the work you do at level one is valuable, your role is similar to a project or delivery manager. As you are not empowered to determine the product features, you are not in a position to manage the product and significantly impact the value it creates. To put it differently, level-one empowerment is not sufficient for being an effective product manager or Scrum product owner. Level 2: Product Discovery Level-two empowerment means that you determine the product features and user experience. You are usually at this level if the following five criteria apply: You carry out product discovery activities including talking to users, detailing user needs, and deriving the right product features. You use an outcome-based product roadmap and/or an opportunity solution tree, personas, user journey maps, and the product backlog to capture and validate your decisions and guide the product delivery effort. You manage the stakeholders, for example, by inviting them to roadmapping workshops and sprint review meetings or by having regular one-on-ones with them. You work towards an overarching product strategy, which states the value the product should create for the users, customers, and business. The strategy may be developed by the head of product or another senior manager. You are empowered to decline a feature request if it does not meet the agreed strategic objectives. At level two, you can actually manage the product and influence the value it creates. Consequently, this is the minimum level of empowerment product managers and Scrum product owners as well as product teams require. Level 3: Product Strategy If you are authorised to determine not only the product features but also the product strategy, you experience level-three empowerment. Here are three signs that you are at this level: You engage in strategizing work, such as market discovery and market research, competitor research and competitive analysis, business modelling and financial forecasting, strategy validation, and selecting and applying the right key performance indicators (KPIs). You employ the following artefacts: product vision and product strategy, business model and business case (if applicable), and KPIs. You follow a business strategy and, if appropriate, a product portfolio strategy, which guide and constrain your decisions. If you're at this level, you have full-stack empowerment: You are authorised to make strategic decisions in addition to solution-focused ones. I generally recommend that product people and product teams have level-three empowerment. This allows them to innovate fast and maximise value... - Published: 2024-01-22 - Modified: 2025-07-10 - URL: https://www.romanpichler.com/blog/product-portfolio-strategy/ - Categories: Product Management Process, Product Vision and Strategy - Tags: head of product, portfolio management, portfolio team, product team, stakeholders Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think of Word, Excel, and PowerPoint, which belong to Microsoft Office. Such a portfolio benefits from having a dedicated strategy—a product portfolio strategy. But what information should it contain? Which template can you use to describe it? How does it relate to the overall product portfolio management work? And who should create and update the strategy? Read on to find out my answers. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1639309/c1e-m98rbzx7w6ag1o95-498m52q3t6xg-hyegmc. mp3 What Is a Product Portfolio Strategy and Why Does It Matter? A product portfolio strategy is a set of cohesive decisions that helps you maximise the value a group of products creates. You can think of it as a framework or guardrails that guide and align the strategies of the portfolio members, as Figure 1 illustrates. Figure 1: Portfolio Strategy and Product Strategies In Figure 1, the strategies of the individual products—Word, PowerPoint, and Excel—implement the Microsoft 365 strategy. Their visions, target groups, needs, standout features, and business goals must comply with the overall portfolio strategy. Product Portfolio, Product Family, and Product Line—What’s the Difference? A product portfolio is a group of products. These might be end-user-facing or internal ones like a software platform, for instance; they might directly generate revenue or support commercial offerings. Larger companies often have several portfolios; early-stage startups, in contrast, usually have a singleton one—it consists of just one offering. A product family is commonly defined as a group of related products. You can therefore view it as a cohesive product portfolio—a portfolio whose members have related value propositions and/or business goals, for example, Adobe Creative Cloud and Microsoft 365. A product line is a set of product variants. You can think of Microsoft Visio as a product line, as it is offered in three versions at the time of writing—basic, standard, and advanced. Another example is YouTube, which is available in three variants at the time of writing—standard, premium, and kids. Which Specific Information Should the Portfolio Strategy Contain? An effective product portfolio strategy should contain five elements—an overarching vision that describes the ultimate purpose of offering the portfolio; the markets and market segments the portfolio serves; the overall value it creates for the users and customers; the business benefits it helps achieve; and the type of products it contains with the capabilities that set them apart from competitors. To make this more concrete, let’s explore how the Microsoft 365 strategy might be captured. Figure 2: A Sample Product Portfolio Strategy If you are familiar with my work on product strategy, you’ll recognise the structure I’ve used in Figure 2: It is based on the Product Vision Board—the tool I’ve developed to capture a product vision and a product strategy. This means that you can apply my strategy approach not only to individual products but also to your product portfolio. To get started, create your own Portfolio Vision Board by downloading and adapting the Product Vision Board or by recreating it in your favourite tool. Please make sure, though, that you state the author and source of the Product Vision Board as well as the CreativeCommons BY-SA license on your derived portfolio board—like I did in Figure 2. If you haven’t worked with the Vision Board, then read the article The Product Vision Board and watch the video Product Vision Board Introduction. But despite the structural similarity between a portfolio and a product strategy, there is an important difference: Due to its nature, a portfolio strategy has to be bigger and less specific than a product strategy—it covers several products and not just a single one. This means that its target group, needs, standout features, and business goals are significantly less specific than those in a product strategy. How Does the Product Portfolio Strategy Direct the Product Strategies? Now that we understand what information a portfolio strategy should contain, we can take a closer look at how it guides the strategies of the products it contains using Microsoft 365 as an example. The Word, PowerPoint, and Excel visions have to either support the 365 vision or, which is my preference, they inherit it. This way, they share the same purpose—“to enable individuals and organisations to get things done. ” Additionally, the target groups of Word, PowerPoint, and Excel have to be subsets of the portfolio target group. Similarly, the needs captured in the individual strategies have to help meet the needs in the portfolio; the standout features of Word, PowerPoint, and Excel have to help realise the ones in the Microsoft 365 strategy; and their business goals have to help achieve the portfolio ones. Figure 3 illustrates this relationship. Figure 3: The Product Strategy Implements the Portfolio Strategy Following this approach ensures that the portfolio and product strategies are closely aligned. To put it differently, the portfolio strategy sets the stage for the product strategies; it guides and constrains the strategic decisions... - Published: 2023-12-04 - Modified: 2024-03-01 - URL: https://www.romanpichler.com/blog/product-strategy-and-product-discovery/ - Categories: Product Vision and Strategy - Tags: product discovery, product team, product vision board Product discovery has become increasingly popular in recent years as a way to determine the right solution. In this article, I explain why you need a product strategy to succeed with product discovery, how the strategy helps you determine the right outcomes and opportunities, and how you can use the Product Vision Board to build an Opportunity Solution Tree. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/6d0aa385-b2a2-49dd-b4ef-919191704970-Product-Strategy-and-Product-Discovery-04-12-2023-10. 38. m4a What is Product Discovery? Product discovery is the process of “figuring out a solution to a problem we’ve been asked to solve,” writes Marty Cagan. It involves understanding and selecting user needs, exploring solutions, and choosing the most appropriate one. Let’s make this more concrete by looking at a popular product discovery tool, Teresa Torres’ Opportunity Solution Tree (OTS). Before I proceed, let me point out that I am neither a product discovery expert in the sense discussed below nor do I fully endorse the specific approaches created by Marty and Teresa. My intention with this article is to show how product teams can use a product strategy to guide their discovery work and maximise the chances of creating successful products. Let’s now get back to Opportunity Solution Trees. Such a tree contains three elements: An outcome, opportunities, and solutions. The outcome describes the business need that has to be addressed. It corresponds to the problem mentioned in Marty’s quote above. The opportunities represent the customer needs that, if addressed, will achieve the desired outcome. The solutions, finally, are the products or product capabilities that help solve the customer needs. Figure 1 shows how these elements form an Opportunity Solution Tree. Figure 1: Opportunity Solution Tree Without wanting to dive into the details of Opportunity Solution Trees —I recommend reading Teresa Torre’s book Continuous Discovery Habits to learn more about them—I’ll point out three main benefits they can offer. Encourage teams to start with outcomes—business and user/customer benefits—rather than outputs—features and deliverables. This avoids the risk of implementing features that add little or no value. Connect a business goal, customer needs, and solutions: You start with an outcome, determine opportunities, break them into smaller, more specific ones, and identify solution candidates. Remind teams to consider different options and not prematurely commit to a single one. Like every tool, Opportunity Solution Trees also have drawbacks. A key issue I see is having the right business goal to start with. How is it determined? How can you be sure that it’s the right outcome to pursue, that others are not more urgent or valuable? To put it differently, if the business goal is wrong, you are likely to determine the wrong opportunities and discover the wrong features and user experience. It’s garbage in, garbage out. To make things worse, this issue is not limited to Opportunity Solution Trees. It applies to product discovery in general. Luckily, there is a solution: Using a validated product strategy that provides the input of the product discovery work. What is a Validated Product Strategy? I like to think of a product strategy as a high-level plan that helps you realise your vision and achieve product success. Such a strategy should answer the following four questions: Who is the product for? Who are the users and, if appropriate, who are the customers? Why would people want to use or pay for it? What specific problem does it address, or which tangible benefit does it offer? What are the business goals? Which benefits does the product create for the company developing and providing it? What kind of product is it and what makes it stand out? How does it differ from competing offerings? Why would people choose it over alternatives? A handy tool to capture the product strategy is my Product Vision Board shown in Figure 2. It describes the strategy by using the sections “Target Group,” “Needs,” “Product,” and “Business Goals. ” These sections correspond to the four questions above. Figure 2: Product Vision Board You can learn more about the Product Vision Board by reading the article The Product Vision Board and watching the video Introduction to the Product Vision Board. You can download the tool together with a handy checklist from my website. While it’s great to capture the strategy of a product, it’s usually not enough. To maximise the chances that following it will result in a successful product, it must be based on empirical evidence and free of major risks. In other words, it must be validated. A great way to achieve this is to start with an initial strategy and iteratively test, correct, and improve it, as Figure 3 illustrates. Figure 3: Iterative, Risk-driven Strategy Validation The process above consists of the following four steps: Identify the biggest risk currently contained in the product strategy. Sample risks might be that the target group is too small, that the need... - Published: 2023-11-06 - Modified: 2025-03-11 - URL: https://www.romanpichler.com/blog/decoding-product-leadership/ - Categories: Essential Articles, Product Leadership - Tags: alignment, empathy, empowerment, product manager, product owner, stakeholders, teamwork, trust Strong product leadership is crucial to offering successful products and enabling product-led growth. Unfortunately, there is disagreement and confusion about what exactly product leadership is and who should exercise it. Is product leadership limited to someone working as a head of product? Or can—and should—others lead in product management too? In this article, I share my advice to help you effectively practise product leadership and become great at leading others. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/3e1810d3-d505-4ffb-a3bf-2109c59fe2f2-Decoding-Product-Leadership-06-11-2023-14. 16. mp3 Leading as the Person in Charge of the Product When you hear the term leadership, you might first and foremost think of a senior manager like the head of product, Director of Product Management, VP of Product, or Chief Product Officer. In fact, some people argue that product leadership can only be exercised by a management role. But in my mind, that’s a misunderstanding of what it means to lead. Leadership is present when an individual guides a group of people to achieve a desired outcome. Leadership can therefore be exercised without being a boss. You don’t have to be a line manager to lead others. Consequently, a product manager and a Scrum product owner are leaders, too. They guide the stakeholders, development teams, and in the case of large products, other product people, to meet the agreed product goals, create the desired outcomes, and achieve product success, as Figure 1 shows. Figure 1: Exercising Emergent Leadership as the Person in Charge of the Product The best product managers and product owners I have seen were great at aligning and guiding people. The opposite is also true: I’ve seen product people who were excellent at product management, had amazing market insights and great product ideas, but underachieved, as they lacked the right leadership skills. Leading as the person in charge of the product, however, is far from being easy. As the individual is a peer and not the boss, they cannot tell people what to do and they are usually not in a position to offer rewards like a promotion. The leadership they exercise is called emergent or lateral leadership. It does not derive from a position on the org chart. Instead, it must be earned. The followers—the product team members in Figure 1—must support the person in charge of the product and be willing to follow their lead. This is achieved by gaining the trust of the individuals: exhibiting the right expertise, showing empathy, speaking and acting with integrity, and being reliable and accountable, as I explain in more detail in the article Leading without Being the Boss and the video shown below. https://youtu. be/mFsp_D92axc Despite the necessity to practise emergent leadership, the person in charge of the product must be sufficiently empowered. This means that the individual has the final say on tactical and strategic product decisions if no agreement can be reached within the product team. If that’s not the case, leading the stakeholders and dev teams can feel like a Sisyphus job—you work very hard but achieve very little. Leading as the Head of Product A head of product is someone who manages a group of product people, individuals who look after a product or a product part—like an end-user-facing feature—and who might be called product managers or product owners. A head of product is responsible for developing the individuals and growing the product management team. This usually includes hiring people, coaching and supporting them, conducting performance reviews, offering promotions, and in some cases, terminating the employment contract, as I explain in more detail in the article What Should a Head of Product Do? . To put it differently, the head of product is the boss of the people on the product management team, and the team members report to the head. The individual’s power consequently originates from their position. The leadership they exercise has been assigned or granted by the CEO or another executive. It is therefore called assigned leadership. Figure 2: Assigned Leadership and the Head of Product Role But great heads of product do not rely on the power that comes with their role. They don’t exclusively practise assigned leadership, and they certainly don’t act as “product dictators. ” Instead, they also take advantage of emergent leadership, as Figure 3 shows. Figure 3: Head of Product Exercising Assigned and Emergent Leadership There are two reasons why effective heads practise emergent leadership. First, it helps them build strong, trustful connections with the product team members and create an environment of trust and support. This increases motivation, creativity, and productivity. To put it differently, it’s hard to innovate and have the courage to make and learn from mistakes if you don't believe that your boss is supportive and understanding. Second, succeeding as the head of product does not only require the ability to lead the people on the product management team. The individual also has to be able to influence the CEO... - Published: 2023-10-10 - Modified: 2023-10-10 - URL: https://www.romanpichler.com/blog/go-product-roadmap-checklist/ - Categories: Product Roadmap - Tags: GO product roadmap, metrics, product goal The GO Product Roadmap is a simple yet effective tool to help teams create goal-oriented, outcome-based roadmaps. Despite its simplicity, I find that it’s not always correctly applied. To address this challenge, I’ve created a checklist, which I share in this article and which you can download for free. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/d348cc84-e102-4805-a14b-d1f87e296907-GO-Product-Roadmap-Checklist-10-10-2023-08. 23. mp3 Overview The GO Product Roadmap consists of five elements, as the image below shows: Date, name, goal, features, and metrics. The most important element is the goal: It describes the outcome you want to achieve or the benefit you want to provide. Sample goals include “acquiring new users,” “increasing conversion,” and “reducing cost. ” The checklist I’ve created offers criteria for each element as well as the entire roadmap. You can download the checklist together with the GO Product Roadmap by clicking on the image below. Applying the criteria will significantly increase your chances of creating a realistic, actionable product roadmap that clearly describes the value your product should create and that aligns stakeholders and development team members. Before You Start If you are new to the GO Product Roadmap, then I recommend reading the article The GO Product Roadmap and watching my YouTube video below before you apply the template and use the checklist. https://youtu. be/NBNsnKPbah0 Goal Outcome-based: Clearly state why it is worthwhile to progress the product. Describe the specific value it should create, for example, “increase engagement,” “generate revenue,” or “reduce development time by removing technical debt. ” Specific: Make the goal—a. k. a. product goal—so detailed that you can tell what needs to be roughly done to achieve it and how long it is likely to take. Measurable: Describe the goal so that you can determine if it has been met. To achieve, this you might state a target, for instance, “increase engagement by 5%. ” Prioritised: Place the goal in the right position on the roadmap considering, for example, its semantic dependencies to the other goals or its cost of delay. Single: Choose a single goal to effectively align and guide people. Avoid using multiple goals that are worked on concurrently. Date Appropriately detailed: For an internal roadmap, state a target date or a specific time frame to communicate when the goal will be met. For instance, “1st February” or “Q1. ” For an external, public roadmap, use large, coarse-grained time frames, for example, “first half of 2024” or just “2024. ” Alternatively, don’t show any temporal information and remove the row. Realistic: Ensure that the date or time frame stated is achievable—without sacrificing sustainable pace and overworking people. Metrics Precise: Clearly state how you will be able to tell if the goal has been met. Say you want to increase engagement by 5%. How can you then determine that this goal has been achieved? Will you, for example, measure daily active users? And if that’s the case, will the figure include unique new users and returning ones? Time-bound: Say when you will be able to find out if the goal has been met, for instance, “one week after the software is released. ” Features Goal-directed: Each feature must be required to meet a product goal on the roadmap. Coarse-grained: The features describe big product capabilities, which act as placeholders for specific functionality. Do not state any product details such as user stories. (These are captured in the product backlog). Focused: Only sketch those features that are crucial to meeting the goal. Limit their number to three to five per outcome. Name Relevant: Choose a name, which communicates the essence of the work carried out. This is helpful especially when meeting the goal results in a new product version or major release. Memorable: The name is easy to remember. Overall Criteria Connected: Ensure that the product goals on the roadmap are connected to the product strategy and the product backlog. They should help you meet the needs and business goals in the strategy, and they should direct the product backlog content: The backlog items should help you meet the respective product goal. Adaptive: The roadmap is regularly inspected and adapted, at least once every three months as a rule of thumb. Shared: Everyone who uses the roadmap has a shared understanding of it and supports the plan. A great way to achieve this is to collaboratively create and update the roadmap. Actionable: The roadmap can be actioned, and it does not contain any speculative information. You can achieve this by basing the plan on a validated product strategy, not being overambitious, and only planning as far ahead as you can realistically see. - Published: 2023-09-11 - Modified: 2025-12-08 - URL: https://www.romanpichler.com/blog/building-high-performing-product-teams/ - Categories: Essential Articles, Product Leadership, Product Roles - Tags: decision-making, empowerment, product team, self-organisation, sprint goal, stakeholders, teamwork "Great things in business are never done by one person. They're done by a team," Steve Jobs once said. This insight also applies to product management: As product people, we can't achieve product success on our own . We rely on the support of others, including stakeholders and development teams. This article shares my advice on fostering collaboration and forming effective product teams to maximise the chances of offering a great product. Listen to the audio version of this article: document. createElement('audio'); https://episodes. castos. com/5e296c8fcbc2e2-83044581/cf9c770b-c725-431e-9843-2c8498796812-Building-High-Performing-Product-Teams-11-09-2023-14. 11. mp3 Organise the Team around a Product As the name suggests, a product team is focused on a product. This sounds simple enough. But in practice, organising teams around products can be challenging, especially when a company lacks a clear understanding of what a (digital) product is and if it does not embrace a product-led way of working. A first step to form effective product teams is therefore to identify the products in your organisation. But what is a product? I view it as an entity that creates tangible value for users and possibly customers as well as the business. The former is achieved by solving a problem or by providing a specific benefit. Think of Google Search, which addresses the challenge of finding information online, and Flickr, which allows people to share photos. Creating value for the business can be accomplished in three ways: First, by directly generating revenue, like Adobe Premier Pro does, for example; second, by helping promote or sell other products or services, as an online store such as Amazon. com does; and third, by increasing productivity and reducing cost—something an internal software platform achieves, for instance. Once you’ve identified and selected a specific product, you can take the next step and determine the people who are required to create or progress it and generate the desired user and business benefits. Involve the Right People For a team to succeed, it is crucial to have the right people on board. To effectively staff the product team, I recommend including the people shown in Figure 1. Figure 1: The Product Team Members Let’s look at the product team members in Figure 1 in more detail starting with the person in charge of the product. This individual leads the product team, not by being the boss but by exercising emergent leadership. They achieve this by earning the trust of the team members and by embracing the right leadership styles: being a visionary, inclusive, and affiliative leader who empathises with the team members and practises active listening, as I discuss in more detail in my article Leading without Being the Boss. Additionally, the person in charge of the product must have the necessary expertise. This includes a sound understanding of the market, the user and customer needs, and the competition as well as solid product management skills such as the ability to develop an effective product strategy and an actionable product roadmap (as I explain in more detail in the article The T-Shaped Product Professional). Finally, the individual must be empowered to decide if no agreement can be reached within the product team. If you are familiar with my work, you’ll know that I am a big fan of collaborative decision-making—finding decisions that everyone can support. However, if the product team members cannot agree, then the person in charge of the product has to have the authority to decide. This avoids that the team is trapped in endless arguments and product decisions are delayed. The key stakeholders in Figure 1 are representatives from different business units who are required to make the right decisions and effectively implement them. For a commercial product, they might include a marketer, a sales rep, and a customer support team member, as I explain in more detail in the article Getting Stakeholder Engagement Right. To do a great job, each key stakeholder requires the necessary expertise, authority, and availability to work on the product team. For example, the marketer must be able to create the right marketing strategy for the product. Additionally, the stakeholders must be willing to act as team players, no matter how senior they might be. Note that including stakeholders on the product team replaces a traditional stakeholder management approach with a much more collaborative one. Instead of sending status reports to stakeholders or having steering committee meetings, the individuals are now actively involved in progressing the product and they actively contribute to its success. The development team representatives are members of one or more cross-functional development teams. It’s important that they have the right skills to spot and evaluate design and technology opportunities and to develop a rough understanding of the likely effort required to implement product decisions. The skills typically include architecture, programming, testing, and if the product is end-user facing, UX design capabilities. If the product is too big to be managed by a single person, then the other product people who work with... - Published: 2023-08-15 - Modified: 2026-05-11 - URL: https://www.romanpichler.com/blog/10-product-strategy-mistakes-to-avoid/ - Categories: Product Vision and Strategy - Tags: alignment, business strategy, decision-making, empowerment, head of product, product vision board, stakeholders, validation The product strategy is an important product management artefact. But despite its significance, it is not always effectively used. In this article, I discuss ten common strategy mistakes I see people make so you can avoid them and successfully leverage the product strategy. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1afc614c-957c-4277-a1c6-9a0932f0d2f7-Product-Strategy-Mistakes-15-08-2023-08. 12. mp3 1 No Strategy The first and most crucial mistake is to have no product strategy at all. When that’s the case, a product is usually progressed based on the features requested by the users and stakeholders. As there is no strategy, objectively assessing the impact of the requests is virtually impossible. Consequently, whoever shouts the loudest or has the biggest clout gets their features implemented. This can result in a Frankenstein product, a product that has a horrible value proposition and offers an awful user experience instead of creating real value for the users and the business. 2 Wrong Level Another mistake I see people make is to focus their product strategy on the portfolio or feature level rather than the product. The strategy is therefore either too big or too narrow. While it can be beneficial to use a strategy that maximises the value a product portfolio creates, I generally recommend keeping it distinct from the individual product strategies and using separate artefacts to capture the plans. Take a productivity tools suite like Microsoft Office or Google Workspace. If I was in charge of such a portfolio, I would use an overall strategy for the entire suite and separate product strategies for the individual tools like Microsoft PowerPoint and Google Slides. Using, however, a strategy that focuses on one or more features is not something I would advise. Take PowerPoint and Slides to stay with the previous examples. Having a strategy that covers, say, the ability to persist and retrieve slides is usually neither necessary nor helpful. Instead, it creates additional overhead, as the feature strategies have to be updated and aligned. If you find yourself struggling to come up with an effective strategy for an entire product, then this may be an indication that the product has grown too big and has become too heterogeneous. Instead of introducing feature-based strategies, consider unbundling one or more capabilities and creating product variants. This will result in more focused products with clearer value propositions, as I discuss in more detail in my book Strategize. 3 Incomplete An effective product strategy describes the approach chosen to achieve product success—to offer a product that solves a problem or creates a tangible benefit for the users and that generates value for the business. But not all strategies I have seen contained the right information. To avoid this mistake and ensure that your product strategy is complete, answer the following four questions: Who are the (target) users and customers of the product? What is its value proposition? Why will people want to use it or pay for it? What are the benefits the product should generate for the company developing and providing it? What are its standout features—the capabilities that set it apart from alternatives and entice people to choose it over competitor offerings? A handy tool to capture your answers and describe the product strategy is my Product Vision Board shown in the picture below. You can download the template by clicking on the image and you can find more advice on how to use it in the article The Product Vision Board. 4 Unspecific It’s not uncommon for me to see product strategies that are too vague and coarse-grained. For example, the target group might be too big and diverse; there might be too many needs stated and they are too unspecific; the business goals might be unclear; or the standout features might be weak. Such a strategy does not provide sufficient guidance and direction. It consequently fails to align the stakeholders and development teams. While it’s perfectly fine to start with an initial, sketchy strategy, you should spend the necessary time to sufficiently refine and detail it. If you struggle with this, then you might either lack the necessary knowledge or how might shy away from making tough decisions. In the first case, carry out just enough research work so you can clearly state the target users and customers, the specific problem the product should solve, the business impact it should achieve, and the three to five features that will give it an advantage over competitor offerings. In the second case, bring to mind that making strategic decisions requires focus. It involves discarding ideas and declining requests. As Steve Jobs once said, “Innovation is saying no to 1000 things. ” 5 Not Evidence-based It’s a mistake to base a product strategy on intuition and past experience, the views of... - Published: 2023-07-04 - Modified: 2026-06-23 - URL: https://www.romanpichler.com/blog/double-vision-how-to-capture-the-product-vision/ - Categories: Product Vision and Strategy - Tags: alignment, ethics, innovation, product vision board The product vision plays a crucial part in achieving product success: It sets a shared direction and helps create strong alignment. Despite its importance, there are two competing views of what a product vision is and how it should be captured. In this article, I discuss the different approaches and explain which one I recommend. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/7ff6fda5-54cd-494e-8328-e02731441226-Double-Vision-04-07-2023-08. 22. mp3 Option 1: The Vision Captures Strategic Decisions Your first option is to view the product vision as a statement that captures strategic decisions like the product’s users and customers, its value proposition, and its standout features. A popular template to capture such a vision is the formula developed by Geoffrey Moore in his book Crossing the Chasm: For (target customers ... ) Who are dissatisfied with (the current market alternative) Our product is a (new product category) That provides (key problem-solving capability). Unlike (the product alternative), We have assembled (key whole product feature for your specific application). Let’s apply this template to a sample product that helps people reduce the risk of developing type-two diabetes. The resulting statement might look like this: For middle-aged men with busy jobs and unhealthy eating habits who own a smartwatch and a smart scale Who are dissatisfied with the limitations of current healthy-eating products Our product is an AI-powered digital eating coach That provides personalised advice to improve eating habits and significantly reduce the risk of developing type-two diabetes. Unlike MyFitnessPal, Fooducate, and Glucose Buddy We have assembled a smart, personalised, and fully integrated solution. While I’ve seen people use variations of Moore’s original template stated above, the resulting visions don’t focus on the product’s purpose—the main reason for offering it. Instead, they describe who the product is for and how it differs from competing offerings. This is hardly surprising, as Moore describes the template as an effective way to position the product, but not to express its vision. Option 2: The Vision Describes a Big, Aspirational Goal Your second option is to regard the vision as an aspirational goal that describes the ultimate reason for creating the product and the positive change it should bring about. For the sample product mentioned above, the vision might simply be: HEALTHY EATING The benefit of using such a vision is that it acts as a big, motivational goal—a shared purpose that guides and aligns the stakeholders and development teams and that helps them understand how their work creates a positive impact and relates to a bigger whole. If you choose this option, then your vision should fulfil the following six criteria, which I explain in more detail in my article Six Qualities of a Great Product Vision. Inspiring: The vision motivates the stakeholders and development teams to act together. Shared: The individuals support the vision. Ethical: The vision gives rise to a product that does not cause any harm to people and the planet. Concise: The vision is captured as a memorable statement or slogan. Ambitious: The vision is a big, hairy, audacious goal that might never be fully achieved. Enduring: The vision acts as the product's North Star and provides continued guidance for at least the next five years. As powerful as a big, aspirational vision is, it does not say anything about how it can be realised. Consequently, you’ll have to capture the strategy of your product. One way to do this is to use my Product Vision Board, which describes the product vision and the product strategy in one artefact, as the picture below shows. (You can download the tool for free by clicking on the image. ) In the template above, the product vision is captured in the top section and the strategy is stated in the bottom four ones. These consist of the target group—the users and customers of the product, the needs, which capture the problem the product should address or the benefit it should create, the product with its standout features, and the business goals, which describe the benefits the product should generate for the company providing it. Applying the tool to capture the vision and strategy of the sample diabetes product results in the following artefact. The product vision board above contains similar information as the sample vision statement I shared earlier based Moore’s template. Note, though, that it adds the ultimate reason for creating the product as well as a business goal. Additionally, it structures and visualises the information instead of using one long sentence. Which Option Is Best? When I first started working in product management, I used a combined vision and strategy similar to the one described in the first option. But over time, I have come to prefer the second option, as it offers the following three benefits: First, the ultimate purpose for offering the product is explicitly stated. As pointed... - Published: 2023-06-06 - Modified: 2024-12-06 - URL: https://www.romanpichler.com/blog/offering-constructive-feedback-a-framework-for-product-people/ - Categories: Product Leadership - Tags: conflict, emotion, stakeholders, teamwork To create value, product people, stakeholders, and development teams have to work together. But when people collaborate, things don’t always go smoothly, and problems emerge. As the person in charge of the product, you should address these issues and offer constructive feedback. That’s often easier said than done, though. Asking people to change their behaviour can be difficult, especially when you are not their boss. To help you with this challenge, I have developed a new framework, which I describe in this article. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/e5dc7298-a7d6-473a-90c8-292428c96184-How-to-Offer-Constructive-Feedback-06-06-2023-08. 21. mp3 "No Matter How it Looks at First, it’s Always a People Problem" This quote from Gerald Weinberg nicely summarises a core challenge we face as product people: Our profession is called product management, but the product part can be the easy one compared to the people challenges we sometimes face. Here are four examples: Joe, the sales rep, has promised a feature to an important customer without first talking to you—the person in charge of the product. Sue, the Scrum Master, wanted to help the development team get better at sprint planning. But the team still over-commits and under-delivers. Pete, the marketer, agreed to rework the marketing strategy to support the next major release. To your surprise, you discover that he has hardly made any progress even though the release is only a few weeks away. Cindy who helps you manage the product started to come late to meetings. Recently she even missed one without telling you in advance. It can be tempting to ignore people issues and focus on product-related tasks like reviewing the product strategy, updating the product roadmap, and refining the product backlog. But this is hardly a recipe for success. Problems like the ones mentioned above will hardly go away on their own. Instead, they may even get worse. Consequently, you’ll have to deal with more unsolicited feature requests, poor development team performance, an ineffective marketing strategy, and meetings that are poorly attended—to stay with the examples from above. It is therefore important that you exercise leadership and address the people issues you are encountering even if this can be challenging and require courage at times. On the positive side, when done correctly, it will not only remove the problems. It will help the individuals involved grow and strengthen your connections with them. Framework Overview To help you successfully tackle people issues, structure difficult conversations, and offer constructive feedback, I have developed the framework shown in the picture below. You can download the infographic by clicking on it. While my framework integrates elements from the CEDAR model, the Situation-Behavior-Impact (SBI) model, and Non-Violent Communication (NVC), I've specifically designed it for a product management context where you lead others without necessarily being their boss. The following sections explain how you can apply the framework. Before You Start Before you share your feedback, reflect on your intention. Ensure that you want to improve the situation and help the other person rather than acting out of frustration or the desire to retaliate. It would be wrong to label or judge the individual, for instance, thinking of Joe—the sales rep introduced earlier—as a selfish and pushy sales guy who needs to be put in his place. Instead, separate the person from the problem, and focus on the latter. Additionally, choose the right time and place for giving feedback. Allocate enough time—at least 30 minutes as a rule of thumb. If you find that the issue has triggered difficult emotions like frustration or anger in you, then wait for them to reside before offering your feedback. Finally, consider if it is feasible to meet onsite. If you meet online, make sure that the cameras are switched on and that you can clearly see each other. Step 1: Connection Prior to discussing the issue, take some time to check in with the other person. Ask them how they are and what’s going on for them. This allows you to empathise and build trust with the individual. This, in turn, will have a positive impact on the conversation, and it will make it easier to share difficult feedback. You might say, for example: Hi Joe, it’s been a while. How are you doing? Have you been travelling lately? Step 2: Objective Describe the desired outcome of the meeting and state the context in which the issue occurred. You might say: Thanks for making time to meet with me, Joe. I want to talk to you about the feature request you recently raised and the impact it’s had. I also want to discuss with you how we can improve the way we handle feature requests in the future. Step 3: Issue Next, address the issue. But rather than telling the other person what’s wrong and what you want them to do differently, ask them to share their perspective. What did they observe? What is their version of what happened? And how are they feeling about the issue? Listen attentively with the... - Published: 2023-05-03 - Modified: 2025-04-07 - URL: https://www.romanpichler.com/blog/leveraging-new-technologies-tips-for-product-people/ - Categories: Product Management Process, Product Vision and Strategy - Tags: ai, innovation, learning, product discovery, technology Change seems to be the only constant when it comes to software technology. Over the last ten years, microservices, cloud-based computing, augmented reality, blockchain, the Internet of Things, machine learning, and artificial intelligence have emerged—to name just a few new technologies. But as product people, we are often so busy with getting new and enhanced features delivered that we risk overlooking new tech trends and being overtaken by competitors. In this article, I share three tips that help you spot new and potentially disruptive technologies early on so you can take full advantage of those that will benefit your product. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/a48664c0-6db1-443d-8fcd-33b28764c52b-Leveraging-New-Technologies-03-05-2023-08. 46. mp3 Make Time to Keep up with Technology Trends As new technologies come and go, it’s important for you—the person in charge of the product—to stay on top of the developments. You should be aware of new trends, be able to make an informed guess if they are likely to impact your market and product, and decide if a technology needs to be further investigated. This usually doesn’t require in-depth technical skills like being able to write code or understand how a specific machine learning framework is used. But you should take an interest in software technology, and you should have a basic understanding of how your product is currently built. To make this more concrete, let me give you a specific recommendation: Spend 30 minutes per week on discovering new software trends and learning more about those that might affect your product. You can do this, for example, by reading technology newsletters, listening to tech podcasts, and talking to development team members, especially those who have a sound understanding of software architecture and technology. Encourage Regular Technology Research and Experimentation It’s not uncommon for me to see development teams who work flat out to enhance features and offer new ones. But if that’s all they do, if there is no time to explore new technologies, then you take a big risk: The development team members may not have the skills to take advantage of an emerging technology. Say that a competitor product just started offering personalised recommendations, and you'd like to be able to do the same. You talk to the development team, and the team members suggest that machine learning is likely to be the right solution. But if nobody has had time to learn about the technology in general and research specific machine learning frameworks, you’re probably months away from offering a similar feature. Instead of giving your product the edge, you’ve been leapfrogged by a competitor—a situation you most certainly want to avoid. It is therefore important that you give the development team members the necessary time to discover and explore new technologies, build prototypes, and understand if and how a technology is likely to benefit your product or possibly threaten it. As a rule of thumb, development teams should be able to spend at least one day per month on technology research and experimentation. The following four measures will help you with this. Gold cards: Development teams set aside time in a sprint for technology research and prototyping by adding dedicated, so called “golden” cards to the sprint backlog. Research sprints: You focus an entire sprint on technology exploration. You might vary the sprint length and possibly use a shorter, say, one-week iteration. This can be helpful to tackle a more complex challenge like researching and testing different machine learning frameworks. Hackathons, also referred to as hack days: People come together for one or more days to collaboratively explore new ideas and create prototypes. Facebook’s Like button was conceived in this way, for example. 20 percent rule: Developers can take up to one day a week to experiment with new ideas and acquire new skills. The Google Chrome browser and Gmail were created this way, for instance. Use the approach that works best for your team and organisation. Be supportive and don’t expect that every experiment will be a success. Instead, be prepared to experience plenty of failures where the team learns that a technology is not useful for your product, at least not in the near future. See the exploration work as a way to future-proof your product and mitigate the risk of missing out on an opportunity. This will not only benefit your product. It will also have a positive impact on team morale and productivity. Adapt the Product Strategy to Respond to New Technologies Finally, you should systematically assess the impact of a new technology on the product strategy and determine if it has to be changed. A new technology might help you capture more market share, for example, and it might extend the life cycle of your product. Think about how smartphones have evolved over the years to stay desirable, for instance, by introducing AI-enabled virtual assistants and face recognition. I recommend that you assess the strategic impact of a technology in the form of regular, collaborative product strategy reviews. Hold these workshops at least once every three months and invite development team members and key stakeholders to them.... - Published: 2023-04-04 - Modified: 2026-04-28 - URL: https://www.romanpichler.com/blog/head-of-product-and-product-strategy/ - Categories: Product Leadership, Product Roles, Product Vision and Strategy - Tags: decision-making, empowerment, head of product The head of product role and the product strategy are often linked. But should a head of product make strategic decisions for individual products? Or would it be better to empower the product people to own the product strategy? Read on to find out my advice. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/7318285d-164a-4caf-966d-c872806ac6fe-Should-a-Head-of-Product-Make-Strategic-Product-Decisions-04-04-2023-08. 21. mp3 The Head of Product Role in a Nutshell A head of product manages a group of product people—individuals who look after one or more products and who may be called product managers or product owners. Depending on the company size and org structure, the role might also be referred to as Director of Product Management, VP Product, and Chief Product Officer. Working as a head of product includes the following three duties, as I discuss in more detail in the article What Should a Head of Product Do? First, develop the individual product people. For example, ensure that the individual’s role and responsibilities are clear; help the person grow as a product professional, be it by coaching and mentoring them or by encouraging them to attend training courses; offer clear and helpful feedback and hold them accountable for meeting agreed goals. Second, develop the product management team. For instance, help the members collaborate, establish shared standards including product management processes, methods, tools, and templates; communicate strategic business objectives; and hire new product people. Third, develop the organisation. For example, ensure that the individual product people are sufficiently empowered to succeed in their roles and establish a product-led way of working. What Happens When the Head of Product Determines the Product Strategy? As you might have noticed, the list above does not mention determining the product strategy. Here is why: When a head of product determines the product strategy on a regular basis, then this is likely to cause the following two issues. First, the product people don’t have full ownership of their products. Instead, they are focused on the tactics/delivery. In the worst case, they are product backlog managers and user story scribes. This can lead not only to low motivation and high turnover. It can also give rise to what I call a strategy-execution chasm: Strategic decisions are not effectively translated into tactical ones, and insights from the delivery work are not used to evolve the strategy. Second, the head of product turns into a bottleneck and/or becomes overworked. As the products grow and as new people are added to the product management group, the workload of the individual rises. But there is only so much work someone can cope with, and being overworked for an extended period of time leads to low productivity, mistakes, and health issues. There is, however, a situation when it makes sense for the head of product to determine the product strategy: when the individual is a contributor who manages a product in addition to leading the product management team. This can be an effective short-term fix, for example, to compensate for the lack of experienced product people on the team. But as a permanent solution, this approach is not advisable: It is likely to cause the second of the two issues mentioned earlier. How the Head of Product Can Help Achieve Product Success If a head of product should avoid making strategic product decisions, how can the individual then ensure that a product creates as much value as possible? Here is my answer: By enabling and empowering the product people to own the strategies of their products. The following four measures will help with this: First, develop the individual product people through training, mentoring, or coaching. This includes securing the necessary training budget and selecting the right training courses, as well as creating a training-on-the-job program, attending product strategy workshops as a stakeholder, and acting as a sparring partner for strategy-related questions. Note that this assumes that the head of product has the expertise required to offer the right advice—which I regard as a prerequisite for taking on the role. Second, help create shared standards to facilitate collaboration amongst the product team members. Agree on how a product strategy is described and in which tool is it captured; how it is validated; how often it is reviewed; and to which extent stakeholders and development team members are involved in the process. You might decide, for example, to follow my approach, use the product vision board to describe the product strategy, iteratively validate an initial strategy, review the plan at least every three months, and carry out the work collaboratively by involving the key stakeholders and dev team representatives. Additionally, decide how products are managed that require more than a single product person. For instance, you might choose to have one overall product manager/owner and additional product people who look after... - Published: 2023-03-14 - Modified: 2026-05-11 - URL: https://www.romanpichler.com/blog/what-is-a-product-strategy/ - Categories: Essential Articles, Product Vision and Strategy - Tags: alignment, ethics, KPIs, product discovery, product vision board, validation The product strategy is possibly the most important product management artefact. But what exactly is it? Which information should it contain? Do you need a strategy for your product? How can you ensure that it is likely to result in a successful product, and how do you keep it up to date? These are the questions I am going to answer in this article. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/4dd3c750-7d8e-4c71-aec8-94d5b845fa21-What-exactly-is-a-Product-Strategy-14-03-2023-12. 04. mp3 What Information Should a Product Strategy Provide? I like to think of the product strategy as a consistent set of specific choices that helps you create a winning product by answering the following four questions: Who is the product for? Who are the users and, if appropriate, who are the customers? Why would people want to use and buy it? What specific problem does it address, or which tangible benefit does it offer? What kind of product is it and what makes it stand out? How does it differ from competing offerings? Why would people choose it over alternatives? What are the business goals? What benefits does the product create for the company developing and providing it? To make these recommendations more concrete, let’s look at an example. Say that I want to develop a product that helps people eat more healthily. To create a strategy, I might choose middle aged men with busy jobs and an unhealthy lifestyle as the target users. The benefit the product should create for this user group might be to reduce the risk of developing type-2 diabetes. The product might be a mobile app, and its standout features might include measure and record sugar levels in food, analyse eating habits and make individualised recommendations, and seamlessly integrate with leading smart scales. The business benefits, finally, might be to create a new revenue stream, diversify the business, or develop the company brand. To capture the product strategy, you can use my product vision board. It’s a tool I have developed specifically to help people describe the vision and strategy of their products. You can download the product vision board from my website and by clicking on the image below. If you want to learn more about the tool, then read my article The Product Vision Board or watch my video Introduction to the Product Vision Board. How Does the Strategy Relate to the Vision and Roadmap? Another approach to define the product strategy is to explore how it relates to other product plans. To do this, let’s take a look at my product strategy framework shown below. As the image above shows, the product strategy sits between the vision and the product roadmap in my model. To put it differently, it states how you intend to realise the vision and thereby make the product successful, and it provides the necessary input to create an actionable product roadmap. The roadmap, in turn, provides the context to discover the right product details and capture them in the product backlog. You can learn more about the framework by reading the article The Product Strategy Framework. Do You Need a Strategy for Your Product? Now, you might be wondering if you need a product strategy at all. Without a product strategy, you will struggle to explain how your product creates value; you will find it difficult to come up with a realistic product roadmap; and you will have a hard time determining the product details. How can you capture the right user stories, for example, if you don’t know for sure who the users are and why they would want to use your product? Finally, it will be hard to select the right key performance indicators (KPIs) and measure how much value your product creates—the product strategy forms the basis for choosing the correct KPIs. I therefore recommend that every product has a strategy. If that’s not the case for your offering, then you should create one, for example by using the product vision board template shown above. How Can You Create a Strategy that likely to Result in a Successful Product? It’s great to have an initial product strategy. But to increase the chances that it will result in a successful product—a product that is desirable, feasible, viable, and ethical product—you should test your plan. A great way to achieve this is to start with an initial strategy and to iteratively validate and change it, as the picture below illustrates. The process above—which is loosely based on Eric Ries’ work—consists of the following four steps: First, identify the biggest risk currently contained in the product strategy. That’s the uncertainty that must be addressed now to make the right strategic decisions. A sample risk might be that the target group is not big enough or that the need identified may not be compelling enough. Second, determine the right method to address the risk such as direct... - Published: 2023-02-14 - Modified: 2025-07-08 - URL: https://www.romanpichler.com/blog/succeeding-with-product-delivery-and-scrum/ - Categories: Product Management Process - Tags: empowerment, KPIs, product delivery, product discovery, scrum, Scrum Master, stakeholders, sustainable pace Scrum is not a product management framework. But it can be tremendously valuable for product people: It can help you make the right product decisions and deliver great products if it’s correctly applied. In this article, I share ten tips to help you maximise value delivery with Scrum. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/85ba3f03-0b5a-4803-9da6-fdc3a0bed894-Succeeding-with-Product-Delivery-and-Scrum-13-02-2023-16. 30. mp3 1 Complement Scrum with a Strategy Process Scrum is a simple framework that helps teams develop successful products. It achieves this by using sprints to create product increments, collecting feedback from users and stakeholders, and adapting the product with the insights gained. As simple as this sounds, there is a catch: To create value with Scrum, you must understand who the users and customers are, why people would want to use and pay for the product, which business benefits it should generate, and, in the case of commercial products, which features differentiate it from competing offerings. Otherwise, you might ask the wrong people for feedback on the increments and hence draw the wrong conclusions. What’s more, you’ll struggle to determine the right product backlog items. How can you capture the right user stories, for instance, if you are unsure who the users are and why they want to use the product? You should therefore do just enough product work before you start using Scrum and before you add any items to the product backlog. But don’t stop there. Continue the strategy work while the product is being developed. This includes interviewing and observing users, using key performance indicators (KPIs) to track the value of the current product version, keeping an eye on the competition, and monitoring market trends. If this sounds complicated, then think about common everyday activities like riding a bicycle. Before you can set off, you first have to consider where you want to go and how you will get there, much like the initial discovery and strategy work I mentioned. To move forward, you’ll have to pay attention to the execution: push the pedals, keep your balance, and change gears. But this is not enough. To get to your destination safely, you’ll have to continuously look ahead, avoid obstacles, and possibly adjust the route. Scrum is like a bicycle; it helps you move forward. But it doesn’t tell you where to go and how to get there—that’s what the strategy work does. 2 Use Scrum for Products that Experience Uncertainty and Change Scrum is often seen as the standard way to create digital products, and I have met more than one company where the product managers were told to be agile and do Scrum. But like any tool, Scrum has its benefits and limitations. I find that the framework is best suited for products that are affected by a significant amount of uncertainty and change. These are typically brand-new and young products, as well as products that are experiencing a bigger change, for example, to extend their life cycle by addressing a new market segment or by replacing some of the technologies. But if your product is in a steady state, for instance, if it is mature, and you focus on incremental enhancements and bug fixes, then you may find it more beneficial to use a Kanban-based agile process instead of Scrum. To put it differently, there is no one right way to develop products and deliver solutions—just like there is no single bicycle that is perfect for every terrain. A road bike, for instance, is great for riding on smooth surfaces. But a mountain bike is better for riding offroad. 3 Look beyond the Product Backlog and Use Additional Product Management Artefacts The product backlog can be a great tool to capture the outstanding work to deliver a product. But it’s not enough on its own. To successfully manage your product and maximise value delivery, you should use additional artefacts including the following five: An inspiring vision that describes the ultimate reason for offering the product; A validated product strategy that captures your approach to realise the vision and make the product successful. An outcome-based, goal-oriented product roadmap, which shows how you intend to implement the strategy and states the specific benefits the product should create in the next, say, twelve months; KPIs that measure the value your product creates and help you understand if the strategy is working; A business model that explains how you intend to realise the desired business benefits and in the case of a commercial product, how it is monetised. Note that none of the five artefacts is part of Scrum. But this does not mean that they cannot or should not be used in combination with the framework. As I mentioned earlier, Scrum is not a product management framework. It therefore offers only limited support for product... - Published: 2023-01-31 - Modified: 2024-01-31 - URL: https://www.romanpichler.com/blog/product-vision-board-checklist/ - Categories: Product Vision and Strategy - Tags: product vision board, stakeholders, teamwork I designed the product vision board to be a simple yet effective tool to capture the product vision and the product strategy. Despite its simplicity, it's not always easy to effectively apply it. This article introduces a checklist to help you get the most out of the tool. Overview The product vision board offers five sections. The vision captures the ultimate purpose for offering a product. The target group characterises the product's users and customers. The needs describe the problem the product should address or the benefit it should offer. The product section states its standout features. The business goals capture the desired benefits the product should achieve for the company developing and providing it. The checklist below states criteria to get the five elements of the product vision board right. Additionally, it offers criteria that apply to the entire board or its bottom sections. You can download the checklist together with the product vision board template by clicking on the image below. If you are new to the product vision board, then I recommend that you read the article The Product Vision Board or watch my YouTube video called Product Vision Board Introduction before you use the checklist. Vision Inspiring: Describes the positive change the product should create. Shared: Unites people and creates alignment. Ethical: Gives rise to a product that does not cause any harm to people and the planet. Concise: Easy to understand and remember. Ambitious: Describes a big, audacious goal that might never be fully reached. Enduring: Provides guidance for the next five to ten years and is free from assumptions about the solution. Target Group Clear: The target group is clearly characterised, for example, by using demographics and behavioural attributes. Specific: You can tell if somebody is included in the target group or not. Cohesive: The members of a target group share similar attributes, e. g. , age, lifestyle, disposable income. If that’s not the case, then break up the target group and form several subgroups. Needs Outcome-based: Capture the reason why people would want to use the product. Describe what success looks like from the perspectives of the users and customers. Specific: The needs are detailed enough so that you can validate them. Focused: Concentrate on the main problem/benefit, the main reason for people to use the product. Prioritised: If you do identify several needs, prioritise them according to their importance for the target group. Product Type: It’s clear what kind of product you want to offer, for example, mobile app on Android and iOS. Differentiated: The aspects of your product that make it stand out, set it apart from alternative offerings are stated. Focused: There are no more than five standout features. Big: The features are coarse-grained product capabilities; no epics and user stories! Business Goals Outcome-based: The desired business benefits, the company’s reason for investing in the product, are clearly described, for example, generating revenue, increasing brand equity, reducing cost. Specific: The business goals are detailed; state rough targets if possible. Prioritised: If more than one business goal is identified, order them according to their business impact. Overall Criteria Needs-first: Start with the needs after you’ve captured the vision especially when you create a new strategy—be it for a brand-new product or for an existing one. An example for the latter would be a life cycle extension, for instance, by addressing a new market. Validated: The statements in the Target Group, Needs, Product, and Business Goal sections does not contain any major hypotheses and risks. They have been successfully validated, for instance, by interviewing and observing target users, building throwaway prototypes, and carrying out competitive analysis. Adaptive: The product vision board is regularly inspected and adapted, at least once every three months as a rule of thumb. Shared: The key stakeholders and development team members have a shared understanding of the product vision board contents. Connected: The strategy captured on the board is systematically connected to more specific outcomes, preferably to an outcome-based, goal-oriented product roadmap like my GO Product Roadmap. - Published: 2022-12-06 - Modified: 2023-05-05 - URL: https://www.romanpichler.com/blog/leading-without-being-the-boss-tips-for-product-people/ - Categories: Product Leadership, Product Roles - Tags: alignment, decision-making, empathy, empowerment, stakeholders, trust As the person in charge of the product, you have a rewarding but challenging job. A key challenge is leading the stakeholders and development teams without being their boss, without being able to tell people what to do. In this article, I offer my advice on how to overcome this challenge, guide the individuals, and create value together. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/7d8b4910-33e1-4e30-a6b5-cff1ad956bd0-Leading-Without-Being-the-Boss-06-12-2022-08. 13. mp3 The Need for Guidance and the Lack of Transactional Power Product success is not something you can achieve on your own as a product manager or Scrum product owner. Instead, you rely on the contributions and the support of the key stakeholders, the development team members, and possibly other product people who help you manage a large product. For example, a marketer has to create the marketing strategy, and the development teams have to design and build the product. What’s more, all deliverables must fit together to achieve the desired outcome. For instance, the marketing strategy, the user experience (UX) design and technology choices have to align to successfully acquire new users, increase conversion, or meet another product goal. Consequently, the stakeholders, development teams, and product people require guidance and alignment—they must all move together in the same direction and work on the same overarching goals, as the picture below illustrates. On top of everything, you are usually not the boss, and the individuals in the picture above don’t report to you. You therefore lack transactional power: You cannot tell people what to do and make them follow your decisions, and you typically cannot offer a bonus, pay raise, or other incentive. To make things worse, some of the stakeholders might be more senior than you. How can you then effectively guide and align them? Influence and Trust as Leadership Building Blocks Effectively leading others requires that they trust you. To trust someone means to have faith in the person, believe that their intentions are good, feel safe in their presence, and be comfortable to speak one’s mind. Once you have earned someone’s trust, the person will be open to your suggestions and advice. This, in turn, enables you to influence the individual and help them achieve the desired product outcome. If the opposite is true, and someone doesn’t trust you, then they are unlikely to follow your lead. They will be inclined to do what they believe is right. This may result in people moving into different directions and producing deliverables that don’t create the desired value. Gaining the trust of the stakeholders, dev teams, and other product people is therefore vital so you can effectively align and guide them and achieve the desired outcomes. It's important for me to point out that effective leadership must be based on the intention to support the people you want to lead, not on the desire to control or manipulate anyone. The influence you exercise should therefore be a positive one, see my article Should Product People be Servant-Leaders? What’s more, there is not one right way to lead. For example, groups that haven’t worked together require a different leadership approach compared to those that have developed into a closely knit unit, as I discuss in more detail in the article How to Choose the Right Product Management Leadership Style. Measures to Build Trust with Stakeholders, Dev Teams, and Other Product People As trust is crucial to lead without being the boss, it’s important that you take the right steps to earn the trust of the stakeholders, the development team members, and other product people. The following nine measures will help you with this. Empathise Take a kind and warm-hearted interest in the people you want to lead, their views, feelings, and needs, as well as the goals they want to achieve. This allows you to better understand them, and it shows the individuals that you care about them, which encourages them to trust you. Attentively listening to people with an open mind and getting to know them will help you empathise, as I discuss below. You can find more guidance on empathy in my article Empathy in Product Management. Get to know people Learn about the individuals’ job role with its specific demands and challenges, their backgrounds, family situations, and interests to better understand why somebody thinks and acts in certain ways. This, in turn, increases your ability to empathise and to earn the trust of the person. There are many ways how you can get to know people and build effective relationships. These include having informal chats over a cup of coffee or at lunch as well as organising team building activities. Practise active listening Give people your full attention and listen with the intention to understand when you are in a conversation with the stakeholders, development team members, and your product management colleagues. This makes people... - Published: 2022-11-01 - Modified: 2026-05-11 - URL: https://www.romanpichler.com/blog/product-roadmapping-mistakes-to-avoid/ - Categories: Product Roadmap - Tags: GO product roadmap, product goal, release burndown, stakeholders, sustainable pace, teamwork, validation The product roadmap is a great product management tool. But it can cause significant issues when it is not used appropriately. This article discusses ten product roadmapping mistakes you should avoid to fully leverage your roadmap. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/17d49fee-52cf-4013-9b86-f9707f9c62a6-10-Product-Roadmapping-Mistakes-to-Avoid-01-11-2022-08. 14. mp3 1 The Product Roadmap is a Feature-based Plan Traditional product roadmaps are usually output-focussed plans that map a list of features, like registration, search, and reporting, onto a timeline. Such a roadmap essentially states when a piece of functionality will be delivered. This can be reassuring for customers and stakeholders. But it has the following three drawbacks: A feature-based roadmap can give rise to and strengthen a feature-factory mindset where adding features is more important than creating value and making a positive impact on people’s lives and the business. Focussing on features risks turning the roadmap into a tactical plan that overlaps with the product backlog, especially when fine-grained features are used. This makes the roadmap harder to understand, and it increases the effort to keep it up to date. A feature-based product roadmap is easily mistaken for a commitment rather than a high-level plan that is likely to change. This will not only lead to disappointed stakeholders. It will also limit your ability to experiment and learn, to run sprints and discover the best way to address the user and customer needs and create value for the business. You can avoid these drawbacks by using a different roadmap type: a goal-oriented or outcome-based product roadmap. As its name suggests, this roadmap focuses on product goals and outcomes, such as acquiring customers, increasing engagement, and future-proofing the product by removing technical debt. Selected coarse-grained features might still be used, but they are now dependent on the goals: Every feature must serve a goal and be required to create a specific outcome. A handy tool to create a goal-oriented roadmap is my GO product roadmap, which you can download for free by clicking on the image below. 2 Roadmap Goals are Features in Disguise While goal-oriented roadmaps can be very beneficial, they are not always applied effectively. A common mistake I see product people make is to use product goals that are features in disguise. Say that I am about to create a product roadmap for a healthy-eating product. Would the two statements “measure calorie intake” and “determine blood sugar level” then qualify as product goals? I don’t think so. In my mind, they describe product capabilities or features, and they characterise the solution. They do not state why it is worthwhile to progress the product. Therefore, be careful not to mix up goals and features. Ensure that your product goals always capture the desired outcome the product should create and not the output. A good test to understand if a product goal describes an outcome is to ask the why question. For example, I could ask myself why it would be helpful to measure calorie intake. The answer would then reveal the true goal, such as “help the users improve their eating habits. ” 3 Stakeholders Determine the Roadmap Content Do your stakeholders ask you to add specific features to the product roadmap? If that’s the case, you are not alone. It’s not uncommon that product roadmaps are driven by stakeholder requests and that individual stakeholders want to have “their” features included. While it is important to actively listen to the stakeholders, you should not allow them to dictate the roadmap content. Your job is not to please the stakeholders, but to achieve product success. If you say yes to every request, you are in danger of creating a Frankenstein product—a product that is a collection of unrelated features, offers a weak value proposition, and gives rise to a poor user experience. Decline stakeholder requests if they aren’t aligned with the product strategy. If they are then look for a product goal that the feature supports. If there is none, then either adjust the plan by amending an existing goal or introducing a new one, or reject the feature request. This, of course, assumes that you are adequately empowered and that you have the final say on strategic product decisions. 4 The Person in Charge of the Product Creates the Roadmap on Their Own Another common roadmapping mistake I witness is the opposite of the one just described: the person in charge of the product creates the roadmap on their own without any input from the stakeholders and development teams. This approach is problematic for the following three reasons: It does not leverage the creativity and knowledge of the stakeholders and development teams. This is likely to result in a product roadmap that is suboptimal or wrong.... - Published: 2022-10-05 - Modified: 2022-11-28 - URL: https://www.romanpichler.com/blog/5-tips-for-stocking-the-product-backlog/ - Categories: Product Backlog & User Stories - Tags: definition of ready, focus, GO product roadmap, product backlog, product goal, risk, teamwork The product backlog is a simple yet powerful tool to capture tactical product decisions and direct the work of the development team. To take full advantage of it, it’s important to set up the initial backlog in the right way. This article offers five practical tips to successfully stock the product backlog and lay the foundation for a successful development effort. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/57beb87a-fc97-4e65-a1cd-c58a28e6dc86-5-Tips-for-Stocking-the-Product-Backlog-05-10-2022-11. 23. m4a 1. Choose a Product Goal A product goal describes a specific and measurable outcome a product should create during the next two to three months. Sample goals are acquiring users, increasing conversion, generating revenue, or future-proofing the product by reducing technical debt. Product goals offer the following four benefits: They describe the specific value a product will create in the coming months; they align stakeholders and development team; they focus the product backlog thereby making it easier to manage and update it, and they provide the context for choosing the right sprint goals, as I discuss in more detail in my article Product Goals in Scrum. If you follow my product management approach and use a goal-oriented roadmap like my GO product roadmap, then you can simply choose the next goal on the plan as your product goal. If that’s not the case, then determine the outcome the product should achieve in the next few months, preferably together with the key stakeholders and development team members. Ask yourself why it is worthwhile to progress the product and spend time, money, and energy on it. What is the specific problem you want to address or the particular benefit you want to achieve in the next few months? If you have a validated product strategy in place, you can use its value proposition and business goals to find the right product goal. Alternatively, use your key performance indicators (KPIs) to identify improvement opportunities. Then choose the most important one as the product goal, as I describe in more detail in my book Strategize. 2. Clear out the Product Backlog Next add the product goal to the product backlog. Then remove all items that are not required to meet the goal. Delete or archive them. This might result in an empty product backlog that contains only the product goal. But that's OK. While this advice may sound drastic, it ensures that your product backlog is focused and concise. I have come across many huge product backlogs in my work, some of which contained several thousand items. All these backlogs had a common issue: They were not focused, and it was not clear, which specific value the backlog should help create. Focussing your product backlog on a single goal makes it comparatively easy to prioritise and update. This is especially important for products that experience a significant amount of uncertainty, risk, and change—like new and young offerings—as their backlogs tend to be volatile and frequently change, as I explain in more detail in the article How Detailed should the Product Backlog be? 3. Determine the Items Necessary to Meet the Product Goal After clearing out the product backlog, consider which product capabilities have to be created or enhanced to achieve the product goal. Say that your goal is to increase conversion by 5-10% over the next three months. Then ask yourself how you will achieve this outcome. How will the product have to change to meet the goal? If you work with my GO product roadmap, then start by copying the features that are associated with the goal into the backlog. Additionally, answer the following four questions to discover the right backlog items: Does the user experience have to be adapted? Do you have to add or change any functionality? Do you have to meet new or enhanced non-functional requirements including compliance standards? Are bug fixes and architecture refactoring work required to address the product goal? Keep the backlog items you’ve identified coarse-grained and sketchy, at least for now. For example, use epics to capture them but not detailed user stories. What’s more, the product backlog does not have to be complete at this stage, and I would argue that it should not be at this point in time. Remember that the backlog will evolve based on the feedback and data you gather by demoing and releasing early product increments to users and stakeholders. You’ll add new items, and you’ll remove or change existing ones. 4. Get the Product Backlog Ready Once you’ve captured the work required to meet the product goal, prioritise the backlog. I recommend using risk as the main prioritisation factor at this stage. This will allow you to quickly address assumptions, and rapidly acquire the relevant knowledge. Risks may be related to the users, technology, business model, and compliance requirements. Here are four sample risks: First, users might not be willing to register before using the app.... - Published: 2022-09-13 - Modified: 2026-03-11 - URL: https://www.romanpichler.com/blog/my-product-strategy-model/ - Categories: Essential Articles, Product Vision and Strategy - Tags: innovation, KPIs, product goal, stakeholders, teamwork, validation Making the right strategic decisions is crucial to achieve product success. If it’s not clear, for example, what a product’s value proposition is and what its stand-out features are, then it will be difficult to create the desired business value. But I find that many product teams do not use a systematic approach to create and evolve a product strategy. To put it differently, they lack a product strategy model. In this article, I describe the model that I have developed. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/7bb7029e-2dec-4c49-976b-73e988439ac4-My-Product-Strategy-Model-13-09-2022-07. 55. mp3 The Model An effective product strategy is key to successfully creating, enhancing, and managing a product. There is no point in worrying about the product details and writing user stories if a sound product strategy is missing. But what exactly is a product strategy? How does it differ from a product roadmap, and how do the two plans relate? And what’s their relationship to the product vision and the product backlog? To answer these questions, I have developed the model shown in Figure 1. You can download the model by clicking on the image. Figure 1: Product Strategy Model Let’s take a closer look at the model and explore its elements and connections, starting with the four artefacts it contains. Vision, Strategy, Roadmap, and Backlog At the heart of the model in Figure 1 are four artefacts: the product vision, the product strategy, the product roadmap, and the product backlog. The product vision describes the product’s purpose, the ultimate reason for creating it, and the positive change it should bring about. You can think of the vision as the product’s true north that guides and aligns everyone involved in achieving product success. This includes the stakeholders, the management sponsor, and development teams. A sample vision might be "help people eat healthily," assuming that you want to offer a product that helps people improve their eating habits and take advantage of the related benefits. The product strategy communicates the approach chosen to realise the vision and to make the product successful. Coming up with a strategy requires you to make four important choices: Selecting the needs the product should address, for example, reducing the risk of developing type-2 diabetes to stay with the health-eating example introduced above. Determining the market or market segment—the users and customers who should benefit from the product, for instance, "middle-aged men with unhealthy eating habits who are at risk of developing type-2 diabetes. " Choosing standout features that set the product apart from competing offerings. These might include "measure and record sugar levels in food," "analyse eating habits and make individualised recommendations," and "seamlessly integrate with leading smart scales. " Setting realistic business goals that describe the benefits the product will create for the company developing and providing it. These may include financial goals like a revenue target as well as acquiring new knowledge and developing the brand. Making these choices requires you to say no to ideas and suggestions. For instance, not addressing teenagers with an eating disorder, at least for now. While this can be tough, it is a necessary part of strategic decision-making. A product that tries to please everyone risks not doing a good job for anybody. What’s more, a new or significantly changed strategy must be validated to maximise the chances of achieving product success. This is best done by systematically addressing its biggest assumptions and risks in an iterative fashion, as Figure 2 shows. Figure 2: Iterative, Risk-driven Validation With a validated strategy in place, you are in a great position to build an actionable product roadmap. The roadmap in Figure 1 describes how the product strategy will be implemented in the next six to twelve months; it communicates the specific benefits the product will achieve; and it aligns and guides the stakeholders and development teams. An effective product roadmap is built on product goals, which describe the outcomes the product should create. For instance, the first benefit on a roadmap that helps create a healthy eating product might be to "help users understand their eating habits and acquire an initial user base;" the second one might be to "help users improve their eating habits and grow the user base. " Additionally, the roadmap may contain elements like dates or time frames, selected coarse-grained features, and metrics. A date or time frame states when a goal should be met, the features sketch the output required to achieve a goal, and the metrics help you understand if a goal has been accomplished. A product roadmap that is based on product goals provides a great basis for deriving a product backlog and making the right tactical product decisions. You can simply copy the next product goal into the backlog together with its features. Then add further items that are required to meet the goal, such as epics, user stories, workflow diagrams, sketches, mock-ups, and non-functional requirements (NFRs). As you move from vision to the product backlog, the decisions you... - Published: 2022-08-16 - Modified: 2023-10-09 - URL: https://www.romanpichler.com/blog/empathy-in-product-management/ - Categories: Product Leadership - Tags: empathy, ethics, mindfulness, self-leadership, stakeholders, trust I was recently asked at a product management conference what superpower product people should have. I didn’t have to think twice and replied, “empathy.” This article explains why empathy is particularly important in product management and how you can strengthen your ability to empathise even with seemingly difficult stakeholders, customers, and team members. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/e3842fef-163c-4118-8f5b-665877b0bc07-Empathy-in-Product-Management-16-08-2022-08. 30. mp3 What is Empathy and What is It Not? Empathy is our capacity to understand other people’s feelings and needs, to take the perspective of another person. Empathy entails a warm-hearted, open, and kind attitude. This does not mean, though, that you must like the other person and that you must be happy and smiley all the time—nor does it mean sugar-coating messages, only telling people what they want to hear, and putting up with issues. The opposite is true: You can empathically address unhelpful and inappropriate behaviour, as the following example shows. Imagine that John is a sales rep and a key stakeholder who hardly ever attends the product strategy workshops you've invited him to. Instead, he requests product roadmap changes by talking directly to you. You should then consider asking John to change his behaviour and attend the strategy sessions to share his change requests. But act in an empathic way: Find out first what’s going on with John and try to understand why he missed the meetings. It might be that he is overworked and short of time or that there is an ongoing conflict with one of the other stakeholders that makes it difficult for him to participate in the workshops. At the same time, be frank. Don’t beat around the bush but make a clear and specific request once you’ve found out what drives John’s behaviour. Note that it’s easy to confuse projection with empathy: The former means making assumptions about what the person should feel according to some preconceived ideas—for example, believing that someone who speaks loudly wants to dominate and take over a meeting. Empathy, however, implies developing an understanding of what is really going on for the other person. In the example just mentioned, the individual might have an odd communication habit and a general tendency to speak loudly, or the person might raise their voice because the individual is upset, not because they want to dominate. Why is Empathy Important in Product Management? While empathy is a fundamental human quality, there are three reasons that make it particularly valuable for product people. First, empathy is the foundation for effective leadership. It creates trust and psychological safety, and it allows you to influence others and encourage change. That’s key for product people who lack transactional power, who are not the boss of the stakeholders and development teams, but still have to guide and align the individuals to achieve product success. To put it differently, becoming more sensitive to other people’s feelings and needs will increase your ability to lead them. Note, though, that the empathy you show must be authentic. If you pretend to care or if you empathise only to get someone to do something, people will sooner or later realise what is going on and they are likely to lose trust in you. Second, empathising with users and customers helps you develop a deeper understanding of their needs. While we have more data and more powerful analytics tools available today than ever before, I find that reaching out to selected users and customers with respectful curiosity and genuine warm-heartedness—for example, by observing how they get a job done and talking to them about their experience—is crucial to truly understand what they want and need. This, in turn, enables you to make the right product decisions, which makes it more likely to offer a successful and ethical product. Third, showing empathy towards yourself and cultivating self-compassion helps you be a happier person. It strengthens your ability to empathise with others, and it avoids the risk of overlooking your own needs and, for instance, regularly working too hard—which is an easy mistake to make, given that most product people have a demanding job. But being overworked and stressed is counterproductive. It can lead to a drop in productivity and motivation, and it can harm your mental health. Practised correctly, self-compassion will help you balance your own needs and the needs of others so that neither are neglected. How Can You Strengthen Your Empathy? We all have the ability to empathise. But how strong it is, varies significantly. Not everyone we meet is a highly empathic person. What’s more, it is easy to empathise with someone we like and who we agree with. But if we are dealing with a “difficult” stakeholder, customer, or team members, developing an open, warm-hearted attitude can be challenging. The following four techniques will help you increase your capacity to... - Published: 2022-07-05 - Modified: 2024-01-22 - URL: https://www.romanpichler.com/blog/what-should-a-head-of-product-do/ - Categories: Essential Articles, Product Leadership, Product Roles - Tags: empathy, head of product, trust Becoming a head of product is a career aspiration for many product managers and product owners. But what exactly should a head of product do? Which are the responsibilities the individual should fulfil? Read on to find out my answer. Listen to the audio version of this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/8c0d4d19-8d6d-495b-bbdc-39e9a26e050a-What-Should-a-Head-of-Product-Do-05-07-2022-08. 29. mp3 The Head of Product Role A head of product is someone who manages a group of product people—individuals who look after one or more products and who may be called product manager or product owner. Depending on the size and org structure of your company, the role might also be referred to as Director of Product Management, VP Product, or Chief Product Officer. As the head of product, you play a key part in developing the people on your team, creating an environment that helps them succeed, and improving the effectiveness of the product management function in the enterprise. The responsibilities I share below are based on my work with product leaders and product practitioners. To make the duties more accessible, I have grouped them into four sets: people management, processes and tools, business strategy and organisational development, and self-leadership. Note that I have kept the description of the responsibilities concise. To learn more, please follow the links in the text. Be aware that there is no one right way to apply the head of product role or a golden standard for doing the job. You should therefore tailor my recommendations to your team and organisation. The best way to do this is to ask the people on the product management team how you can effectively support them. People Management Create an environment where people feel valued and able to speak their minds. Genuinely care about the individuals on your team and show appreciation for their efforts. Practice active listening, empathise with the team members, speak and act with integrity, and build strong, trustful connections. Give people a choice about the products they work on, for example, by using self-selection. This increases motivation and it shows the team members that you value them. Ensure that the product management roles are well defined and understood by all team members. Clearly state the authority, responsibilities, and necessary skills of each role. Involve the team member in describing the roles. This leverages their expertise, creates a shared understanding, and shows them that you value their input. Make sure that the product people have the authority and autonomy they need to succeed in their jobs. Individuals who manage products should have full-stack ownership and be empowered to make not only tactical product decisions but also strategic ones. Additionally, ensure that the products are loosely coupled so that they can be effectively progressed and not held back by dependencies. Set clear expectations and agree on specific, measurable, and outcome-based goals. Having well-defined roles in place will help you with this, as I’ll discuss below. Hold people accountable to meet the agreed goals. Use, for example, the CEDAR model and appreciative inquiry techniques to offer feedback in the right way and help people get back on track. Develop the individuals on the team. Help them get better at product management and grow as product professionals. You might achieve this by having regular one-on-one meetings, mentoring and coaching the individuals as well as recommending suitable training courses. Don't forget to capture the learning and development measures, for example, on a learning roadmap. Establish clear career paths to retain team members and show them how they can advance their careers. For instance, someone might start as an associate product manager, then move into a junior and subsequently into a senior product manager role, next become a portfolio manager and finally a head of product. Encourage a growth mindset and create a failure-tolerant environment where experiencing setbacks and making mistakes is seen as a necessary part of learning new skills as well as bringing new products and features to live. One way to do this is to share failure experiences from your career. Remove impediments the team members face and act as an escalation partner for problems the individual product people cannot solve. Examples are excessive red tape and the lack of qualified Scrum Masters. Help the team members practise sustainable pace so they don't sacrifice their wellbeing but stay healthy and motivated. For example, encourage people to take regular breaks from work and don't expect them to work extra hours, at least not on a regular basis. Grow the product management team. This includes creating job descriptions and interviewing candidates. A great way to develop the team is to organise around products, as I discuss in more detail in the article Tips for Growing a Product Management Team. Processes and Tools Help establish the right... - Published: 2022-06-07 - Modified: 2022-08-16 - URL: https://www.romanpichler.com/blog/avoid-these-common-kpi-mistakes/ - Categories: Product Vision and Strategy - Tags: KPIs, metrics Key performance indicators (KPIs) are metrics that measure how well your product is doing. As useful as they are to proactively manage a product, they are not always effectively applied. In this article, I discuss six common KPI mistakes. I explain how you can overcome them and leverage key performance indicators to maximise the value your product creates. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/31dc7820-0a4d-4e19-9652-35748d3c8c6a-Six-these-Common-KPI-Mistakes-07-06-2022-10. 09. mp3 1 No Product KPIs Imagine that you have trained hard to run a half-marathon. Shortly after the start of the race, your smart watch stops working, and you discover that you didn’t bring your phone. Consequently, you don’t know for sure how fast you are running and if you are on track to achieve your target finish time. The same is true when you don’t use any key performance indicators. You’ll end up guessing how well the product is doing and if it is creating the desired value. While common sense suggests that managing a product without the right measurements is not a sensible approach, I’ve seen product teams who did not use any KPIs. This can be caused by an intense focus on execution and delivery—being so concerned with adding features and running sprints that tracking the product’s overall performance is neglected. Consequently, these teams relied on: Anecdotal feedback: “Customers love our product, they told me so. "Gut feeling: "Trust me, I’ve seen this before, and I’m sure we’re on the right track. "Solution-centric data: "We’re making great progress; we’ve implemented 50 more user stories, and velocity is up by eight points! " Sadly, the data above is not helpful to see clearly how much value the product is creating. Instead, it can lead to making wrong product decisions and ultimately mismanaging the product.   2 Wrong Product KPIs When you reflect on the key performance indicators you use, how confident are you that you have chosen the right metrics and that you collect the right data? My experience suggests that it’s rather common that not all indicators used are helpful. There are four common reasons for this: The analytics tool decides: The measurements are largely determined by the analytics tool employed—you trust the tool to collect the right data for you. This often leads to too much data being gathered. You consequently spend too much time analysing the data, and you may struggle to determine the relevant data. This, in turn, can cause you to draw the wrong conclusions and make the wrong decisions. The value the product should create is not clearly understood: A validated product strategy and an actionable product roadmap are missing. You therefore end up guessing which indicators you should use rather than being able to systematically derive the right ones. A powerful stakeholder or line manager determines the KPIs—not the person in charge of the product. This usually leads to using metrics that are valuable for the individual but not necessarily for the product. In the worst case, you collect irrelevant data that unduly influences product decisions. Vanity metrics are used. These are indicators that make the product look good rather than paint a realistic picture of its performance, as I’ll discuss in more detail in one of the following sections. Using wrong or unhelpful indicators means that you will collect wrong or irrelevant data. If this data is actioned, bad product decisions will be made. Therefore, ensure that all measurements you use are truly helpful. To achieve this, refer to the needs and business goals stated in the product strategy and the product goals on the product roadmap. Then ask yourself how you can tell that these goals have been met. Additionally, include health indicators, metrics that measure how healthy your product and team are, as I explain in more detail in the article How to Choose the Right KPIs for Your Product. Don’t forget to regularly review and adjust your KPIs. Do this at least once per quarter, as a rule of thumb, ideally as part of the product strategy reviews. 3 Stakeholder or Big Boss Dictates KPIs In theory, the key performance indicators should be systematically derived along the lines just mentioned. But in practice, that’s not always the case. I have worked with product people who were told to use certain KPIs by a powerful stakeholder or their boss. If that’s the case for you, then you may not be fully empowered. As the person in charge of the product, you should have full-stack ownership of the product. You should possess the authority to ultimately determine which KPIs are used, and which ones aren’t—even though I recommend involving key stakeholders and development team members in the decision-making process. If you feel that you lack empowerment, consider how you can increase your authority. My article Boost Your Product Leadership Power will help you with this. Additionally, have the courage to take... - Published: 2022-05-04 - Modified: 2024-11-28 - URL: https://www.romanpichler.com/blog/product-teams-in-scrum/ - Categories: Product Leadership, Product Roles - Tags: innovation, scrum, stakeholders, teamwork Scrum is a powerful framework that connects the person in charge of the product with the individuals designing and building it. But it offers limited advice on how to collaborate with the stakeholders and involve them in strategic product decisions. This issue can be addressed by forming a product team that extends the traditional Scrum team, as I explain in this article. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/1ba59f1e-eb05-4d01-9d13-6dd0f3c5377f-Product-Teams-in-Scrum-04-05-2022-08. 04. mp3 Why the Scrum Team is Not Enough Scrum is a popular agile framework. Its strength is, at least partly, based on its roles with the Scrum team being the fundamental unit. This team consists of a product owner, a Scrum Master, and several developers, which are also known as development team. Forming such a team connects the person in charge of the product—the product owner—with the people who design, architect, program, test, and document the solution—the developers. It encourages direct interaction and close collaboration between them. But what Scrum lacks, in my mind, is a way to involve the key stakeholders, especially in strategic product decisions. That’s understandable, as the framework is focused on the development of complex products. But from a product management perspective, effectively engaging the stakeholders is crucial to achieving product success. Here is why: As the person in charge of the product, you typically require the stakeholders’ expertise to make the right product decisions. You might not know, for example, which marketing strategy is most appropriate or which sales channels are most effective. Consequently, you’ll benefit from the input of a marketer and a sales rep. You need the stakeholders’ support and contribution to successfully progress the product. The marketer might have to create or update the marketing strategy; the sales rep might have to adapt the sales channels, for instance. As the Scrum product owner, you should therefore establish close and trustful connections with the key stakeholders, collaborate with them, and involve them in important product decisions on a regular basis. Introducing the Product Team A great way to achieve this is to form a product team, as shown in Figure 1. Figure 1: Product Team vs. Scrum Team The product team in Figure 1 consists of Scrum team members and key stakeholders. The latter are those business stakeholders whose expertise and buy-in you need to make the right product decisions and achieve product success, as I explain in the article Getting Stakeholder Engagement Right. For a commercial, revenue-generating product, the key stakeholders might include a marketer, sales rep, and customer service rep, for instance. Consequently, a product team is a cross-functional group that comprises everyone required to progress the product and achieve product success. Forming such a team facilitates direct interaction and close communication between the product owner, the key stakeholders, the development team members, and the Scrum Master. Rather than talking to stakeholders on a one-on-one basis and possibly trying to negotiate a compromise between them, you literally bring the right people together and invite them to share their ideas and concerns with the entire group. This creates a shared understanding and a sense of togetherness, assuming that the group interactions are facilitated well. Note that the term product team is used in different ways by different people—much like other product management expressions. Some fellow authors include the stakeholders, for instance, Steve Haines in his book The Product Manager’s Desk Reference, whereas others don’t, for example, Marty Cagan in his book Inspired. I believe that the first definition is more helpful, especially in an agile context. Tips for Forming Effective Product Teams in Scrum As the product team is meant to be a proper team, a group of people who work towards shared goals and who trust and support each other, you should carefully setup and guide such a team. The following six tips will help you with this. Organise around a product. A product team is best formed around a product . This supports a product-led approach, and it makes it more likely that the team has the necessary autonomy to effectively progress the product. Form the product team early on, ideally when you are about to carry out the initial product strategy work for a new product. The team members should stay together for an extended period, preferably for the entire product life cycle. This creates stability and continuity. It allows people to get to know each other, build trust, and work together effectively; and it avoids costly handoffs and loss of knowledge. Bring the members together on a regular basis, be it online or onsite. Invite the individuals to product strategy review meetings and sprint reviews. This ensures that the members are involved in strategic and tactical product decisions and have a holistic understanding of how the product is evolving. Invest in team building. This does not necessarily have to involve big days out. Having coffee or lunch together and checking-in... - Published: 2022-04-05 - Modified: 2022-04-09 - URL: https://www.romanpichler.com/blog/10-tips-for-effective-product-management-meetings/ - Categories: Product Leadership - Tags: decision-making, Scrum Master, stakeholders, teamwork Meetings are essential to align the stakeholders and development team members and make the right product decisions. But we’ve all been stuck in bad meetings that lacked a clear objective, didn’t have an agenda, were dominated by a few vocal individuals, started late, or overran. Such meetings are unproductive and demotivating. It doesn’t have to be this way, though. The following ten tips will help you run successful product management meetings that engage the attendees and help you achieve the desired outcomes. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/c2eed9e2-23ea-423c-916e-e4dc27045e88-10-Tips-for-Effective-Product-Management-Meetings-06-04-2022-12. 00. mp3 1 Set an Objective Be clear on the reason why the meeting is needed. What’s the meeting about? Which outcome do you want to achieve? For example, a product strategy workshop might have the objective to identify the key changes required to achieve product-market fit. Contrast this with a sprint review meeting, which might help you determine if users can easily sign up for the product. Without a clear and specific objective you will find it hard to determine what needs to be achieved, who needs to attend, and how you can effectively structure the meeting. If you struggle to find a such an objective, then this may indicate that the meeting is not required. 2 Involve the Right People Carefully consider who should participate in the meeting to achieve the objective you have set. For product strategy and roadmap meetings, I recommend involving the key stakeholders, for example, someone from sales, marketing, support, and finance, as well as development team representatives—ideally members who know about the user experience (UX), architecture, and technologies. But for sprint review meetings, you may also want to invite (selected) users and customers to collect their feedback. As a rule of thumb, avoid meetings with more than ten attendees when you have to make high-impact decisions and/or rework the product strategy, product roadmap, or product backlog. I find that engagement tends to decline when the group grows significantly larger and reaching agreement becomes harder. Consequently, you often have to run longer meetings. This can make it harder for people to free up the necessary time and attend them. 3 Have the Right Input Available Make sure that the relevant data is available prior to the meeting. Which input you need will depend on the meeting type and its objective. Here are three meetings with sample input data: Product strategy workshop: product performance data (KPIs), competitive analysis, market trends, development progress, for example, in the form of a release burndown chart, and user feedback on recent product increments. (This assumes that you review and update the strategy and roadmap together, an approach I find very useful. )Sprint planning meeting: product goal, prioritised product backlog with enough ready items, development team capacity for the next sprint, and any action items from the last sprint retrospective. Sprint review meeting: sprint goal, product increment, definition of done, release burndown chart. Consider sharing the input beforehand when you run a strategy workshop so that people can prepare for the meeting. This can speed up the decision-making process and lead to better decisions. 4 Prepare an Agenda Decide how you want to structure the meeting and determine the steps you will have to take to achieve the objective. For example, for a strategy workshop, you might want to choose the following agenda: Welcome and check-in. State objective and agenda. Discuss product performance data (KPIs), competitive analysis, and market trends. Assess product strategy and adjust if necessary. Discuss development progress and user feedback on the latest product increments. Review and adjust product roadmap; check potential impact on the product strategy. Close the meeting. Don’t forget to allocate time for each agenda item and to add one or more breaks to the agenda if the meeting lasts longer than one hour. Share the agenda—together with the objective—in the meeting invite so that the attendees know what will happen in the meeting. 5 Make Time to Check-in Set aside time at the beginning of the meeting to check-in, to allow people to casually touch base and reconnect. One way to do this is to ask the attendees to briefly answer the following two questions: How am I feeling right now? Why am I feeling this way? While you might be tempted to skip checking-in to save time and get more done, this is usually a bad idea, especially in an online setting where it’s much harder for people to socialise and engage in a chat. Setting aside five minutes to check in shows the attendees that you are interested in how they are doing. It makes people feel valued, and it encourages everyone to contribute to the meeting right from the start. This can increase psychological safety, boost productivity, and lead to better decisions. To put it differently, if you don’t check, you might slow down the progress and achieve poorer results. 6 Use a Facilitator It can be challenging to get everyone to engage in a meeting in the right way. Some individuals may... - Published: 2022-03-09 - Modified: 2024-09-30 - URL: https://www.romanpichler.com/blog/six-qualities-of-a-great-product-vision/ - Categories: Essential Articles, Product Vision and Strategy - Tags: alignment, ethics, leadership style, product vision board, stakeholders The product vision can be a powerful tool to align stakeholders and development teams. When used effectively, it acts as the product’s true north, and it inspires and guides people. This article helps you create such a vision. It describes six essential qualities that a compelling product vision has to have. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/fe8d0259-b607-464a-9796-0b811871bcb8-Six-Qualities-of-a-Great-Product-Vision-09-03-2022-09. 05. mp3 Inspiring An inspiring vision creates a meaningful purpose for everyone involved in making the product a success including the stakeholders and development team members. It helps people understand how their work relates to a bigger whole and how their efforts create a positive change. It also allows you, as the person in charge of the product, to understand if dedicating your time and energy to the offering is worthwhile and sustainable. If the vision resonates with you, then this will help you do a great job, especially when the going gets tough. If that's not the case, then you should maybe look for a different challenge. As Steve Jobs once said, “If you are working on something that you really care about, you don't have to be pushed. The vision pulls you. ” Additionally, an inspiring vision helps you apply a visionary leadership style and become a visionary leader—someone who guides others through a big, motivating goal. Shared A shared vision unites people. It creates alignment, and it facilitates collaboration. A vision is shared when the stakeholders and development team members support the goal and are happy to work towards it. If that's not the case, then it will be difficult to encourage the individuals to agree to more specific goals and to follow a product strategy and a product roadmap that are based on the vision. A great way to ensure that your vision is shared is to create it together with the stakeholders and dev team members in a collaborative workshop, be it online or onsite. Encourage the participants to describe the purpose that they associate with the product. Then look for a product vision that everyone can support. Visioning Workshop Attendees As the vision is truly fundamental, you should take the time required to create an inclusive goal that resonates with everyone. Resist the temptation to shortcut or rush the decision-making process. Similarly, don’t allow the most powerful person to dominate and don't make the mistake of agreeing on the smallest common denominator. Otherwise, you'll end up with an ineffective vision that fails to inspire and guide people. Ask the Scrum Master or agile coach to facilitate so you can focus on shaping the vision and you don't have to ensure that everyone is heard and that nobody hijacks the decision-making process. (See my article Making Effective Product Decisions for more advice on how to decide together with stakeholders and dev teams. ) Ethical An ethical vision gives rise to a product that benefits its users and customers and that does not cause any harm to people and planet. This includes not affecting people's mental health, for instance, by getting them hooked or offering content that promotes misinformation, self-harm, hatred, and violence. Additionally, an ethical product does not contribute to climate change, and it does not damage the environment by how it is developed, provided, and if it includes hardware, manufactured, delivered, and disposed of. While the vision alone doesn't achieve ethicality, it plays a crucial role, as it describes the intention for offering the product. You ultimately have to ask yourself why you want to provide the product. Is it to help others, or is it to maximise your own benefits? Concise A concise product vision is easy to communicate, understand, and remember. To achieve this, I like to capture the vision as a brief statement or a slogan—a short, catchy phrase. An example for a product that helps people improve their eating habits might be “help people eat healthily. ” A handy tool to describe the vision is my product vision board. The board, shown in the picture below, captures the vision in the top section and the strategy in the four sections underneath it. You can download the board from the tools section of my website and by clicking on the image. Ambitious You can think of the product vision as a big, hairy, audacious goal (BHAG). Such a vision increases the chances of providing a continuous purpose in an ever-changing world, compared to a narrow, specific one. I would therefore choose a big, ambitious vision like “help people eat healthily” over a more specific, narrower one like “help people lose weight. ” Note that such a product vision is not measurable. It truly is an inspirational, grand goal. Enduring Despite its name, a product vision should not describe the product or solution. For example, “offer a weight loss mobile app” and “become the number... - Published: 2022-02-09 - Modified: 2022-03-09 - URL: https://www.romanpichler.com/blog/why-product-owners-need-effective-scrum-masters/ - Categories: Product Roles - Tags: organisational change, product owner, scrum, Scrum Master, self-organisation When you consider who the important partners for product people are, your thoughts might turn to the stakeholders, development team, and sponsor. But having an effective Scrum Master is crucial when you work with a Scrum-based process. Sadly, many product owners don’t have an effective Scrum Master at their side. More often than not, this causes the individuals to take on some Scrum Master duties like coaching the development team. In this article, I explain why this is a bad idea, why you need a qualified Scrum Master to succeed as a product owner, and what you can do when you lack one. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/647c5652-c942-4e7b-81f3-5213e9d30313-Why-Product-Owners-Need-Effective-Scrum-Masters-09-02-2022-08. 44. mp3 What the Scrum Master Should Do While the role is discussed in many books and articles, I find that it is still not always correctly understood. What’s more, it’s not uncommon in my experience that product owners have to do their job without the support of a Scrum Master or agile coach. So why is the role important? I view the Scrum Master as someone who takes care of process, collaboration, and organisational change issues. This includes the following six duties: Roles: Ensure that the right roles are in place and their authority and responsibilities are clear to everyone. This includes product roles such as product owner and feature owner. Staffing: Help find people who have the right skills and are motivated to work on the product and who can fill the roles. For example, I’ve seen organisations where the Scrum Masters work with HR and the development teams to recruit new team members. Process and collaboration: Teach agile values, principles, and practises to the product owners, development teams, stakeholders, and management. Help people use the right processes in the right way; help them discover ways to improve their work, for instance, in the form of sprint retrospectives. Productive work environment: Help set up an environment that is conducive to creative teamwork and encourage people to practice sustainable pace—to do a great job without getting overworked, losing motivation, and falling ill. Ensure that people have the infrastructure and tools they need to do a good job. This includes laptops, tablets, phones, and software tools; but it may also include having access to a kitchen and a coffee machine. Organisational change and empowerment: Work with senior management, HR, and other business groups to implement the necessary organisational changes required to fully empower product people and leverage agile practises. Meetings: Prepare and facilitate meetings. This includes sprint planning, Daily Scrum, sprint review, and sprint retrospective, as well as product strategy and product roadmap workshops. Establish ground rules and ensure that everyone is heard, and that nobody dominates. Having an effective Scrum Master allows you to focus on your job—to maximise the value the product create. It avoids that you get too involved with people, process, and organisational issues. A Scrum Master can also be a sparring partner for you—someone who you can discuss concerns with and who offers helpful feedback. You can think of the product owner and Scrum Master as two complementary roles in Scrum: the former is responsible for product success and the latter for process success. And without the right processes in place, it is hard to maximise value creation on a continued basis. What the Scrum Master Should NOT Do In theory, your Scrum Master should focus on providing people and process leadership. In practice, however, Scrum Masters sometimes take on duties that do not belong to the role, including the following three ones: Project management: The Scrum Master is not a project manager, even though that’s a common misunderstanding. The individual should neither identify and assign tasks nor create reports like a release burndown chart, for example. Instead, the person should teach the Scrum product owner and development team how to how to proactively manage a sprint and a release, respectively. Product backlog work: Keeping the product backlog up to date is a responsibility the Scrum product owner and development team share. But it’s not the job of the Scrum Master. You should therefore not expect that your Scrum Master refines the backlog for you. The individual is not a product backlog manager or a user story writer. The same is true for setting product goals. An effective Scrum Master will remind you to select product goals, but the individual won’t do it for you. Team management: The Scrum Master should not manage the development team. Instead, the individual should help the team practise self-management so that the members learn to make realistic commitments and work together effectively. You can view the Scrum Master as an enabler or a coach, as someone who helps others understand how they can create a valuable product rather than doing the work for them. Dealing with a Non-existent or Ineffective Scrum Master As I mentioned earlier, it’s not uncommon in my experience that there is no Scrum Master at all or that the role is not effectively applied. But as the Scrum Master work is important, someone else usually steps up and takes on the duties. Often, that’s you, the person in... - Published: 2022-01-11 - Modified: 2026-05-11 - URL: https://www.romanpichler.com/blog/a-learning-roadmap/ - Categories: Essential Articles, Product Leadership, Product Roadmap, Product Roles - Tags: GO product roadmap, learning, self-leadership, skills Working in product management can be very rewarding. But it can also be very challenging. One of the reasons is the diverse skills that are needed to succeed as the person in charge of the product. To acquire and deepen them, you will benefit from a focused learning plan. This article discusses such a plan in the form of a learning roadmap. I explain what a learning roadmap is, how you can create one, and how you can effectively put the plan into action and become an even better product professional. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/770bb347-8d19-42eb-b4d6-3c36d1cfbaa8-A-Learning-Roadmap-for-Product-People-11-01-2022-08. 14. mp3 Overview of the Learning Roadmap Like a modern product roadmap, a learning roadmap states the specific outcomes or benefits you’d like to achieve to become a more competent product person, and it captures them in form of learning goals. These help you direct your learning efforts, track progress, and measure how much you have learnt. To make these ideas more concrete, let’s look at a sample learning roadmap. The roadmap in figure 1 is based on my GO product roadmap template. It contains the following four rows: Figure 1: A Sample Learning Roadmap The first row describes when the learning goals should be met for the next 12 months. I’ve chosen quarters in the sample roadmap above, but you can use shorter time frames, of course, if you can meet your learning goals more quickly. The second line names the skills areas the learning goals belong to, which I’ll cover in more detail in the next section. For the first two quarters, the area is strategy; for the last two, it is leadership. The third row contains the most important information. It lists the learning goals you want to achieve. The first goal is about creating a new strategy, the second one talks about the product life cycle model, the third one covers decision-making, and the last one addresses active listening. The fourth and final line states how you intend to meet the learning goals. In the roadmap in figure 1, I listed the key topics to be addressed and the learning measures that will be used to acquire and deepen the skills. Note that you may want to make the measures as specific as you can and state, for instance, the title of the books you intend to read. A learning roadmap like the one above offers four benefits: First and foremost, it gives you a goal-directed plan that focuses your learning efforts. Many learning plans I have seen were lists of learning measures. They lacked clear, achievable learning goals that built on each other and described a meaningful learning journey. Second, a learning roadmap allows you to leverage your product roadmapping skills and use them to create an actionable learning plan. For example, the guidelines I have developed for the GO product roadmap template directly apply to the roadmap in figure 1. Third, capturing the plan as a roadmap concisely describes the learning path you want to take and nicely visualises it. Fourth, a goal-oriented, outcome-based roadmap is compatible with OKRs. You can view the goals as objectives and the dates, topics, and learning measures as key results. This can help you tie individual learning goals to team and department goals. Creating the Learning Roadmap To build a learning roadmap, take the following three steps. First, reflect on your current product management skills and determine any gaps and shortcomings in your current skill set. Second, identify the right learning opportunities. Third, derive the right learning goals, put them on your learning roadmap and add the additional information. Let’s look at these steps in more detail. Step 1: Understand the strengths and weaknesses in your product management skill set To analyse your current product management skills, I recommend using the following three subsets: Tactical skills, strategic skills, and leadership skills, as the following picture shows. Figure 2: A Product Mmgt Skills Model The tactical skills in figure 2 include the ability to create user models and personas; stock, prioritise, update, and refine the product backlog; capture user stories; apply the right solution validation techniques, for example, product demo, usability test, and early release; and have a rough understanding of how the product is designed and architected. The strategic skills comprise the capabilities to create, validate, and evolve an effective product strategy; develop, review, and update an actionable product roadmap; use the right KPIs; choose the right business model and create a financial forecast. The leadership skills, finally, include the ability to empathise even with seemingly difficult users and stakeholders; earn people’s trust and build strong connections; to actively listen to users, stakeholders, and development team members; to set the right goals—from the product vision to individual sprint goals; to resolve disagreement and conflict; and to effectively involve stakeholders and dev team members in product decisions. As (digital) product management is a diverse and comparatively young profession, it is completely normal to have gaps or shortcomings in your product management knowledge and skill set. You might find, for instance, that you... - Published: 2021-12-07 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/four-product-success-factors/ - Categories: Product Vision and Strategy - Tags: business model, ethics, innovation, product vision board, validation Our ultimate goal as product people is to achieve sustained product success: to ensure that our products do a great job for their users and customers and that they generate value for our businesses on a continued basis. While achieving product success cannot be reduced to a simple formula, there are four factors that have a profound impact on it, as I discuss in this article. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/d30447c7-0c4b-4422-82b6-6f80f0a133d9-Four-Product-Success-Factors-07-12-2021-08. 34. mp3 The Four Factors Explained To achieve lasting success, a product must fulfil the following four conditions. First, it has to address a specific need that a group of people have. Second, it has to be feasible to develop it. Third, it has to generate sufficient business benefits to justify developing it. Fourth, it must not cause any harm to its users, the wider society, and the planet. In other words, desirability, feasibility, viability, and ethicality have to be met. They truly are the cornerstones of product success, as the picture below illustrates. Let’s look at the four success factors in more detail. Desirability is probably the most important factor. If people don’t need or want to use a product, it will fail. To be desirable, a product has to solve a specific problem or offer a tangible benefit. Take the example of Sonos, a wireless hi-fi system that allows people to enjoy music by providing easy access to a range of streaming services. It’s simple and convenient to use, and it offers a decent sound quality. Products like the Sonos system are sometimes called vitamins, as they provide a nice-to-have benefit, similar to vitamin supplements. Compare this to a product like Apple’s AirTags, which address the issue of finding keys and other misplaced items. Such a product is also referred to as a painkiller, as it addresses a problem or pain point. But no matter how a product is classified, it must create value for its users—or it is doomed. Feasibility implies that it is possible to design and build the product: the technologies required exist or can be developed. Additionally, enough people with the right skills are available or can be recruited. If, for example, developing the product requires the application of advanced machine learning algorithms, then you’d have to explore if appropriate machine-learning frameworks exist, or if it’s possible to develop the algorithms in house. Viability means that developing and providing the product is viable from a business perspective. The product therefore has to create enough business benefits to justify spending money on it. These may include generating revenue, reducing cost, increasing productivity, and strengthening the brand. Examples of revenue-generating products are Google Search, which generates money through ads, and Microsoft Word, which is monetised through subscriptions (as part of the Office suite). Contrast them with products like the Google Chrome browser and Microsoft Edge, which offer different business benefits: they allow the companies to control how users access the Internet, tie them to their respective ecosystems, and make it more likely that they interact with revenue-generating offerings. Ethicality, finally, states that a product must not cause any harm to people and planet: It must not reduce people’s mental wellbeing, for example, by getting them hooked or by offering content that promotes misinformation, self-harm, or violence. Additionally, an ethical product does not contribute to climate change and does not damage the environment by how it is developed, provided, and—if it includes hardware and plastics—manufactured, delivered, and disposed of. To achieve this, you will benefit from a business model that is fair to all parties and from making ethically sound design and programming decisions, for instance, by avoiding the use of dark patterns and mitigating machine learning biases. The first three factors were—as far as I know—originally suggested by Tim Brown in his book Change by Design. He describes them as competing constraints that must be balanced to innovate successfully. But as Brown notes, this could result in “dreaming up alluring but essentially meaningless products destined for the local landfill—persuading people ... ‘to buy things they don’t need with money they don’t have to impress neighbours who don’t care. ’” What’s more, the impact digital products can have on people’s mental health makes it compulsory in my mind to add ethicality as a fourth success factor. On the positive side, an ethical product increases the chances of achieving lasting product success, and it reduces the risk that the reputation of the company suffers, as some tech companies have had to experience in recent years. Applying the Success Factors Knowing which factors influence product success is helpful. But it’s even better to use them when you make strategic product decisions. To see how this can be done, let’s explore how the success factors can be applied to the product vision board. The board captures the vision and strategy of a product, and it consist of five sections: vision, which describes the... - Published: 2021-11-02 - Modified: 2025-07-14 - URL: https://www.romanpichler.com/blog/dealing-with-performance-issues-on-the-development-team/ - Categories: Product Leadership - Tags: product owner, scrum As the person in charge of the product, you rely on the development team to do a good job. But some teams are held back by performance issues and fail to reliably deliver working software. This article shares my advice on how product people can deal with an underperforming development team and help the group improve. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/f5cce4df-3919-435c-b27e-505e5490fc5e-Dealing-with-Performance-Issues-on-the-Development-Team-02-11-2021-12. 29. mp3 What is Bad Performance? Before I discuss how you can help an underachieving team, let’s briefly explore what good performance looks like, assuming that an agile, Scrum-based process is used. A development team does a good job if the following three conditions are fulfilled: First, the group reliably meets the agreed sprint goals and delivers product increments that offer a great user experience and exhibit the desired software quality. Second, the team participates in continuous discovery and strategizing, and its members regularly help refine the product backlog. Third, the team observes sustainable pace. The workload and intensity do not affect the team members’ wellbeing. If one of these requirements are not fulfilled, the team needs to improve their work. Here are three common symptoms of a development team struggling to do a good job: The team repeatedly over commits or delivers buggy software; the team members expect that you, the person in charge of the product, does the product backlog work and writes the user stories; and finally, the team members repeatedly have to work extra hours to finish the work in the sprint. As the person in charge of the product, you depend on the work of the development team and you are, of course, affected by poor performance. This includes not being able to release working software to (selected) users and customers, finding it hard to reliably forecast the development progress, and possibly getting overworked as you don’t receive the necessary support from the development team. It is hence in your best interest to help the team get back on track. At the same time, you are not the boss, and you cannot tell the team members what to do. What’s more, an agile, self-managing team is collectively responsible for their performance. This can make it challenging to help a development team improve. Share Your Views but Don’t Tell People What to Do To discuss how you might help a struggling team, let’s use an example. Say that you are working on a new brand-new product. The current sprint has an important goal: to release the product increment to selected users and validate if the functionality offered works for them. Additionally, you’ve invited the senior management sponsor to the upcoming sprint review meeting to secure the individual’s continued support. But during today’s Daily Scrum meeting, you notice that the sprint progress has been worryingly slow: Plenty of tasks aren’t finished, and some stories haven’t even been started. It seems that the development team is behind schedule and will find it hard to reach the sprint goal. The team, however, does not seem to be concerned. In this situation, it can be tempting to step in, tell the development team that they must get their act together and possibly even assign specific tasks to individual members. But this would be wrong. You would interfere with and damage the team’s self-management. An agile team is responsible for planning and tracking the work, reviewing the progress on a daily basis, and deciding how the work should be done to maximise the chances to meet the sprint goal. If you stepped in and took control, you would act as a project manager and essentially disempower the team. But this does not mean that you should be a passive bystander and watch the team fail. If you believe that the development team needs your help, then talk directly to them, for example, after a Daily Scrum. However, ask the team members for their views before you share yours. You might say, for example, “How are things going? Do you think you are on track to meet the sprint goal? ” Then attentively listen to what the individuals have to say. If you are not satisfied with the answers and believe that the team members are not aware of the issue, share your view without judgement and criticism. You might say, for example, “It seems to me that the development progress has been slow. Several tasks aren’t finished, and some stories haven’t been started. Do you think that’s true? ” But leave it up to the team to decide what needs to be done, and do not force your perspective onto them. You might be wrong after all: The team might be doing a great job despite your concerns. If you are unsure if you should say something or not, talk to the Scrum Master who is responsible for helping the team practice self-management, as... - Published: 2021-10-05 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/product-backlog-mistakes/ - Categories: Product Backlog & User Stories - Tags: prioritisation, product goal, risk, scrum The product backlog is a simple yet powerful tool to capture and revise detailed product decisions and direct the work of the development team. Unfortunately, effectively using the backlog can be challenging. This article discusses seven common product backlog mistakes to help you recognise and fix them. https://episodes. castos. com/5e296c8fcbc2e2-83044581/bfdb7c35-15ec-4192-be90-2e7f5f437b3d-Seven-Product-Backlog-Mistakes-to-Avoid-05-10-2021-08. mp3 The Product Backlog is Too Big A few years ago, I was asked to help a healthcare company with their agile transition and its impact on product management. One of the challenges the agile transition team was concerned about was the choice of the right product backlog tool, which at first seemed odd to me. But when I was told that the backlog in question had over 40,000 items, I could see that there was an issue. Admittedly, that’s by far the largest product backlog I have come across to date. But I find it not uncommon to encounter backlogs that range from several hundred to a few thousand items. But such a product backlog is difficult to comprehend, let alone prioritise and update. This is problematic especially for young products and those that experience a bigger change, like a life cycle extension, as their backlogs tend to be volatile and require frequent and sometimes bigger adjustments. You should therefore strive to keep your product backlog as concise as possible whenever your product faces uncertainty and change—be it market, business, or technology related. The following three techniques will help you with this: First, group related items into themes. Second, keep lower-priority items coarse grained. Third and most importantly, focus the backlog on a specific product goal. Then decline and remove items that do not serve this goal, as I discuss below. The Product Backlog is Too Detailed Another time, I was asked to help a team of a major charity in the UK whose task was to create a new website for their fund-raising campaigns. The product owner told me that she’d refined the product backlog as well as she could but that the development team were still not happy with it. Looking at the backlog, I noticed that it contained only detailed user stories—no epics or other coarse-grained items. But an overly detailed product backlog makes it hard to see the wood for the trees: There is simply too much information. This, in turn, makes it difficult to prioritise and update the artefact. What’s more, it is likely to contain speculative and ultimately wrong items, especially when the development effort is characterised by uncertainty and change. I therefore recommend that you start with an initial product backlog that is intentionally sketchy and incomplete, especially when your product is young or experiences a bigger change. Then let the backlog evolve based on the feedback received from users, customers, and stakeholders. This allows you to minimise the effort to stock the product backlog and to base your product decisions on empirical evidence, rather than gut-feeling. The Product Backlog is Not Appropriately Refined A while back, I was working with a company that connects consumers in the UK with a tradesperson like a plumber or gardener. Back then, the company was still a startup, and the product owner had asked me to help them address a planning issue: The development team routinely overcommitted and never managed complete all the work in a sprint. When I was shown around the office, I saw some paper cards on the wall with big, sketchy epics on them, and I asked the product owner if these were part of the product backlog. The individual replied, “No, this is the product backlog. ” Given that the backlog did not contain any sufficiently refined, ready items I was no longer surprised that the development team struggled to get sprint planning right. While you don’t want to make your product backlog any more detailed than necessary, you should ensure that its high-priority items are ready. This requires them to fulfil the following three criteria: First, they are sufficiently clear and understood by the development team. Second, they can be completed in a sprint according to the Definition of Done. Third, they can be tested. Getting the high-priority items ready is best done together with (some of) the development team members, as I discuss below. The Product Backlog is a Wish List Some product backlogs—like the one with 40,000 items mentioned above—resemble a wish list, a catalogue that contains anything and everything that you might ever need. The trouble with such a backlog is not only that it is usually too big. It also results in a “feature soup,” a product that resembles a loose collection of unrelated features. This leads to a weak value proposition and a poor user experience, which are hardly hallmarks of a great product. But if these backlogs are so bad,... - Published: 2021-09-07 - Modified: 2022-04-28 - URL: https://www.romanpichler.com/blog/three-qualities-of-great-product-roadmaps/ - Categories: Essential Articles, Product Roadmap - Tags: alignment, GO product roadmap, planning, product goal, stakeholders, teamwork The product roadmap can be an incredibly useful planning tool that aligns the stakeholders and development teams and communicates how a product is likely to evolve. Sadly, that’s not the case for all roadmaps. To ensure that your product roadmap is effective, you should make it goal-oriented or outcome-based, shared, and actionable, as I explain in this article. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/Three-Qualities-of-Great-Product-Roadmaps-07-09-2021-08. mp3 Goal-oriented (a. k. a. Outcome-based) Traditionally, product roadmaps are output-focussed plans that map features like registration, search, and reporting onto a timeline. Such a roadmap essentially states when a piece of functionality will be delivered. This can be reassuring for customers and stakeholders, as the individuals believe that they know when their features will be delivered. But this approach has three drawbacks: First, a feature-based roadmap makes it hard to secure agreement and create alignment, as stakeholders often compete to get their feature on the roadmap. Second, it overlaps with the product backlog, especially when detailed features are used. This makes the product roadmap more susceptible to change and it increases the effort to update it. Third, the features are sometimes regarded as a commitment rather than a part of a high-level plan that is likely to change. This limits your ability to experiment and learn, to discover the best way to address the user and customer needs and create value for the business. I therefore recommend applying a different product roadmapping approach and using goal-oriented roadmaps, which are also called outcome-based. As their name suggests, these roadmaps focus on product goals or outcomes such as acquiring customers, increasing engagement, and future-proofing the product by removing technical debt. The goals state the specific value a product is likely to create and therefore communicate why it is worthwhile to progress it. This helps align the stakeholders and development teams, as I discuss below, and acquire a budget if required. Lastly, goal-oriented roadmaps are compatible with objectives and key results (OKRs): You can think of the goals as objectives and the other roadmap elements as the key results, as I explain in my article OKRs in Product Management. These benefits make goal-oriented, outcome-based product roadmaps preferable to traditional, feature-focused plans, especially for digital products that exhibit uncertainty and change virtually across their entire life cycles. If you are looking for a template to create a goal-oriented roadmap, then try my GO product roadmap shown below. In addition to goals, the template above contains dates or time frames, names, features, and metrics. Note that the features depend on the outcomes: Each feature must help meet a goal and achieve the desired benefit. What’s more, the goals are the primary roadmap elements and are used to secure agreement. You can find more information about the template in my article The GO Product Roadmap. Shared No matter how well thought-out your product roadmap is, it is worthless if the key stakeholders and the development team members don’t understand and support it. A great way to achieve a shared roadmap is to involve the individuals in the product roadmapping decisions, preferably in the form of a collaborative workshop—be it online or onsite. Note that collaborative roadmapping does not mean that everybody gets their way or is necessarily super happy with every single decision. It means leveraging people’s expertise to create a product roadmap that maximises the value the product creates and that attracts as much support as possible. While it’s important that you cultivate an open mind, attentively listen to the ideas and concerns of the stakeholders and dev teams, and empathise with them, you should not allow the individuals to tell you what to do. Otherwise, your roadmap may end up being a weak compromise rather than a compelling plan that helps create the desired value for the users and the business. Have the courage to say no and ensure that the roadmap tells a coherent story about the likely growth of your product. Consider asking your Scrum Master or agile coach to facilitate the workshop and to ensure that everybody is heard and nobody dominates, assuming that a Scrum Master is available. This is particularly helpful when the attendees are new to collaborative decision-making and when they haven't worked together before. (See my article Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams for more information on collaborative decision-making. ) Actionable For a product roadmap to be effective, it must be actionable. The best way to achieve this is to base the plan on a validated product strategy, a strategy whose key assumptions have been tested. Such a strategy should state the user and customer needs, the target group, the product’s stand-out features, and its business goals. Before you develop a roadmap, you should therefore create and validate a product strategy, as the following picture shows. Additionally, you will have to choose a... - Published: 2021-08-17 - Modified: 2022-04-25 - URL: https://www.romanpichler.com/blog/product-vision-faqs/ - Categories: Product Vision and Strategy - Tags: alignment, product vision board, teamwork The product vision can be a powerful instrument to inspire and align stakeholders and development teams. But in practice, it is not always effectively applied. This article shares questions about the product vision I am frequently asked together with my answers. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/Product-Vision-Board-FAQs-17-08-2021-08. mp3 What is the Product Vision? The product vision describes the ultimate purpose of a product, the positive change it will bring about. You can think of it as a big, hairy, audacious goal (BHAG)—or a moon shot—that inspires people and offers continued guidance for the next five to ten years. Say I wanted to create a product that helps people become more aware of what and how much they eat. As the product vision, I could then choose “help people eat healthily” or just “healthy eating. ” While the example states the purpose of a new product, I find that a vision is equally beneficial for an existing one. What Makes a Good Product Vision? A good, effective product vision fulfils the following six criteria: Inspiring: The product vision creates a purpose for the people working on the product. It provides motivation and guidance even if the going gets tough. Shared: The vision unites people, and acts as the product’s true north.  Ethical: A good vision gives rise to an ethical product, a product that truly benefits its users and that does not cause any harm to people and planet. Concise: The product vision is easy to understand and remember. Using slogan—a short, memorable phrase—can be a great way to create such a vision. Ambitious: It describes a big, visionary goal. Enduring: Despite its name, I recommend keeping the product vision free from assumptions about the actual product or solution. This allows you change the product strategy and the product while you stay grounded in your vision. Who Owns the Product Vision? Ideally, a product vision is collectively owned by the person in charge of a product, the key stakeholders, and the development team(s). This ensures that the individuals support the vision and follow it—rather than paying lip service to it. A great way to foster joint ownership is to develop the product vision together, as I describe in the section “How do I Create an Inspiring Product Vision? ” As the person in charge of a product, you should ensure, however, that a meaningful product vision exists and guide the effort to create one. How do I Capture the Product Vision? As mentioned above, I find it helpful to use a brief statement or a slogan to describe the product vision. This increases the chances that people understand and remember it. An elaborate or verbose vision that looks great on paper but is hard to understand and memorise offers little value. Additionally, I like to capture the product vision together with the product strategy, as it’s done on my product vision board shown below. The board encourages you to state the product vision at the top and the product strategy underneath it. You can find more information about the product vision board above in my book Strategize and the article The Product Vision Board. Can the Product Vision and the Company Vision Be the Same? Yes, the two can be identical. But I recommend using two separate visions—unless you work for an early-stage start-up. The company vision should describe the purpose of the entire organisation, the reason why the business exists. Take, for example, IKEA’s vision to “create a better everyday life for the many people. ” The product vision, however, should communicate the ultimate reason for developing and offering a specific product, for instance, IKEA’s app that allows users to design their own PAX wardrobe. Does Every Product Have to Have its Own Vision? Every product should have a vision, but not every offering requires its own, unique one. Say your product is part of a product portfolio like Microsoft Office. As its products are closely related, I would use one overarching vision for the entire portfolio, a product portfolio vision so to speak. In Microsoft Office’s case, this might be, “help people collaborate in real time. ” Word, PowerPoint, Excel, and the other Office products would then share this vision. Do I need a Product Vision and a Product Strategy? If your vision describes the ultimate purpose for creating the product, you will have to complement it with a product strategy. While the vision is great to inspire the stakeholders and development teams, it is not enough to direct their work. This is where the product strategy comes in. You can think of it as the approach chosen to realise the vision and achieve product success, as the following picture shows. An effective product strategy should clearly state the... - Published: 2021-07-06 - Modified: 2026-07-10 - URL: https://www.romanpichler.com/blog/tips-for-moving-into-a-head-of-product-role/ - Categories: Essential Articles, Product Leadership, Product Roles - Tags: conflict, empathy, empowerment, trust Becoming a head of product and managing a group of product people is a significant career step. In this article, I share my recommendations to help you get ready for the new job and be off to a great start. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/Tips-for-Becoming-a-Head-of-Product-06-07-2021-08. mp3 Be Prepared to Look after People, Not Products When you become a head of product, you move into a management position. Consequently, your focus shifts from looking after a product to leading the product people on your team and helping them to do a great job. Instead of creating, for example, product strategies and roadmaps and tracking KPIs, you should help the people on your team acquire the right knowledge and develop the right skills so that they can carry out the relevant work on their own. This will allow them to take full ownership of and responsibility for their products, and it will increase their motivation, productivity, and job satisfaction. A great way to do this is to mentor and coach people. For instance, you might show the individuals how they can make effective strategic product decisions, create an actionable product roadmap, and effectively use the right KPIs. Another key aspect to support the people on your team succeed is to create the right environment for people to succeed. This includes establishing psychological safety, fostering collaboration and trust amongst the product people, establishing clear roles and expectations, which I'll discuss below, and ensuring that everyone has the right infrastructure and tools available. Becoming the head of product therefore requires you to let go of your role as a practicing and presumably successful product person and to step away from the many joys and challenges of managing a product. For some people, that's straightforward. But others find it hard to no longer be actively involved in making product decisions, regularly talking to users, engaging the stakeholders, and working with development teams. Additionally, being an effective leader requires you to cultivate a genuine caring attitude for the people you want to lead, whether you like them or not. It means that you'll have to deal with people issues on a regular basis, help and support the individuals who are on your team, constructively address problems and offer advice. To put it differently, to lead means to serve and support others. If it's hard for you to let go of being actively involved in managing a product or if you don't find it rewarding to help and support a group of product people, then becoming a head of product is probably not right for you, at least not at this point in time. Grow Your Leadership Skills To be able to effectively lead and support a group of product people, you will benefit from having developed strong leadership and people skills, including the following ones: Empathy: You are able to reach out with warm-heartedness even to individuals who you don’t agree with and who you find not likeable, value their perspectives, and take a genuine interest in their needs. Trust, integrity, and respect: You can earn the trust of others, speak and act with integrity, and create an environment where people feel safe and respected. Active listening: You are used to listening to others with the intention to understand, not to answer. You give the other person your full attention, and you keep an open mind whilst hearing what the individual has to say. Feedback: You are able to offer constructive feedback so that the other person can receive it and benefit from it. You are also able to skilfully deal with difficult feedback and criticism that others share with you. Goal setting: You can lead others through shared goals that create a common purpose and give the individuals the autonomy they need to do a great job. Decision-making: You understand how groups can effectively make decisions, and you are able to secure strong buy-in to important product decisions from others, including the stakeholders and development teams. Conflict: You can constructively deal with disagreements and conflicts rather than ignoring or suppressing them, or ending up with damaged relationships, bad feelings, and mistrust. Time management: You have learnt to effectively manage your time, and you are able to practice sustainable pace. Group dynamics: You know what it takes for a group of people to effectively work together, and you are able to help a group of individuals jell. A great way to develop these skills is to manage a larger product together with a group of product people who you lead—without being their boss. But even if this option is not available to you, guiding a group of stakeholders and one or more development teams will allow you to practice the skills listed above. Ensure... - Published: 2021-06-07 - Modified: 2024-09-30 - URL: https://www.romanpichler.com/blog/tips-for-deciding-with-stakeholders-and-dev-teams/ - Categories: Essential Articles, Product Leadership, Stakeholder Management - Tags: decision-making, empathy, stakeholders, teamwork I am a big fan of involving the stakeholders and dev teams in important product decisions. But deciding together can be challenging: The most senior stakeholder might try to dictate the decision, the group might shy away from difficult conversations, or people might get stuck in endless debates. This article shares eight practical tips to help you avoid these pitfalls and harness the full power of collaborative decision-making. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/Making-Effective-Product-Decisions-07-06-2021-14. mp3 Be Clear on When to Involve the Stakeholders and Development Teams You can—and should—make many business-as-usual decisions on your own. Complex and high-impact decisions, however, are best made together with the stakeholders and development teams. There are two reasons for this: First, you usually require people’s expertise to help you tackle complex issues, for instance, to understand technical risks or the impact on the ability to market and sell the product. Second, you need strong support from the stakeholders and dev team members for high-impact decisions in order to ensure that they are effectively followed through. Involving the individuals in the decision-making process show them that you value their input, and it provides them with the opportunity to influence the decision. This, in turn, makes it more likely that they will support and implement the decision. In practical terms, involve stakeholders and dev teams in decisions that affect the product strategy and the product roadmap—be it that you create the plans or that you make bigger changes to them. Examples of the latter include deciding if you should pivot, address a new market or market segment, retire a product, and if you should replace the product goals or change the dates on a product roadmap. Additionally, include the development team members in product backlog decisions, and always choose sprint goals together. Bring the Right People Together Once you've established that a decision should be made collaboratively, carefully consider who needs to be involved in the decision-making process to ensure that the right decision is made and that it receives the necessary support. Then invite the right people to a collaborative workshop, no matter if it takes place online or onsite. A joint workshop creates transparency; it allows the individuals to understand each other’s perspectives and interests; and it frees you from having to go forth and back between the individual stakeholders and dev teams until an agreeable proposal has finally been found.   If you are unsure which stakeholders you should involve, then carry out a stakeholder analysis using, for example, Ackermann and Eden’s power-interest grid shown below. The grid encourages you to divide the stakeholders into four groups, as I explain in more detail in my article Getting Stakeholder Engagement Right. Once you have done this, focus on the players. These are the individuals whose input you need to make the right decision, who help you progress and offer the product, and who are affected by the product and its ability to create value. For a revenue-generating product, this might be someone from marketing, sales, support, and finance. If you work with several development teams, ask each team to send one or two representatives to the workshop. I find it useful to have UX design, architecture, programming, and testing skills present to make the right decision. And in a scaled environment where you share product ownership, involve the product people who work with you, for example, feature owners. Use a Dedicated Facilitator When you bring people together to make a decision, getting the individuals to engage in a constructive conversation can be challenging, as you might have experienced yourself. Some individuals might enjoy sharing their ideas so much that they won’t stop talking. Others might be shy and reluctant to contribute, and senior members might expect that their suggestions are followed by everyone. What's more, you are usually required to actively contribute to the decision and share your expertise, as the person in charge of the product. I therefore recommend using a dedicated, skilled facilitator who runs the meeting and facilitates the decision-making process. This might be your Scrum Master, assuming that the role is filled, and that the individual has the skills required. The facilitator should establish ground rules, help people embrace a collaborative mindset, create an environment where people feel safe to speak their minds, encourage everyone to fully participate and prevent individuals from dominating, ensure that an appropriate decision rule has been chosen, and guide everyone through the decision-making process. Having a dedicated facilitator can be especially useful in an online workshop where people may need more encouragement to fully participate and stay engaged. Lead by Example Deciding together becomes difficult when people act in self-centered ways and aim to maximise their personal gain, seek to dominate the discussion, or believe that they know best and that their idea must win. What’s needed to develop an inclusive solution and reach a sustainable agreement is a collaborative mindset. I... - Published: 2021-05-11 - Modified: 2024-12-06 - URL: https://www.romanpichler.com/blog/five-product-owner-myths-busted/ - Categories: Product Roles - Tags: empowerment, product manager, product owner, scrum The product owner is a role which is often misunderstood and frequently misapplied. In this article, I address five common product owner misconceptions. I explain why they are wrong and how the role can be effectively implemented. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/Five-Product-Owner-Myths-Busted-11-05-2021-08. mp3 Myth #1: The product owner must ensure that the stakeholders are satisfied Stakeholders can be powerful and influential individuals. But the value a product creates is ultimately determined by its users: No product will be successful in the long run if it does not solve a specific user problem, create a tangible benefit, or help the users achieve a specific goal. While internal stakeholders such as marketing, sales, and support play an important role in successfully offering a product, it would be wrong to try to please them and to say yes to all their ideas and requests. In the worst case, you’d end up with a product that implements the stakeholders’ requirements but does not effectively address the user and customer needs. At the same token, ignoring the stakeholders or excluding them from important product decisions is not helpful either. Instead, you should engage the stakeholders, leverage their expertise, and generate as much buy-in as possible, as I explain in more detail in my article "Stakeholder Management Tips for Product People. " But do not allow people to dominate and tell you what to do, and don't agree to a weak compromise. As the product owner, then you should own the product on behalf of the company and be empowered to have the final say, particularly if no agreement can be reached. Myth #2: The product owner is a tactical role focused on managing the product backlog In Scrum—the framework that gave birth to the product owner—the role is responsible for maximising the value a product creates for the users and for the business. This requires full-stack ownership: having the authority to make strategic product decisions in addition to tactical ones. Consequently, a Scrum product owner should own a product in its entirety—from the product vision to the product details. The individual should carry out product strategy work in addition to taking care of the product backlog work. But the situation is different for product owners in the agile scaling framework SAFe. The framework uses its own product owner role, which is different from the one in Scrum. The SAFe product owner is tactical in nature and focuses on working on the product backlog and guiding the development teams. The strategic work is taken on by another role, the SAFe product manager. Splitting product ownership and using a strategic and tactical role is a common scaling technique—although not necessarily the most helpful one, as I discuss in more detail in my article “Scaling the Product Owner. ” The following picture summarises the difference between the Scrum and SAFe product owner roles. Be therefore clear which product owner role you play and if you are a Scrum or a SAFe product owner, as your authority and accountability will significantly differ. I have always regarded the Scrum product owner as an agile product manager, and I find it an unfortunate mistake that SAFe use the same name for its tactical product role. This has created more confusion and increased the misconceptions of the role. Myth #3: The product owner is responsible for the team performance An agile development team does a good job if the members can reliably meet the agreed goals and create software that offers a great user experience and exhibit the desired quality. As such a team is a self-managing group, the members are expected to jointly plan the work, decide how it is carried out, track the progress, resolve any disagreements and conflicts, and practice sustainable pace to stay productive and motivated. As it takes time for group of people to become an effective self-managing team and learn to make realistic commitments, the dev team needs a Scrum Master or agile coach who supports and advises them. This includes showing the dev team how agile processes can be applied and suggesting specific techniques, facilitating meetings, and teaching people how to constructively deal with conflicts. In other words, the Scrum Master is responsible for helping the team do a good job. But as the product owner, you should focus on the product, not the team and the process. That’s usually challenging enough. Don’t make the mistake to cover the Scrum Master’s work over an extended period, as this will either cause you to neglect some of your core responsibilities or sacrifice your health—neither of which is desirable, of course. If you lack a Scrum Master, or if the individual is not sufficiently available or qualified, then consider what you can... - Published: 2021-04-13 - Modified: 2024-06-03 - URL: https://www.romanpichler.com/blog/how-to-choose-the-right-kpis-for-your-product/ - Categories: Essential Articles, Product Vision and Strategy - Tags: KPIs, learning, metrics, software quality A key challenge of working with KPIs is to select the right indicators: There are so many different metrics to choose from including daily active users, net promoter score, and profit, to name just a few. What’s more, senior managers and stakeholders can have strong views on which indicators should be used. This article helps you select the metrics that really matter and are truly helpful for your product. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/How-to-Choose-the-Right-KPIs-for-Your-Product-13-04-2021-08. mp3 What are KPIs? Key performance indicators (KPIs) are metrics that measure how your product is doing. Effective KPIs help you understand if your product is creating the desired value for the users, the customers, and the business. Without KPIs, you end up guessing how well your product is performing. It’s like driving a car with your vision blurred: You can’t see if you are heading in the right direction or getting closer to your destination. You might have a hunch, but you don’t know if it is correct. Using KPIs and collecting the relevant data helps you balance intuition with empirical evidence. This increases the chances of making the right decisions and achieving product success. A Goal-directed Approach to Choosing KPIs To select the right KPIs, I recommend taking the following three steps: First, use the user and business goals in the product strategy to select an initial set of indicators. Then take into account the product goals on the product roadmap to discover additional KPIs. Finally, choose further indicators to assess the health of your product and team. This, of course, assumes that you have a validated product strategy and a realistic product roadmap in place. If that’s not the case, then I recommend creating those two plans first. As you may have noticed, I suggest using a goal-directed approach to identify the right indicators. I am not a big fan of “standard” KPIs, for example, customer acquisition cost (CAC), churn, and number of active users for SaaS products. While it’s helpful to be aware of the indicators that may be commonly used for the type of product you manage, it would be a mistake to blindly adopt them. Employing user, business, and product goals to guide the selection of KPIs avoids this mistake and it ensures that your indicators are relevant and helpful, as the following image shows. You can download the infographic by clicking on the picture. Step 1: Take Advantage of the Product’s User and Business Goals To select the right KPIs, start with the needs and the business goals in the product strategy. Then consider how you can tell if they have been met. Say I want to offer a product that reduces the blood sugar levels of individuals who have type-2 diabetes and that generates £50k of revenue within the first 12 months of launching the app. I would then ask myself how I can measure that the product creates the desired user and business value. To determine the former, I might choose user feedback, customer satisfaction, and referral rate as the key performance indicators. To understand the latter, I might select monthly recurring revenue (MRR). Note that this approach assumes that valid user and business goals are available. In other words, the goals should be part of a validated product strategy—a strategy whose key assumptions and risks have been successfully addressed. This might have involved observing target users, interviewing them, carrying out competitor research, and using throw-away prototypes, to name just a few strategy validation techniques. Step 2: Use Product Goals to Discover Additional KPIs In addition to deriving KPIs from the user and business goals, I like to use the product goals I have captured on the product roadmap in order to discover additional indicators. A product goal is a specific and measurable benefit or outcome your product should achieve, typically in the next two to three months. What’s more, every product goal should be aligned with the user and business goals in the product strategy, as I explain in more detail in my article “Product Goals in Scrum. ” Say the goal of my initial product (MVP) is to allow the users to better understand their eating habits and acquire an initial user base. I would then look at the first part of this goal and ask myself if I need to introduce a new indicator. As I’ve already chosen user feedback, customer satisfaction score, and referral rate, I would not add another metric at this stage. But the second part, acquire an initial user base, would require the introduction of a new KPI in order to understand if the acquisition goal has been met. To do so, I might measure market share, for instance, by tracking the product’s position in the appropriate app store. Step 3: Add Health Indicators Measuring how well your product is doing at meeting its user, business, and product goals is great. But it is not enough. Let’s... - Published: 2021-03-09 - Modified: 2022-04-28 - URL: https://www.romanpichler.com/blog/product-goals-in-scrum/ - Categories: Essential Articles, Product Backlog & User Stories, Product Management Process - Tags: GO product roadmap, product goal, scrum The 2020 edition of the Scrum Guide introduced a new type of goal, the product goal. This article shares my recommendations to help you as the person in charge of the product set effective product goals. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/Product-Goals-in-Scrum-09-03-2021-09. mp3 Product Goals Defined The Scrum Guide released in November 2020 states that “the product goal describes a future state of the product ... is the long-term objective for the Scrum team. ” It also suggests that “the product goal is in the product backlog. The rest of the product backlog emerges to define ‘what’ will fulfill the product goal. ” The product owner is accountable for “developing and explicitly communicating the product goal. ” The entire Scrum team is “focused on one ... product goal” at a time. If this definition leaves you scratching your head, don’t worry. Scrum is a simple framework designed to facilitate the development of complex products. It does not intend to prescribe how the practices it offers should be applied. As a consequence, different people have suggested different ways to apply the product goal. Some view it as the product vision, others equate it to the product’s value proposition. I find, however, that a product goal is best used to describe a specific and measurable benefit or outcome a product should create in the course of the next two to six months. A sample goal might be to acquire users, increase conversion, generate revenue, or reduce technical debt. Such a goal aligns the stakeholders and development teams, and it directs their work. What’s more, I like to ensure that product goals are connected to the product strategy and its user and business goals. This helps me choose the right product goals and it ensures that meeting a product goal is a step towards creating the desired value for the users and the business, as figure 1 shows. Figure 1: The Product Goal in Context In figure 1, the vision is the basis for choosing the user and business goals, and the latter create the context for determining the right product goal. At the same token, each product goal acts as the foundation for identifying helpful sprint goals. In other words, the goals are connected and form a cascading set of product-related goals. Please see my article “Leading Through Shared Goals” and my book How to Lead in Product Management for more information how to effectively use the goals in figure 1, which includes securing the necessary buy-in from the stakeholders and development teams. Background Story: Readers familiar with the history of Scrum—sometimes lovingly referred to as Scrumtorians—will undoubtedly know that it has contained sprint goals at least since 2002 and a (product) vision since 2004, even though the latter is not mentioned in the Scrum Guide. When I started to work with Scrum in 2004, I could not get my head around the question of how to systematically connect a big, inspiring vision to a tactical, short-term sprint goal. It took me years to come up with the set of goals in figure 1. In hindsight, the set looks disappointingly simple You can also access the contents of this article on my YouTube Channel: https://youtu. be/i0NWukbHkDM Sample Goals To better understand how the goals in figure 1 can be applied, let’s take a look at an example. Figure 2: Sample Goals In figure 2, I first captured the vision “Help people eat healthily” and then used it to choose the user and business goals “Reduce the risk of developing type-two diabetes; create new revenue source. ” In order to determine the right product goal, I asked myself, “What would be a first good step to meet the from the user and business goal? ” I consequently chose the product goal “Help the users understand their eating habits and acquire an initial user base. ” I then used this goal to determine the right sprint goal. I figured that finding out if users are willing to share personal information when activating the app would be the most important risk to address and hence should be the goal of the first sprint. Note that I chose to use a compound product goal in figure 2 that has a user part—help the users understand their eating habits and business—and a business one—acquire an initial user base. Both parts are closely connected: In order to acquire a user base, the product must offer tangible value to the users, and a first step to help people eat more healthily is to help them become aware of their current eating habits. You don’t have to work with compound product goals of course, if you prefer to focus your objectives on either the user... - Published: 2021-02-02 - Modified: 2023-10-09 - URL: https://www.romanpichler.com/blog/how-agile-has-changed-product-management/ - Categories: Product Management Process - Tags: empowerment, kanban, overburden, scrum, sustainable pace As the Manifesto for Agile Software Development celebrates its 20th anniversary, I take a look at how agile practices have influenced and changed product management. I discuss the benefits that have been achieved and the challenges that still remain. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/How-Agile-Has-Changed-Product-Management-02-02-2021-08. mp3 Once Upon a Time in Waterfall Land Before the advent of agile frameworks like Scrum, a product person—the product manager—would typically carry out the market research, compile a market requirements specification, create a business case, put together product roadmap, write a requirements specification, and then hand it off to a project manager. The latter would work with one or more development teams to get the specification implemented. During the development phase, the product manager would be only loosely involved, typically attending a project steering meeting and possibly issuing change requests. Otherwise, the individual would hope that the requirements were implemented as specified. Only once the product was close to being finished would the product manager return to the project and prepare the release of the product. This sequential, waterfall-based approach used to work when there was little change and innovation, when product managers could correctly predict what the users needed and describe the detailed product functionality upfront. But it is less suited to create complex digital products. You can also access the content of this article on my YouTube channel. https://youtu. be/oDjkQxXw-2U The Brave New Agile World As agile practices have become more widely adopted, the processes used to develop products have significantly changed: Product people and development teams now tend to collaborate much more closely. Dev teams have become cross-functional consisting of UX designers, architects, programmers, testers, and other roles. Products are developed using iterative-incremental processes like Scrum. Requirements are no longer detailed and frozen before development starts but they emerge. An increasing number of organisations have moved away from organising around projects and have started to embrace a product-led approach. Early user feedback, frequent solution validation: We now have the ability to collect early and frequent user and customer feedback, which helps us validate our ideas and update our plans accordingly. This has increased the chances of creating a product with the right UX and the right features. Reduced time-to-market: We can now release new products and features more quickly. This is enabled by a closer, ongoing collaboration with cross-functional development teams, shifting from written documentation to face-to-face conversations, and using techniques such as user stories that reduce overhead—when applied correctly. Better product quality and improved adaptability: The quality of our products has improved through the application of agile development practices like emergent design, test-driven development, and continuous integration. This has allowed us to adapt the product more quickly and to respond to user feedback more easily. Better requirements: As product people, we are no longer solely responsible for coming up with the correct requirements. Instead, the dev team members actively participate in the product backlog refinement work and help us identify the necessary changes and capture new product backlog items. This leverages the team members’ creativity and expertise, creates a shared understanding, fosters collective ownership, improves the quality of the requirements, and ultimately results in better products. Transparent development progress: We can see the development progress more clearly and make corrections early if required: The progress is now based on working software rather than a detailed, Gantt chart-based project plan. This mitigates the risk of discovering late that the product cannot be shipped on time or that some features were implemented incorrectly. Improved alignment: Stakeholders and development teams are now better aligned through the use of regular collaborative workshops like sprint reviews. This creates a shared understanding and leads to greater commitment: Asking people about their perspectives and involving them in the process of making product decisions increases the likelihood that the individuals will support the decisions. Motivated productive teams: Last but not least, self-organising development teams tend to be more motivated and productive compared to traditional ones, as they are able to determine themselves how much work can be done in a given period, decide who carries out a specific piece of work, and agree on how the team members collaborate. Old and New Product Management Challenges While agile methods have given us plenty of benefits, a number of product management challenges still persist. These were not caused by agile practices, as far as I can tell. Agile has made them more visible, though, and it has exacerbated some of them. Let’s look at the key challenges that remain. Lack of empowerment: When coining the Scrum terms, Ken Schwaber and Jeff Sutherland chose the term product owner instead of product manager in order to emphasise the level of authority and empowerment a product person requires—especially in an agile... - Published: 2021-01-12 - Modified: 2024-12-06 - URL: https://www.romanpichler.com/blog/tips-for-saying-no-to-stakeholders/ - Categories: Product Leadership, Stakeholder Management - Tags: decision-making, empowerment, stakeholders Saying no is a firm part of our job as product people: Trying to please everyone and taking on board every idea is hardly a recipe for achieving product success. But saying no can be tough, especially when we are faced with a senior, assertive stakeholder. This article offers five practical tips to help you say no in the right way. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/5-Tips-for-Saying-No-to-Stakeholders-12-01-2021-08. mp3 Imagine that you are talking to John, a senior salesperson who’s been involved with the product for a while. John mentions the upcoming product release and says, “You really must add the enhanced reporting feature. I’ve spoken to several customers, and they have all confirmed that it is absolutely crucial. ” You know, though, that it is impossible to add the feature to the development effort. The dev team is struggling with the current workload, and moving the date is not an option. What’s more, you suspect that John’s request may be motivated by the desire to meet his sales targets. But John is a well-connected and influential individual who doesn’t like to be told that he is wrong. How can you decline his request without offending him and losing his support? You can also access the content of this article on my YouTube channel. https://youtu. be/DB0ggAe7ApA Don’t Feel Bad about Saying No Declining a request can be hard. You might not want to disappoint John in the example above, you might worry that saying no will anger him and lead to conflict, or you might not want to be seen as a naysayer but somebody who has a can-do attitude and wants to help. Saying no, however, is part and parcel of a product person’s job. If you said yes to every idea and request, you would end up with a feature soup, a product with an uncompelling value proposition and a poor user experience. As Steve Jobs once said, “Innovation is saying ‘no’ to 1,000 things. You have to pick carefully. ” If you believe, however, that it would be impossible for you to say no to John, then this may indicate that you are not properly empowered, that you lack the authority and respect required to be in charge of the product and be responsible for its success. If that’s the case, explore how you can strengthen your product leadership. Refer to my article "Boost Your Product Leadership Power" for more guidance. Empathise with the Stakeholder Having decided that you can’t accept John’s request, you might be tempted to share your view with the individual and say, for instance: “Sorry, John. But there is no way that I can add the feature to the current release. The development team is struggling to implement the agreed features, and, as you know, we can’t push out the date. ” This might seem like a reasonable answer: It’s direct and it offers an explanation. But would it be effective? If John does not feel heard and understood, it will be hard for him to accept no as an answer, no matter how valid your arguments are. Instead, he might feel rejected and react with disappointment or anger. He might think that you don’t appreciate his views and don’t care about his needs. Consequently, John may no longer fully trust and support you. To avoid this situation and maximise the chances that John can receive a no, empathise with the individual before you offer an answer. Find out why the feature is important to John. What is his personal, vested interest in getting the feature included in the release? Why does it matter to him? Only if John feels understood will he open up to your perspective, listen to your arguments, and accept that you can’t add the feature to the release. The following listening techniques will help you with this: Give your full attention to the individual. Maintain eye contact and show the person that you are interested in what she or he has to say. Keep an open mind even if you disagree with what you are hearing or if you dislike the individual. Listen with the intention to understand, not to answer. John might be right, after all, and you should add the feature to the release. Pay attention to the person’s body language. Non-verbal information—like voice pitch and volume, gestures, facial expressions, and eye movement—expresses the speaker’s feelings, which help you uncover the individual’s underlying interests. Ask clarifying and probing questions to check that you have correctly understood what was said and encourage the other person to provide more information. You might say, for instance, “Can you please help me understand why adding the feature is important to you? ” Reframe the Conversation Stakeholders often request specific features without necessarily being fully aware of the problem it addresses. But value is hardly created by adding a single piece of... - Published: 2020-12-01 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/okrs-in-product-management/ - Categories: Product Leadership - Tags: sprint goal, stakeholders OKRs—objectives and key results—have experienced a renewed popularity in recent years. Consequently, I am regularly asked if and how OKRs can be applied in product management. This article shares my thoughts. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/OKRs-in-Product-Management-01-12-2020-07. mp3 OKRs in a Nutshell OKRs are a method for setting and tracking goals. An objective describes what is to be achieved. The key results state how we accomplish the objective. Let’s say, for example, that the objective is to “increase engagement. ” The key results might then be “daily active users are up by 20%,” “session length is increased by 10% on average," and "the objective is achieved by 30 June 2021. ” OKRs can be used to create cascading goals—goals that are systematically linked. This is done by using higher-level key results as lower-level objectives, as the following example shows. Figure 1: Sample, cascading OKRs In figure 1, the key result "daily active users are up by 20%” becomes an objective with two new key results, “add feature alpha” and “implement auto login” thereby connecting the two OKRs. It’s worthwhile to note that OKRs were originally invented by Andy Grove at Intel in the 1970ies to facilitate “excellent execution,” that is, to help people set hard, measurable goals and to be able to clearly determine if these have been met. And that’s exactly how I experienced OKRs when I worked at Intel in the late 1990ies. Goals in Product Management As I explain in my book How to Lead in Product Management, setting the right goals is crucial to align stakeholders and development teams and to achieve product success. Does this mean that there is a natural fit between goals in product management and OKRs? In order to answer this question, let’s look at a set of product management goals. Figure 2 below shows the goals I recommend. Figure 2: A Chain of Product-related Goals Figure 2 contains a set of cascading goals: vision, user and business goals, product goals, and sprint goals. The vision guides the user and business goals, which are contained in the product strategy. The user and business goals help select the right product goals, which I capture on the product roadmap. A product goal, finally, helps determine the right sprint goals. At the same token, a sprint goal is a step towards a product goal; achieving a product goal helps you make progress towards the user and business goals; and the latter two finally help you move closer towards your vision. (For a more detailed explanation of the goals above, please see my article “Leading through Shared Goals,” and if you would like to learn more about goal setting in product management, then check out my book How to Lead in Product Management. ) Let’s now explore how the goals in figure 2 can be captured as OKRs. Capturing Product-related Goals as OKRs Say that I’d like to offer a product that helps people eat more healthily. I could then capture the goals shown in figure 2 as OKRs in the following way: Figure 3: Sample Product-related OKRs There are three things in figure 3 above that I’d like to bring to your attention: First, the top-level OKRs describe vision and product strategy. The vision is the objective, and the product strategy is expressed by the key results. Second, I have derived the product goal objective from the first and third key result of the top-level objective (as illustrated by the grey arrows). I have also used the first key result of the second objective to determine the third objective. This creates a set of cascading OKRs. I wasn’t able, however, to reuse higher-level key results as lower-level objectives, as shown in figure 1. Third, the second OKRs are the equivalent of the first entry on a goal-oriented product roadmap. If you want to work with a roadmap that looks further ahead, you will have to add additional OKRs to the ones in figure 3. Should You Use OKRs for Your Product? To answer this question, let’s consider some major benefits and drawbacks of applying OKRs in product management, starting with the positives: Consistency: Using OKRs means that all goals adhere to the same format. This can be particularly helpful when OKRs are widely used in the organisation and the stakeholders and development team members are familiar with the method. Validation: Coupling objectives with key results can help you tell if and when a goal has been met. Links: Being able to use key results as new objectives is very useful, even though I was not able to take advantage of it in the sample OKRs in figure 3. But I also see the following drawbacks:... - Published: 2020-11-03 - Modified: 2026-05-11 - URL: https://www.romanpichler.com/blog/the-product-strategy-cycle/ - Categories: Essential Articles, Product Management Process, Product Vision and Strategy - Tags: innovation, product discovery, scrum, teamwork Despite its importance, product strategy is not always effectively practiced. One of the key issues I encounter in my work is that strategy and execution are not aligned but rather disjointed. To address this issue, I have developed an iterative process called the product strategy cycle. The cycle systematically connects strategy and execution so that the former guides the latter and insights gained from the tactical work help evolve the product strategy. In this article, I explain how you can use the cycle to join up product strategy, product roadmap, KPIs, product backlog, and development work, and I discuss the role stakeholders and development team members play in making effective strategic product decisions. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/The-Product-Strategy-Cycle-03-11-2020-07. 57. mp3 Enter the Cycle Traditionally, strategy and execution are often viewed as separate, sequential pieces of work that are carried out by different people. For example, a product manager might determine the product strategy and one or more development teams might be tasked with executing it. But as long as innovation, change, and risk are present, this approach is ineffective. Instead, strategy and execution have to be closely connected: The former should not only guide execution, but execution should inform strategy changes and help adapt the strategy. Based on this insight, I have come up with the product strategy cycle shown in the picture below. It’s a model of an iterative process that systematically links the product strategy with the product roadmap, the product backlog, the development work, and the key performance indicators (KPIs). In the picture above, the process starts at the top of the cycle by creating a new strategy, either for a brand-new product or an existing one. In the latter case, a new strategy might be required to extend the product’s life cycle, for example, by addressing a new market or market segment. An effective product strategy should capture the product’s target group, value proposition, standout features, and business goals. Before you proceed further, you should validate your new strategy and address key risks and assumptions in order to maximise the chances of achieving product success. For example, the market segment you have chosen might be too big and heterogenous, the value proposition might not be compelling enough, or the business goals might not be feasible. Identifying and addressing the key risks in the product strategy is best done iteratively, as I explain in more detail in my book Strategize. I have therefore placed a small cycle next to "Product Strategy" in the picture above. Once you’ve addressed the key risks and you are confident that you have chosen the right needs, market, standout features, and business goals, you can take the next step and derive a product roadmap from the strategy. I view the roadmap as a product plan that describes how you intend to implement the strategy and which specific benefits or outcomes the product should provide over the next, say, 12 months, based on the needs and business goals stated in the product strategy. I call these outcomes product goals. Sample product goals are acquiring new users, increasing engagement, removing technical debt to future-proof the product, and generating revenue. With an actionable product roadmap in place, move on and stock your product backlog. To do so, choose the next product goal stated on the product roadmap, determine the features and functionality required to meet it, and capture them in the backlog. Then create just enough ready product backlog items to be able to start the upcoming sprint and develop the actual product. As an iterative process is usually best suited to create a new product or a major product update, I've added another little cycle between "Product Backlog" and "Product" in the picture above. After development has started, measure the development progress, for instance, by using a release burndown chart. When an initial or new version of the product has been released, use the KPIs to measure the product performance. These should include the metrics required to determine if the product goal chosen has been met and additional indicators that help you assess how your product is doing and if the strategy is working. Examples of the latter are engagement, retention, product quality, team motivation, and in the case of a revenue-generating product, revenue and cost. Use the KPIs and the development progress data to review the product strategy and the product roadmap, and change them as appropriate. This might involve making smaller, incremental adjustments. But it might also require you to pivot, to significantly change the strategy in order to make the product successful. Take YouTube as a well-known example. The product pivoted from a dating website to a video-sharing platform. You have now completed the cycle and started another one. Involve the Right People Systematically connecting strategy and execution is a key factor to establish an effective product strategy practice. But it is not enough. The best product strategy is useless if the stakeholders and development team(s) do not buy into it and are not prepared to implement the decisions that it captures. To maximise the chances that people understand and support the strategic product decisions, I recommend that you involve the key... - Published: 2020-10-06 - Modified: 2024-09-30 - URL: https://www.romanpichler.com/blog/a-brief-guide-to-product-discovery/ - Categories: Product Management Process, Product Vision and Strategy - Tags: innovation, product manager, product owner, product vision board, scrum, stakeholders, teamwork When practiced correctly, product discovery maximises the chances of achieving product success. Unfortunately, I find that it's not uncommon that companies lack an effective product discovery approach. This article offers help. It explains what product discovery is, why it matters, and how it helps you maximise the chances of creating a successful product. It discusses when, how and by whom product discovery should be carried out. Finally, it describes how product discovery helps you progress existing products. What is Product Strategizing? Product strategizing describes the activities required to determine if and why a product should be developed and offered. This increases the chances of creating a product that users actually want and need and achieving product success, and it involves answering the following questions: What is the specific value the product should create for the users and customers? What problem should it solve, or which benefit should it create? Which market and market segment should the product address? Who are the users and who are the customers? What makes the product stand out? How will it differ from competing offerings? What are its business goals? How will it benefit the company? For example, generate revenue or meet a profit margin, reduce cost, or develop the brand? What business model will it use in order to achieve the business goals, including revenue sources, cost factors, and channels? Will the product make a positive impact on people’s lives, the wider society, and the planet, or will it at least not cause any harm? How might people use the product? What are the major touch points? What kind of user experience (UX) should the product give rise to? How can the product be built? What architecture patterns and technologies may be used? In order to answer the questions above, you may want to use techniques such as direct observation, user interviews, prototyping, creating a strategy canvas or E-R-R-C grid, and you may capture some of them using a tool like my Product Vision Board. Whatever you do, I suggest that you follow Steve Blank’s advice and “get out of the building”. Meeting users and customers, at least in the form of a video call, not only helps you validate your assumptions and develop new ideas. It also allows you to empathise with the individuals and to better understand their perspectives and needs. I find it helpful to distinguish two types of product strategizing: timeboxed and continuous discovery. Let’s look at timeboxed strategizing first. Timeboxed Product Strategizing Whenever you create a brand-new product or when you make bigger changes to an existing one, like taking it to a new market, you will benefit from using a dedicated, timeboxed product strategy period. This results in an innovation process like the one shown in the picture below. In the picture above, the product strategy work precedes product development. The former focuses on understanding if and why a product should be created or updated. The latter largely determines how the product should be developed. This includes discovering the right UX design and functionality and making the right technical decisions. Note that I have purposefully drawn discovery and development as overlapping, as I find it helpful to address major UX and technical risks as part of the strategizing work—without making the mistake of using big design upfront (BDU). Addressing these risks ensures that the development team has the right knowledge to hit the ground running when starting development. Consequently, the key deliverables include the following: Validated product strategy and business model, Actionable product roadmap that implements the strategy, Valid business model, Initial product backlog that captures the necessary product details, A high-level UX design concept and coarse-grained software architecture supplemented by throwaway prototypes (spikes). As it’s notoriously difficult to correctly forecast how much time a bigger piece of strategy work will require, I recommend timeboxing it. To do so, consider the amount of innovation and risk present and allocate an appropriate timebox. If you were to develop a brand-new product for a new market with new technologies, for instance, then you would face more risks compared to taking an existing product to a new market. Consequently, the former will require more time than the latter. You might want to allocate, say, two months for the first initiative, but only two weeks for the latter, assuming that you already serve the new target market. Additionally, I recommend running weekly review sessions to understand the progress of the discovery work and adapt it if necessary. To carry out the strategizing work, bring together the right people, product person, development team representative, key stakeholders, and Scrum Master or agile coach, as shown in the picture below. As the person in charge of the product, you should lead the strategizing and development effort. Here’s why: You can’t be responsible for maximising the value a product creates if you don’t actively participate in, guide the discovery work, and shape strategic product decisions. Development team representatives—ideally a UX designer, one or... - Published: 2020-09-02 - Modified: 2022-04-28 - URL: https://www.romanpichler.com/blog/prioritising-a-product-backlog-when-everything-is-important/ - Categories: Essential Articles, Product Backlog & User Stories - Tags: requirements, risk The product backlog is an essential product management tool: It captures detailed product decisions and directs the work of the development team. The latter requires it to be prioritised or ordered. But how can you prioritise a product backlog when everything seems equally important? This article shares my answer. It recommends taking four steps to get to an effective, prioritised product backlog. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/Prioritising-a-Product-Backlog-When-Everything-is-Important-02-09-2020-08. 42. mp3 Step 1: Ensure that you know who the product is for and why people will want to use it I’ll never forget the day when I suggested to the product manager of a brand-new healthcare product to prioritise its features. The individual looked at me slightly bewildered and replied, "I can’t. They are all high-priority. " Prioritisation requires deciding how important an item is. If everything is high priority, everything is equally important. This means in effect that nothing is a priority. But without clear priorities, the development team lacks direction, and there is only a slim chance of creating a successful product. A common root cause of not being able to prioritise a product backlog is a lack of understanding of who the users of the product are and what specific value it should create for them. I find it not uncommon that features are added to the product backlog because a senior stakeholder demands it (HIPPO syndrome) or someone thinks it is a good idea (“let’s brainstorm some user stories”). But a product exists to generate value for the users and for the company providing it. If it is not clear who the users are and why they would want to interact with the product, it will be hard to decide which items should be in the product backlog and how important they are. To mitigate the risk of adding the wrong items to the product backlog, ensure that you have a validated product strategy in place, no matter if you look after a brand-new or as an existing product. Such a strategy should clearly state the following: The users and customers of the product so that it is clear who will benefit from it and who won’t;The main problem the product should address or the primary benefit it should offer, or the main goal users will want to achieve with it;The three to five features that will make it stand out from the crowd;The specific benefits it should create for the business. Let’s look at a brief example and say that I want to create a product that helps people eat healthily. Then I could choose to address middle aged men who suffer from unhealthy eating habits and who don’t exercise enough. The benefit might be to reduce the risk of developing type-2 diabetes. The standout features might be to measure food sugar levels, analyse the user’s eating habits, and integrate with leading smart scales. The business goals, finally, might be to diversify my company and open up a new revenue stream. Additionally, you should be confident that your strategy is correct, and you should have data to support your view. In other words, you should have addressed the key assumptions and risks in the product strategy, and you should have carried out the necessary validation work. A tool like my product vision board helps you capture and validate your product strategy. Step 2: Describe the outcome or benefit the product should create in the next few months Having a product strategy in place is great, but it is not enough to effectively prioritise a product backlog. What’s required is a specific product goal that is connected to the strategy and creates the right context to decide which backlog items are more important and which ones are less. To create such a goal, ask yourself which outcome or benefit your product should achieve in the next, say, three to six months. What are the desired user and business benefits you want to create? Make sure that this goal is in line with the product strategy and that it helps create the desired user and business benefits. An example based on the sample strategy above would be "help the users understand their eating habits and acquire an initial user base. " (Note that I have chosen a compound goal that captures the desired user and business benefits. ) I like to take this idea further, derive several product goals from the product strategy for the next 12 months, and capture them on a product roadmap. This puts the goal chosen in context and communicates how the product is likely to evolve over a longer period. If you have a product roadmap, then ensure that it implements the overall product strategy. Consider reworking it so that it clearly states the desired outcomes your product should achieve. Step 3: Remove all items from the product backlog that do not support the... - Published: 2020-08-11 - Modified: 2023-10-09 - URL: https://www.romanpichler.com/blog/common-product-vision-board-mistakes/ - Categories: Product Vision and Strategy - Tags: product vision board The product vision board is a simple yet powerful tool to capture the product vision and the product strategy. Despite its simplicity, effectively using it can be challenging. I have seen many boards over the years that suffered from a number of shortcomings including a poorly defined target group, an unconvincing value proposition, and business goals that weren’t measurable. This article helps you recognise and rectify common product vision board mistakes, thereby maximising the chances of creating an inspiring vision and a winning product strategy. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/Common-Product-Vision-Board-Mistakes-11-08-2020-08. 27. mp3 A Brief Guide to this Article This article assumes that you are familiar with the product vision board or the key elements of a product strategy: market, value proposition, standout features, and business goals. The overall example I use to illustrate the mistakes is a healthy eating app that helps its users improve their eating habits and live more healthily. While I wrote the article for people who work with the product vision board, I hope that it will also be useful for readers who use another product strategy tool like the value proposition canvas or the lean canvas. If you are new to the product vision board, then you may might to read the article "The Product Vision Board" or watch the video "Introduction to the Product Vision Board". You may also want to download the vision board template to try it out for yourself. Vision Captures Product Idea or Business Objective Examples: “Offer a weight loss mobile app”, “Become the number one weight loss app provider” Problem: When you tie the vision to the product idea or a specific business objective, you lose the ability to pivot—to change the strategy but to stay grounded in the vision. Additionally, such a vision is hardly inspiring. A good vision exercises pull—it describes a future state that people want to bring about. Cause: A confusion about what an effective product vision is. Solution: Describe the ultimate purpose of your product, the positive change the product should bring about like “healthy eating”. Think of the vision as a big, hairy, audacious goal (BHAG) that inspires people and offers a continuity of purpose for the next five to ten years. More Information: 8 Tips for Creating A Compelling Product Vision and Strategize, pp. 18. Target Group is (too) Big and Heterogenous Examples: “Everyone who owns a smartphone”, “Business users and consumers” Problem: A very big and diverse target group makes it hard to formulate a crisp, compelling value proposition and strong standout features. It can also result in a large product backlog and high development cost: The greater the number of people who should benefit from your product is, the more diverse their needs are likely to be, and the more features are usually required to address them. Trying to offer a product that pleases everybody carries the risk of not doing a good job for anyone. Causes: A lack of understanding of users and their needs, lack of empowerment of the person in charge of the product, inappropriate growth strategy. Solution: Successful products are not built by agreeing on the smallest common denominator or trying to please powerful stakeholders. Instead, they require tough strategic decision and clear focus. Therefore, choose a specific market segment and develop a product for the few, not the many, as Steve Blank suggested, particularly when you manage a new or young product. After your product has reached product-market fit and has become more feature rich, consider unbundling bigger features and creating product variants to address the needs of specific groups. For example, I might decide to offer a version for middle aged men to help them reduce the risk of developing type 2 diabetes and a version for children to help them overcome a specific eating disorder. Additionally, strengthen your ability to guide the stakeholders and dev teams: Increase your referent power and earn people’s trust, strengthen your product management expertise, and lobby for more management support. More Information: Market Segmentation Tips and Strategize, pp. 59; Boost Your Product Leadership Power and How to Lead in Product Management, pp. 36. Many Needs but No Compelling Reason for Using the Product Examples: “Lose weight, be more active, feel better, be fitter” Problem: If a product does not address a clear and compelling need, it will be difficult to encourage users to use it; uptake and engagement are likely to be poor. Consequently, it will be hard to achieve the desired business benefits and monetise the product. Causes: Lack of understanding what problems users really face and what they really need; a target group that is too large and heterogenous, as discussed above. Solution: Focus on the main reason for people to use the product, the primary benefit that the product should offer to the users or the main problem it should address. Another approach is to identify the main goal users will want to achieve by using the product or to find the primary job the product should do... - Published: 2020-07-07 - Modified: 2023-01-13 - URL: https://www.romanpichler.com/blog/feature-teams-vs-component-teams/ - Categories: Product Management Process, Product Roles - Tags: product life cycle, scaling Whenever you require more than a single development team to progress your product, you have to consider how to organise the teams. One choice is to use feature and component teams. This article explains why this distinction matters for product people, and it shares my advice on when feature teams are right for your product and when component teams might be better suited. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/Are-Feature-Teams-or-Component-Teams-Right-for-Your-Product-07-07-2020-08. 13. mp3 What are Feature and Component Teams? A feature team is a development team that implements end-user functionality end-to-end. Contrast this with a component team. Such a team owns an architecture building block, for example, a layer, a subsystem, or a collection of components or services, as figure 1 illustrates. Figure 1: Feature vs. Component Team Figure 1 depicts a simple software architecture that consists of three layers: user interface, business logic, and data. Say that I want to develop an app that helps people eat healthily. A feature team might then develop the capability that allows users to see their eating trend, for instance. It would implement the feature as a vertical slice, from the user interface down to the data layer. A component team, however, might develop the business logic that calculates recommended calorie intake. The team would not touch any of the other layers but exclusively focus on the business logic. Why Does this Matter to Product People? When your product starts to attract more users, you typically require more development teams to sustain the growth, enhance features, and add new ones. This presents you with a choice: You can organise the teams primarily around features or architecture building blocks. This choice matters: It will affect your ability to progress your product and achieve its strategic goals, as I explain in more detail below. Feature and component teams both come with benefits and drawbacks. The former have a strong end-user focus: They work on functionality that creates value for the end users. Feature teams can also consume items directly from the product backlog and turn them into working software. Additionally, they are loosely coupled and not dependent on the work of other feature teams. This has two benefits: First, it allows you to quickly test an idea and release a feature fake or early version of a feature, gather user feedback, and adapt it. Second, if one feature team fails to deliver, then you can usually still use the work of the other teams. But using feature teams can introduce user experience and architecture inconsistencies and it can lead to code duplication. In the worst case, each team creates its own user experience and user interface design, its own business logic, and its own data layer, to stay with the architecture example shown in figure 1. Component teams avoid these drawbacks. As they are organised around architecture building blocks, they enforce architecture consistency. Additionally, it can be easier to staff component teams compared to feature teams. In figure 1, every feature team would need someone with the appropriate user interface design skills, for instance. On the downside, component teams often cannot consume items directly from the product backlog. The teams that own the business logic and data layer in figure 1 need technical requirements that describe the interfaces that should be created or enhanced. Translating end-user requirements into technical ones creates overhead and slows down development. What’s more, as component teams tend to build software for other development teams, they can lose sight of the end users and sub-optimise their building blocks: I have seen component teams who were more concerned about the performance of their components than the end-user experience. When are Feature Teams Preferable and When are Component Teams Better? I recommend that you prefer feature teams over component teams as long as your product experiences bigger changes. This is typically the case for brand-new products, products in the introduction stage, products that rapidly grow, and products whose life cycle is being extended, for example, by taking them to a new market or adding new features. But once your product is stable, once it has entered the maturity stage (and you don’t intend to extend its life cycle), then component teams tend to be a better choice, as figure 2 shows. Figure 2: Feature and Component Teams and the Product Life Cycle Features teams allow you to move fast, add new functionality, respond to user feedback, and adapt your product. This makes them better suited for coping with innovation, uncertainty, and change—challenges that are present at the early life cycle stages and a life cycle extension. Component teams help you reduce cost and increase profitability by maximising reuse and ensuring architecture integrity. This is desirable for mature and declining products, where you typically focus on incremental enhancements and bug fixes, and cost reduction. Consequently, it can be beneficial to change the team setup after a product has... - Published: 2020-06-01 - Modified: 2025-09-19 - URL: https://www.romanpichler.com/blog/stakeholder-management-tips-for-product-people/ - Categories: Product Leadership, Stakeholder Management - Tags: stakeholders, teamwork, trust As product people, we rely on the stakeholders to successfully progress our product. But effective stakeholder management can be challenging. It can feel like herding cats with every stakeholder going off in a different direction, pursuing their individual goal. This article offers practical tips to help you succeed in aligning the stakeholders, involving them in the right way, and securing their support for important product decisions. Listen to this audio version of this article: document. createElement('audio'); https://episodes. castos. com/5e296c8fcbc2e2-83044581/Stakeholder-Management-Tips-for-Product-People-01-06-2020-10. 47. mp3 Lead the Stakeholders—Don’t Please, Don’t Dictate As the person in charge of the product, your aspiration should be to lead the stakeholders in order to create value together and achieve product success. In reality, however, some product people either aim to please the stakeholders by saying yes to their requests or by brokering compromises. Others do everything they can to make the stakeholders agree to their ideas and plans. But neither of these two approaches is desirable. The first one carries the risk of being a feature broker and offering a product that has a weak value proposition, gives rise to a poor user experience, and consists of a loose collection of features. The second approach fails to leverage the knowledge and expertise of the stakeholders. What’s more, it makes it unlikely that the stakeholders will fully support the product decisions and that they will follow them through. Effective stakeholder management starts by embracing the right attitude: See the stakeholders as equal partners; take an interest in their perspective, ideas, concerns, and underlying needs; build trustful connections with the individuals; and encourage the stakeholders to work together. But do not accept inappropriate behaviour and do not allow people to treat you like a project manager, team lead, or personal assistant. The following tips will help you with this. Focus on the Key Stakeholders A stakeholder is anyone who has a stake in your product, who is affected by it, or who shows an interest in the offering. While this definition includes users and customers, I use the term in this article to refer to the internal business stakeholders. For example, these stakeholders are likely to include representatives from marketing, sales, support, and finance for a commercial product. To focus your stakeholder management effort, identify your key stakeholders—those individuals with whom you want to establish a trustful connection and collaborate on a regular basis. This is particularly helpful when you are faced with a large group of stakeholders, which is not uncommon in bigger companies. A handy stakeholder analysis tool is the power-interest grid developed by Ackermann and Eden. As its name suggests, the grid analyses the stakeholders by taking into account their power and interest; it assumes that people take a low or high interest in your product and have low or high power. This results in four stakeholder groups: players, subjects, context setters, and crowd, as the picture below shows. The players are your key stakeholders: These are the individuals whose trust you should earn, who you should closely collaborate with, who you should involve in important product decisions. This avoids the risk that the stakeholder management work becomes overwhelming and consumes too much of your time. For guidance on how to interact with the other stakeholder groups, please see my article “Getting Stakeholder Engagement Right”. Build Trust As the person in charge of the product, you lack transactional power: You cannot tell the stakeholders what to do, you cannot assign tasks to the individuals, and you are typically not in a position to offer a bonus, pay raise, or other incentives. At the same time, you rely on their work and support to progress the product, for instance, to market and sell it. How can you then guide the individuals and ensure that everyone moves together in the same direction? The answer is by building trust. Here is why: As you lack transactional power, you must influence the stakeholders and encourage them to follow your lead. To do so, you have to earn the individuals’ trust. To put it differently, if the stakeholders don’t trust you, they won’t follow you and they won’t support your ideas and suggestions. The following techniques will help you with earning the stakeholders’ trust: Empathise: Take a warm-hearted interest in the stakeholders and try to understand their perspectives, ideas, concerns, interests, and needs—no matter how likeable and agreeable you find the individuals and their views. Practice active listening: Make an effort to attentively listen to the stakeholders and cultivate an open mind. Speak and act with integrity: Say what you believe is true, be willing to admit mistakes, and walk your own talk. Get to know people and, for example, have lunch or coffee together, be it in the same room or online. Involve people in product decisions but don’t make the mistake of trying to please them. Increase your product management expertise. Keep the Key Stakeholder Group... - Published: 2020-05-05 - Modified: 2024-01-22 - URL: https://www.romanpichler.com/blog/six-types-of-product-owners/ - Categories: Essential Articles, Product Roles - Tags: product manager, product owner, scrum, skills While the product owner role is not new—it emerged in Scrum in the second half of the 1990ies—there is still confusion about what it means to be a product owner. It’s not uncommon for me to meet someone who refers to themself as a product owner, only to discover that they own a product part but not the entire product. Other times, I meet someone who says they are a product owner. But it turns out that the person manages several products, an entire product portfolio. This article helps you reflect on and improve the way the product owner role is applied at your workplace. It describes six common types of “product” owners. It shows how the roles differ and relate to each other, and it explains how you can effectively apply them. Listen to this article: Overview The term product owner is commonly used to refer to six different product roles in my experience. These are: The original Scrum product owner who owns a product in its entirety and is responsible for maximising the value it creates. A feature owner who manages a major capability with which end users interact like search and navigation on an online retailer’s website. A component owner who owns an architecture building block like the persistence layer. A platform owner who manages a platform as a collection of shared software assets. The SAFe product owner who owns the product details. A portfolio owner who manages a group of (related) products. Each of the roles above is a product management role; anybody playing one of the roles takes on product ownership; and each role can be exciting and rewarding. None is per se better or worse. But as indicated, the ownership scope significantly differs and with it, the empowerment and skills required to succeed. The following picture provides an overview of the six roles, which I describe in more detail in the sections below. Note that some of the roles above can be combined. For example, you could be a product and a feature owner on a larger product, or you could be a portfolio owner and at the same time, manage one of the products in the portfolio, assuming that this neither leads to biased product decisions nor sacrifices sustainable pace. Scrum Product Owner As its name suggests, a product owner in Scrum is in charge of a product. Note that the choice of the name is intentional. The role is not called product administrator, feature broker, product backlog manager, user story writer, or project manager—even though that’s sometimes how it is interpreted. It is also not called "product manager" primarily to indicate the level of empowerment and respect product owners require to succeed in their jobs. But you can think of the product owner as an agile product manager, as I explain in the following video. https://youtu. be/dagL0eO7AkA If the product owner owns a product and is responsible for maximising its value, then it is important to understand what a product is. I regard a (digital) product as an asset that creates value for a group of users and for the business. For example, I am writing this article using Microsoft Word. When I need to take a break from writing, I save the document. Word is the product. But the ability to save the document is a feature, a part of the overall product. If someone is referred to as product owner, then the individual should own the product in its entirety—like Word in the example—and not just a product part—such as the ability to save a document. Referring to people as product owners who do not manage a product and do not exercise the right ownership is wrong in my mind: It creates confusion and it sets wrong expectations: Someone who owns a product part cannot take on the responsibility of maximising the product’s value and achieving product success. Additionally, the individual does not need the corresponding decision-making authority and does not require the same skills. A product like Microsoft Word is, of course, likely to be too big to be managed by a single individual: It requires several product people to collaborate. But even in this case, I would suggest that there should only be one product owner. The other product people involved should have roles whose names correctly reflect their scope of ownership, as I discuss below. Feature Owner and Component Owner A feature owner is an individual who owns a capability end users can interact with, for example, the ability to persist a Word document or to edit it. A component owner owns an architecture building block like a user-interface layer or a payment service. Component owners typically require in-depth technical skills. For example, the owner of a persistence service has to be able to describe its interfaces or APIs and converse with the users—the development team members who use the service. Feature and component owners are responsible for maximising the value their features and components create while ensuring that this does not compromise the product’s overall value creation. This includes describing their functionality, interacting with development teams, participating in product strategy work, and helping evaluate feedback and data. I regard feature and component owners as members of a product owner team, a group of product people who collaboratively manage a... - Published: 2020-04-01 - Modified: 2026-05-21 - URL: https://www.romanpichler.com/blog/dealing-with-difficult-emotions/ - Categories: Product Leadership - Tags: mental health, self-leadership, trust As product people, we make tough decisions and sometimes, we have to work with challenging people. It is therefore no surprise that we experience difficult emotions at work. While feelings like irritation, tension, and anger are unpleasant, learning to constructively deal with them is an important skill: It increases our mental wellbeing, builds trust, strengthens connections, and improves our ability to make effective decisions. This article helps you deal with difficult emotions at work. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/Dealing-with-Difficult-Emotions-in-Product-Management-01-04-2020-08. 17. mp3 Why Difficult Emotions Matter Particularly for Product People We may not like difficult emotions like confusion, frustration, anger, envy, sadness, and worry, but we all experience them. This is especially true at the time of writing this article, with the Coronavirus pandemic causing many people to be concerned about their health and jobs and the well-being of family members and friends. For us product people, however, difficult emotions are particularily relevant. Here is why: We routinely interact with individuals who have different perspectives, interest, and needs, such as users, customers, stakeholders, development team members. Users don’t always have the same wants and needs as customers, and the ideas of the stakeholders and dev team may diverge. This can lead to friction and conflict, which gives rise to difficult emotions. We are responsible for their success of our products. While I really appreciate this entrepreneurial aspect of our work, it can bring up tension, stress, and frustration when we are trying to progress our products towards agreed goals but are in danger of missing them, be it a sprint goal, product goal on the roadmap, or a strategic user or business goal. We have a rich and creative but equally challenging and multi-faceted job. It ranges from carrying out product strategizing work to managing the product backlog; from talking to users to meeting with marketing and answering questions from the support team—to name just a few examples. Having to attend to so many different tasks can be challenging: It can create difficult feelings like restless and irritation. Negative emotions, however, are not only unpleasant. They influence how we perceive reality and how we communicate. When you feel hurt or grumpy, for instance, your thoughts are likely to show a negative discolouration, and you might interpret what others say as criticism rather than take it as their observation. This can lead to misunderstandings and damaged connections, as well as wrong analysis of feedback and data and wrong product decisions. To put it differently, learning to skilfully deal with difficult emotions increases our mental wellbeing, strengthens our connections with stakeholders and development team members, and improves our ability as product people to make effective decisions. A big shout out to Marc Abraham who, according to my knowledge, was the first person to bring attention to challenging feelings like frustration in product management. Becoming Aware of Difficult Emotions To constructively deal with difficult feelings, we must become aware of them and learn to acknowledge them. This might seem trivial, but it is a crucial step that can be hard to take. There are three reasons why this can be the case: Self-view: If you firmly think of yourself as a gentle, kind person, then you might find it difficult to accept that at times, you too can feel emotions like anger, ill-will, and envy. Mental State: If you are very busy, rushing from one task to the next, then noticing difficult feelings will be harder. In fact, you might not become aware of them until they have grown so big that they can’t go unnoticed any longer. Work Environment: If you work in a male-dominated environment, then tuning into your feelings may not feature very high on your agenda, especially if you are male. The male-dominated workplaces I have experienced were largely characterised by ignoring difficult emotions, rather than acknowledging them. But ignoring and suppressing unpleasant feelings won’t make them go away—trust me, I’ve tried this more than once. Instead, it will affect your mental well-being and impact your ability to make the right decisions. In the worst case, an emotion will eventually grow so big and powerful that it overwhelms you and that it causes you to act it out, thereby possibly saying or doing something you will later regret. Therefore, bring awareness to how you are feeling, and allow difficult emotions to be present. One way to do this is to spend a few minutes going through the following sets of questions, which are adapted from Jay Oren Sofer’s book Say What You Mean: How are you? Are you feeling irritation, worry, or anger? If that’s the case, where do you experience the feeling in your body, for example, in your belly, shoulders, hands, or face? What does it feel like? Is there pressure, tightness, aching, heaviness? Don’t rush through the questions above. Take your time to answer them. Be aware that sometimes several feelings are present that can be initially hard to... - Published: 2020-03-11 - Modified: 2024-12-06 - URL: https://www.romanpichler.com/blog/overcoming-six-key-product-leadership-challenges/ - Categories: Product Leadership - Tags: Scrum Master, stakeholders, sustainable pace, teamwork, trust Products are developed, provided, and enhanced by people, and effectively leading them is crucial to achieve product success. But leading stakeholders and development teams is hard: It requires product managers and product owners to overcome six leadership challenges that range from lacking transactional power to guiding self-organising teams. This article—which is based on my new book “How to Lead in Product Management”—discusses the six challenges and offers practical tips for overcoming them. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/How-to-Overcome-Six-Product-Leadership-Challenges-11-03-2020-08. 34. mp3 No Transactional Power Unlike a line manager, you usually don’t manage the development team and stakeholders as the person in charge of the product, and the individuals don’t report to you. You consequently don’t have any transactional power: You cannot tell people what to do; you cannot assign tasks to them; and you are typically not in a position to offer a bonus, pay raise, or other incentives. In other words, you are not their boss. At the same time, you depend on the individuals. You rely on them to design, implement, market, sell, and support the product. Additionally, some of the people you lead might be more senior than you. They might have worked longer for the company, and they might be very influential and well connected. In order to overcome this challenge, build trust with the stakeholders and development team members. The following tips will help you with this: Empathise with the individuals and make an effort to understand their perspectives, needs, and interest, for example, by practicing active listening. Speak and act with integrity: Say what is true and make your actions match your words. Show people that you value their ideas and concerns and involve them in product decisions. Get to know people and allow them to get to know you. Strengthen your expertise. The more knowledgeable you are, the more likely it is that people will trust and follow you. Leading a Large and Heterogeneous Group The second challenge you face is leading can be comparatively large and heterogeneous group: Together, the development team and stakeholders are often more than nine people—the maximum number of individuals line managers are commonly recommended to lead. What’s more, the dev team is cross-functional and may include UX and UI designers, developers, and testers, alongside other roles. The stakeholders come from different business units, for example, marketing, sales, support, and service for a commercial product. As people have different backgrounds, they are likely to have different perspectives and needs. While this can be a source of creativity and innovation, it can also give rise to arguments and conflicts. In order to succeed in leading such a group, I recommend that you keep the stakeholders and development team stable. Why? First, it takes a while for a group of people to get to know each other, build trust, and be able to effectively collaborate. Second, every time a team changes, the team performance tends to dip: The new members have to get up to speed, new connections have to be made, and new friendships have to be built. Additionally, increase your ability to constructively deal with disagreements and learn to resolve conflicts so that nobody is left feeling frustrated or hurt. Finally, agree on shared goals or outcomes. Use them to establish a shared purpose, to direct and align people, and to give the individuals the autonomy they need to do their piece of work—be it creating a marketing strategy or designing and building a product increment. Limited Influence on Group Selection While you might know who would be best suited to work as a stakeholder or team member, you are typically not in a position to hand-pick people. Instead, line management staffs the development team and selects representatives from the business units as stakeholders—no matter how likeable you find the individuals and how well you get on with them. To maximise the chances of finding the right people, team up with the Scrum Master and engage with line management and your sponsor. A great technique to acquire the right people is self-selection: Clearly communicate the roles you need to fill and the skills people will require. Then let the individuals decide if they want to be on the team or not. To effectively lead people who you may find difficult or unlikeable, strengthen your capacity to empathise. Come from a place of curiosity and care, as Oren Jay Sofer recommends, and cultivate an open mind. At the same time, do not accept inappropriate behaviour—clearly tell people in a kind, empathic way when their speech or actions are harmful. Dual Role While guiding people can be challenging on its own, you also have to actively contribute to getting the product out of the door. The latter includes carrying out product strategy work, updating the product roadmap, and prioritising the product backlog. You therefore play a dual role: You are leader and contributor. This sets you apart from a line manager and... - Published: 2020-02-11 - Modified: 2024-01-22 - URL: https://www.romanpichler.com/blog/leveraging-software-platforms/ - Categories: Product Vision and Strategy - Tags: product owner, user experience, user interface design Software platforms can be powerful tools to grow a product portfolio and create new revenue streams. But successfully using them can be tricky. This article shares my tips to help you take advantage of your platform. Listen to this article: https://episodes. castos. com/5e296c8fcbc2e2-83044581/Leveraging-Software-Platforms-10-02-2020-12. 20. mp3 Be Clear on What a Software Platform Is Different people have suggested different definitions for the term software platform. Let me briefly share mine: I view such a platform as a collection of software assets that are used by several products, as the following picture illustrates. In the picture above, product A, B, and C are built on the platform and use its assets. To put it differently, the platform serves three different products. Let's look at two examples of successful software platforms, syngo and Amazon Web Services (AWS). The former is a platform that standardises how medical images are read, stored, and shared across MRI and CT scanners and other Siemens Healthcare products; the latter offers cloud-based services on which other products can be built, for instance, Netflix’s video streaming. In both cases, a range of products take advantage of the services the platform offers. Understand the Benefits and Drawbacks of a Software Platform Platforms offer several benefits: They can help grow a product portfolio faster and cheaper and they can help increase revenue. Take a portfolio like Microsoft Office, for example. If the teams developing the different apps all created their own user-interface layers, there would be considerable code duplication, added development costs, and increased development time. A software platform that standardises the user interaction and offers additional shared services, like saving and opening files, avoids these issues and allows the app development teams to focus on creating the app-specific functionality, rather than having to develop infrastructure code. What’s more, opening up a platform to other companies, as, for instance, Amazon did with Amazon Marketplace, can create a new revenue source and help diversify the business. In Amazon’s case, the platform enables other vendors to sell products alongside Amazon's offerings and Amazon collects a fee for each third-party sale. But platforms also have potential drawbacks. I have seen software platforms grow so big over time that they became bottlenecks and slowed down the rate at which the end-user-facing products could offer new and enhanced features. I have also witnessed a brand-new platform being retired, as it did not meet the needs of the users—the development teams who should have used it to build their products. As these examples show, it is worthwhile to carefully consider if a platform can benefit your business and to choose the right approach to build and manage it and to choose the right approach in order to build and manage it. Treat the Platform as a Product While a software platform is a piece of technology, it creates value for the product development teams by making it easier and faster to build their products and it generates value for the business by reducing cost, accelerating development, and possibly increasing revenue. Consequently, a platform should be managed as a While a software platform is a piece of technology, it is still beneficial in my experience to treat it as a product. Consequently, a platform should have its own product strategy and roadmap, KPIs, product backlog, and well-designed software architecture that leverages the right technologies. Make sure, though, that the platform decisions are guided by the needs of the products it serves. After all, a platform exists to help teams build better products faster and cheaper. In other words, the platform strategy and roadmap should be derived from the strategies and roadmaps of the products that are built on it, and its architecture should be designed to make it as easy as possible to use its services. A software platform, therefore, is more than a set of APIs. It typically requires documentation that shows how the platform assets can be used. It may also require tools that allow teams to code against its APIs. AWS, for instance, comes with a cloud development kit that supports . NET and Java, integrates with different IDEs, and hence supports developers to develop AWS-based applications at the time of writing. Assign a Platform Owner If we regard the platform as a product in its own right, then there should be clear ownership and an individual who manages the platform and ensures that it creates the desired value, as the following picture illustrates. As a software platform is a technical, supporting product, I recommend looking for a senior developer or software architect with a strong technical background who can talk to the members of the product development teams and understand their needs as well as empathise with the end users, depending... - Published: 2020-01-07 - Modified: 2025-07-14 - URL: https://www.romanpichler.com/blog/release-planning-advice/ - Categories: Product Roadmap - Tags: GO product roadmap, release burndown, scrum, teamwork Release planning is an important task for product people working with agile teams: It ensures that the product is moving in the right direction and it connects strategy and tactics. Despite its importance, release planning is not always effectively practiced in my experience. This article shares my advice to help you reflect on your release planning practices and improve them. What Release Planning Entails and Why It Matters While release and release planning are common terms, I find that different individuals attribute different meanings to them. I regard a release as a version of a product, for example, Mac OS X Catalina and Windows 10. Releases come in two flavours: major releases, like iOS 13, and minor releases, such as iOS 13. 3. Release planning is the process of determining the desired outcome of one or more major releases and maximising the chances of achieving it. This involves the following: Establishing clear, specific, and measurable goals. that describe the outcomes or benefits your product should create. I call these goals product goals (and sometimes release goal). I like to capture them on a product roadmap. Determining the work to be done. This typically involves the development team providing rough, high-level estimates. Understanding date and budget constraints: Are there any hard deadlines that must be met, or is the budget fixed? Monitoring progress from sprint to sprint and making adjustments as required. In Scrum, release planning is carried out iteratively, often at the end of a sprint when it's clear how much the progress was made. Release planning enables organisations to make informed investment decisions; it sets expectations, aligns stakeholders and development teams; and it allows product people to guide the work of the dev team. It is therefore in your best interest—as the person in charge of the product—to make sure that release planning is effectively carried out. This requires you to actively engage in the work, rather than delegating it to the development team or Scrum Master. Use a Product Roadmap to Plan Multiple Releases Release planning takes place at two levels: across several product versions (major releases) and within a single one. The former can be nicely done with a product roadmap. My preference is to work with a goal-oriented roadmap, like my GO Product Roadmap shown below, that states the desired benefits or outcomes of each major release for the next 12 months. Sample goals include acquiring new users, increasing conversion, reducing cost, and removing technical debt to future proof the product. The goals on your product roadmap should tell a compelling story about the likely development of your product. They should describe the journey you want to take it on in order to create value for the users and the business, as I explain in more detail in the article “Product Roadmap Prioritisation”. Such a roadmap provides a continuity of purpose and ensure that individual releases build on each other thereby progressing and enhancing the product in a systematic way. What’s more, the roadmap goals help you focus the product backlog by limiting its content to items that are necessary to meet the next product goal. But don’t forget to regularly review the product roadmap—at least once every three months, as a rule of thumb. As you learn more about the development team’s ability to make progress and better understand how to best meet the user and business needs, you will need to update your roadmap. This ensures that the plan stays actionable and provides the necessary guidance to the stakeholders and dev team. Prioritise the Success Factors for Your Releases In an ideal world, the development team will deliver all the releases on the product roadmap on time and on budget. But in reality, unforeseen things do happen. The development progress may not be as fast as anticipated, for instance, or one of the technologies may not work as expected. To maximise the chances of success, I recommend that you prioritise goal, date, and budget for the releases captured on your product roadmap. One way to do this is to determine the impact of not (fully) meeting a goal, missing the desired release date, and exceeding the budget. Then fix the most important factor—the factor that would cause the biggest damage if you don’t adhere to and therefore has the biggest impact on the success of the product. Try to protect the second most important factor, the one that would create the second biggest damage. Finally, be flexible with the third one, the factor that has the least impact on the success of a major release. You might have noticed that I haven’t mentioned quality. There’s a reason for it: Quality should be fixed and not be compromised. Otherwise, responding to user feedback and changing market conditions and quickly adapting your product will be hard, if not impossible. Employ the Right Estimation Approaches Estimating the... - Published: 2019-12-03 - Modified: 2022-04-28 - URL: https://www.romanpichler.com/blog/tips-for-effective-product-strategy-reviews/ - Categories: Essential Articles, Product Vision and Strategy - Tags: product discovery, teamwork, validation The product strategy describes how you plan to achieve product success. It typically covers the product’s value proposition, market, stand-out features, and business goals. While a strategy is key to creating a winning product, it would be a mistake to blindly execute it and assume it will always stay valid. As your product develops and grows, and as the market and the technologies evolve, the product strategy has to change, too. You should therefore regularly review and adjust it. The following tips will help you with this. Hold Regular Product Strategy Reviews A product strategy, like any other plan, is subject to change. How changeable your strategy is, depends on your product’s life cycle stage. As long as your product hasn’t reached product-market fit, the strategy is usually volatile. Contrast this with a mature product, which tends to have a more stable product strategy. But as the strategy will change, I recommend that you review and adjust it at least once per quarter—as a rule of thumb. Consider increasing the frequency for products that face a significant amount of uncertainty and decrease it for mature and declining products. Make sure that you block the necessary time for product strategy reviews in your calendar. Don’t allow urgent issues, like a sales or support request, to cause you to neglect reviewing the product strategy. Strategy is about being proactive and seeing opportunities and threats early so you can carefully choose how to respond. If you neglect reviewing and adapting the product strategy, you might experience nasty surprises in the future, for example, a competitor might catch you off guard with a new killer feature. Use Collaborative Workshops to Review and Adapt the Strategy Collaborative workshops with the key stakeholders and development team members are a great way to jointly review and adjust the product strategy. For a commercial, revenue-generating product, the stakeholders might include a marketeer, sales rep, and member of the support group. Joint reviews offer the following benefits: Better decisions: They help you make better decisions by leveraging the collective knowledge and creativity of the stakeholders and development team. Additionally, they help you consider different viewpoints thereby reducing the risk of wrong and biased decisions. Improved alignment: They lead to a better understanding and stronger buy-in for any strategy changes. Increased commitment: They empower people and they increase their commitment and motivation to work on the product. As deciding together can be challenging at times, I recommend that you do two things: First, ask your Scrum Master to facilitate the workshop. The individual should help people embrace a collaborative mindset; encourage everyone to fully participate and prevent individuals from dominating; ensure that the group has chosen a clear decision rule and guide everyone through the decision-making process. Having a dedicated facilitator allows you to fully contribute to the workshop. What’s more, it will reduce the likelihood that the HIPPO—the highest paid person’s opinion—wins rather than deciding what’s best for the product and feasible for the dev team and stakeholders. Second, make sure that you actively listen to the workshop participants. Listen with an open mind and try to understand the individual’s underlying needs and interests. This will make people feel understood and it will increase their support of the strategy changes. Look at Four Key Factors In order to review the product strategy and assess its validity, take into account the following four factors: Performance: How your product doing based on its key performance indicators? Does the data show positive, flat, or negative trends? What conclusions can you draw from the analysis? What would make your product perform better? Trends: Are there any new technology, regulatory, or social developments that will affect your product? Do they offer an opportunity to innovate, add, remove, or enhance features, or create a brand-new product, for example, by unbundling a feature? Competition: Are your competitors launching new products or features? Are there new market entrants? Is your product still sufficiently differentiated? Company: Are there any significant changes in your company that affect the product strategy? For example, has the business strategy changed or have key people left? Have the Courage to Make Tough Decisions Once you’ve reviewed the product strategy, decide what to do. There are four main choices you have: No change: Leave the strategy as it is. The product strategy is still valid; the product is performing well; there are new trends, no significant competitor and company changes that you need to respond to. Small changes: Carry out small adjustments to improve product performance or respond to a change. This includes adapting the value proposition and target group, improving the product’s standout features, and changing the business goals. Big changes: Make a big strategy change. This includes pivoting the product, significantly changing the strategy or replacing it. A big strategy change is required when your product is not doing well, when you are facing a disruption in the market or competition, when the business strategy significantly changes. A bigger change may also be required to move from one life cycle stage to... - Published: 2019-10-08 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/product-roadmap-prioritisation/ - Categories: Product Roadmap - Tags: product discovery, product life cycle, stakeholders Getting the product roadmap prioritisation right is a common challenge. Which items should be addressed first? Which ones can be delayed? This article answers these questions and helps you effectively prioritise your product roadmap. Before You Start Prioritising ... Before you order the roadmap items, double-check that you have a validated product strategy in place. You should be able to confidently say why users would want to use your product and why it is worthwhile for your company to invest in it. In other words, you should have valid answers to the following questions: Which user problem will the product solve, or which benefit will it provide? How will it create value for the business? For example, will the product directly generate revenue, help market and sell another product or service, reduce cost, or develop the brand? If you haven’t nailed the answers, then do not continue the roadmapping effort. Instead, carry out the necessary product discovery and strategizing work. Otherwise, your roadmap may be built on false assumptions. Getting the prioritisation right will then be virtually impossible. Create a Compelling Narrative To prioritise the product roadmap, consider in which life cycle stage your product is. As long as it hasn’t reached maturity, a product has to constantly move forward: initially to get to launch, then to reach product-market fit, and finally to sustain growth. At these life cycle stages, your product roadmap should tell a convincing story about the likely development of your product; it should describe the journey you want to take it on in order to create the desired value for the users and business. To get the prioritisation right, take the following steps: Determine how you can meet the user and business goals stated in your product strategy. What is the best way to achieve them? How can you break them down into smaller, intermediate goals? Order the newly created goals so that each one is a logical progression, a further step towards the overall user and business goals, considering any dependencies between the goals. For a brand-new product, this might mean that you start with user acquisition followed by activation, retention, and finally revenue generation, depending on your product’s underlying business model. For a product in the growth stage, you might find that you first have to remove technical debt before you can enhance the user experience and increase conversion. If there are items that were on the product roadmap prior to the prioritisation, then check if they help you reach any of the newly created goals. If that's the case, then assign them to the appropriate objective. Otherwise, either discard the item or investigate if changing the goals to accommodate the items would be beneficial. A cost-benefit analysis might help you with this. Whatever you do, make sure that your roadmap tells a cohesive, meaningful story that clearly communicates how the product will create value. Determine the Cost of Delay Once your product has entered the maturity stage, you usually don’t want to take it on another big journey, unless you decide to extend its life cycle. Instead, you stay where you are, protect your product’s position, and maximise the return it generates. Consequently, there are often smaller, unconnected goals that need to be addressed, like sustaining engagement or preventing churn by offering incremental enhancements or bug fixes. But these objectives often lack clear connections, and they don’t form a logical sequence or narrative. Faced with such a challenge, I recommend using cost of delay to get the prioritisation right. To put it simple, ask yourself how big the loss or severe the disadvantage is likely to be when you delay each item. For example, if you are unsure whether you should first enhance the user experience to sustain engagement or fix bugs to prevent churn, then identify the impact of delaying each goal. Once you've determined the cost of postponing the items, address the one with the biggest cost of delay first, then the item with the second biggest cost, and so forth. This should give you the right prioritisation. Don’t Let Powerful Stakeholders Dictate the Prioritisation The two approaches described above assume that the user and business needs together with the product’s life cycle stage determine the prioritisation of your product roadmap—not the HIPPO, the highest paid person’s opinion. Don’t get me wrong: I am a big advocate collaborative product roadmapping. Do actively involve the key stakeholders and development team members, encourage people to share their ideas and concerns, attentively listen to them, and build shared agreement, as much as possible. But if you are faced with individuals requesting or even demanding that their interests must be first addressed, then do not simply give in. Don’t... - Published: 2019-09-03 - Modified: 2024-12-06 - URL: https://www.romanpichler.com/blog/empowering-development-teams/ - Categories: Product Leadership - Tags: self-organisation, teamwork An empowered development team owns its work, is authorised to make the right decisions, and is able to work independently. Empowered teams are happier, create better products, and allow you, the person in charge of the product, to spend more time on product discovery and strategy. This article shares five tips to help you empower your development teams. Show People that You Care Empowering development teams starts with taking a sincere interest in the individuals, attentively listening to their ideas and concerns, and empathising with them. This shows that you care and value people's perspective; it builds trust; and it gives the team members the confidence to step up and take ownership. If people don’t feel safe, they may shy away from accepting additional authority and only do what their job description requires. In the worst case, empowerment is seen as a trick to make development teams do more work and to blame them if things don’t go to plan. Create Autonomy through Shared Goals To help your team take ownership and work autonomously, establish shared goals. A good example are sprint goals: A sprint goal captures the desired outcome of a sprint and is agreed by product owner and development team. Having a sprint goal in place enables the team to decide what needs to be done and how the work is performed. In order to create shared goals, involve the team members in the decision-making process. Use collaborative decision-making techniques, such as deciding by consent, to secure people’s buy-in. Don’t try to persuade or pressurise teams to accept a goal. Otherwise, the members are unlikely to take ownership, and they may not care if the goal is met or not. At the same token, hold people accountable for meeting goals—assuming that they have agreed to them. Be grateful for people’s effort and goodwill and acknowledge the challenges the team may have encountered. But provide clear feedback and do not allow people to sidestep or ignore shared goals. Let the Team Own the Solution I commonly find that product people believe that they must precisely describe the product functionality and spoon-feed their development teams with detailed user stories. While this approach may be appropriate when a team does not sufficiently understand the user needs and lacks user story skills, it should not become a habit. Instead, you should help your development team grow, acquire the relevant knowledge, and let people take full ownership of the solution or, if that’s not possible, the product details. A great way to do this is to include the team members in product discovery and UX work and allow them to observe and interact with users. Additionally, involve the development team in the product backlog work and teach people how to formulate and refine user stories. This may increase your workload initially. But in the long run, it will reward you with a more autonomous and motivated team, and more time to take care of product strategy and discovery. While giving people ownership of the solution is important, it is not enough to empower a development team: If a team is held back by dependencies, working autonomously is impossible. You should therefore ensure that your development team owns the software it develops—be it an entire product or a product part like a feature or component—and that it has enough people with the right skills onboard. This might require adjusting the team setup, for example, moving from component to feature teams, as well as cross-skilling team members or adding new people to the team, for instance, hiring a new UX designer. Encourage Self-organisation An agile development team should take full ownership of their work. This includes planning and tracking the work and identifying impediments. But it also means learning to effectively collaborate, constructively deal with conflicts, and make joint decisions. While it’s the Scrum Master’s responsibility to support self-organisation, there are a number of things you can do: Ensure that you establish shared goals that clearly describe the desired outcome of a sprint, as discussed above. Do not interfere with the work of the team during the sprint. This includes not assigning tasks and criticising individuals, and not changing the sprint goal once it’s been agreed. Actively participate in the sprint retrospective. Offer constructive feedback, address issues and concerns, and help resolve them. Be aware that it takes time for a group of people to become a self-organising team and that the learning process may involve setbacks and mistakes. Newly formed development teams tend to find it hard, for example, to reliably meet their commitments. You may consequently have to be patient and allow the team to use the first few sprints to learn how much work they can be accomplish in a sprint. Give the Team the Opportunity to Learn and Develop Finally, encourage a growth mindset amongst the team members and... - Published: 2019-08-13 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/how-to-reduce-the-product-backlog-size/ - Categories: Product Backlog & User Stories - Tags: simplicity It's normal that a product backlog changes over time. But some backlogs grow too big and become overly long, detailed, and complex. Consequently, they are difficult to update, prioritise, and refine. The following five tips help you simplify such a backlog and reduce its size so you can manage with it more easily. Split the Product Backlog Faced with an overly long and detailed product backlog, investigate if it does describe one cohesive product. Over time, products can serve an increasingly heterogeneous market and provide a large number of different features, some of which may not be used by all users. If that’s the case for your product, then you can unbundle one or more features and release them as products in their own right, like Facebook did with Messenger in 2014. The company unbundled the messaging functionality originally included in its Facebook mobile app and made it available as a stand-alone product. Move the unbundled features to a separate backlog for the new product, and enjoy working with the original product backlog, which is now smaller. Limit the Product Backlog Scope Your second option is to limit the scope of your backlog. To do so, choose a clear, specific, and measurable product goal for the next two to six months, for example, acquire x number of new users or increase engagement by y%. Then use the goal to direct and focus your product backlog: Remove all backlog items that do not help meet this goal. While this approach may sound radical, it ensures that your product backlog is concise and focused. It avoids looking too far into the future, having speculative items on the backlog, and turning the product backlog into a wish list. To capture additional ideas of how to progress your product, use a goal-oriented or outcome-based product roadmap and focus the product backlog on the next goal or outcome on the roadmap. This way, the product roadmap complements the product backlog: The former is a longer term, strategic plan; the latter contains the product details and facilitates execution. Hide the Details Your third option is to structure the product backlog in order to make it more manageable thereby hiding detailed items. A simple way to do this is to group epics into themes, which represent coarse-grained features or user journey steps like registration or search and navigation. This allows you to work with the following structure: theme → epic → user story. While such a product backlog contains the same number of items, you can now access its contents more easily by using themes and epics to navigate to the corresponding user stories. Aggregate the Details Another option to reduce the product backlog size is to combine detailed items. This is achieved by replacing lower-priority, fine-grained items with a coarse-grained one, for example, substituting a number of user stories with a newly created epic. This can be particularly helpful when you inherit an overly long and detailed product backlog. In addition to reducing the product backlog size, aggregating the details creates an appropriately detailed product backlog. Such as backlog is easier to update and change, which is particularly helpful for young products and those experiencing a major change like a life cycle extension. Eliminate Zombie Items Most of us have probably done it: Adding items to the product backlog to please an important stakeholder even though we knew that we would not be able to implement them any time soon. Over time, they’ve turned into zombie items at the bottom of the product backlog, which aren’t dead or alive. If you’ve followed my earlier advice, you will have already removed those items. But if that’s not the case, then either make them high priority or delete them now. Your product backlog should only contain items that help create value for the users or business—not to appease individuals. In the future, make sure to decline items that are not helpful to execute the product strategy and meet specific product goals. Attentively listen to and empathise with a stakeholder who requests a feature. But be not afraid to say no once you’ve understood the person’s underlying needs and interests. - Published: 2019-07-09 - Modified: 2024-01-22 - URL: https://www.romanpichler.com/blog/tips-for-growing-a-product-management-team/ - Categories: Essential Articles, Product Leadership - Tags: scaling, teamwork Growth is something wonderful: It means that individuals, teams, and products prosper. Growing a product management team, however, throws up a number of challenges: How big should the team become? How fast should people be added? And how should the individuals work together? This articles discusses how you can address these challenges and it shares my recommendations for growing in an effective manner. Organise Around Products In order to grow your product management team, start by reviewing your product portfolio. Determine which assets are actual products—value creating vehicles that offer a tangible benefit or address a real problem for a group of people, while at the same time deliver specific business benefits, such as generating revenue directly or indirectly, reducing cost, or increasing brand equity. Once you’ve identified the products, determine the skills required to manage each asset. For example, an internal product like a platform is likely to require in-depth technical skills—unlike an end-user facing offering, which is likely to require a thorough understanding of the market and business model, for example. Then look for the right individual to lead and manage each product bearing in mind that the person should look after the asset over an extended period of time. This rewards long-term thinking and helps people see which impact their decisions have. Determine How Many People are Needed Once you have identified your products together with the skills required to manage them, find out how many product people you need. A common way to do this is to determine the number of development teams needed to progress each asset: If a product needs more than two to three teams, then it is usually too large for one person to manage in my experience. If that's the case for one of your products, consider adding more product people who take on specialised roles like feature owner (a. k. a. area product owner in LESS) and work with the person in charge of the overall product. Develop Shared Standards Before you add more people, make sure that sufficient shared standards are in place. Review the product management roles and responsibilities, processes, and tools that are currently used. Explore if they are helpful, consistent, and complete. For instance, do you have a shared understanding of how ideas are progressed to shippable products—be it new offerings or new features? Do common product discovery and strategy practices exist? And do you agree on what a product vision, strategy, roadmap, and backlog are, for example, and how these plans should be captured? Finally, review how the work of the product people is currently assessed. What are performance evaluations based on? And are they fair? For instance, you may want to tie the evaluations not only to the performance of the product an individual looks after; you may also want to consider the person's ability to effectively lead and collaborate with dev teams and stakeholders, as well as improve their work and acquire new skills. If important standards are missing, then develop them first and delay growing the team: Without effective standards, it will be difficult for a larger group of people to work together. Confusion, miscommunication, and other forms of waste are likely to materialise. This is not to say that any standard should be set in stone. The opposite is true: Standards exist to help people do great work in a healthy manner. If a standard can be improved, the people doing the work should be empowered to change it. Grow the Team Incrementally I've seen many organisations significantly increase the size of their product management group in one go. While there are always good reasons for this approach, it creates strain for the organisation and the individuals. The quick addition of new product people can be overwhelming and lead to a prolonged period of slow and inconsistent decision-making and low productivity. Instead of a big-bang approach, grow your product management group in a piecemeal fashion. This is best done by adding one or two people at a time, particularly when your team is still you. Growing incrementally allows you to understand if your hiring practices are effective, the standards you have in place work well, how much support the new product people need—both from the head of product as well as from the Scrum Master, and how easy or challenging it is to integrate the individuals into the team and foster effective collaboration. What's more, if you discover any issue, an incremental approach allows you make the necessary changes before you add more people. When it comes to recruiting the right people, I find that it is often beneficial to develop current employees to help them grow into a product role as well as hire experienced product people. Employees understand the company, its markets, and its products. External product people offer a fresh perspective and have a hopefully solid product management skill set. Make sure,... - Published: 2019-06-04 - Modified: 2023-12-20 - URL: https://www.romanpichler.com/blog/should-product-roadmaps-have-dates/ - Categories: Product Roadmap - Tags: budget, GO product roadmap, planning Whether product roadmaps should show dates is a controversial topic in product management. Some people passionately argue that dates should be banned from roadmaps. Others claim that they are useful. This article discusses the pros and cons of using dates on product roadmaps to help you decide which option is right for you. Product Roadmaps in a Nutshell To start with, let’s briefly recap what a product roadmap is. A roadmap is a high-level plan that states how a product is likely to evolve over the next six to 12 months. An effective, modern product roadmap focuses on the outcomes and benefits a product should provide. In other words, it is outcome-based and goal-oriented. This differs from a traditional approach, which maps features onto a timeline. For more advice on working with outcome-based product roadmaps, watch the following video. https://youtu. be/Op8VTfhPQfM Why Dates on Roadmaps Are Beneficial Stating dates and specific time frames on a product roadmap can be helpful for two main reasons: They allow you to state deadlines and check if your plan is realistic and actionable. Capture Deadlines Some products must obey deadlines or a specific window of opportunity to achieve success. Take, for example, seasonal products like games and smartphones, whose main sales tend to take place before Christmas. Having the products ready on time is essential, as a delay would have a significant revenue impact. But even non-seasonal products can be subject to deadlines. For instance, in the case of imaging healthcare devices, a working prototype usually has to be available at the RSNA’s annual meeting to announce and then be able to launch the product, as far as I know. Similarly, I've experienced hard deadlines for internal, supporting products like a supply line management application that had to be released at a specific date to achieve the desired benefits. Sometimes it even makes sense to employ a release train and timebox major product releases, for example, to coordinate different products or regularly offer improvements to the users. Ensure the Roadmap is Realistic Even if your product is not affected by any deadline, it may be helpful to consider dates or time frames when developing a product roadmap, as this allows you to understand if the plan is realistic. A handy tool for this job is the Iron Triangle shown below. The version of the triangle depicted above takes into account goal attainment, date or time frame, and budget. Quality as the fourth factor that influences product success is placed in the middle to indicate that it should be fixed. Please note that one of the triangle’s vertices must always stay flexible and act as a release valve to account for unforeseen events, also known as Sod’s Law. To decide which vertices can be flexed, perform an informal impact analysis. Ask yourself if it would it be better to: Stick to the goal but take more time to reach it or increase the budget by adding more people (if that’s helpful and possible)? Or should you adjust the goal to make it less ambitious but adhere to the date or time frame and the budget? Considering these questions makes it more likely to create a product roadmap that can be actioned and it sets the expectations of the stakeholders. (For more information on the Iron Triangle and how you can determine dates and budget, please refer to my book Strategize. ) Why Dates on Roadmaps Are Not Helpful Using dates on product roadmaps can create unrealistic expectations and expect teams to commit for unacceptably long timeframes: Users, customers, and sales people may regard target dates as a firm promise or commitment and insist that these are adhered to—no matter how fast the development progress is. This can create a significant amount of pressure for the person in charge of the product and the development team; it can result in an unhealthy work environment and unsustainable pace where teams work long hours or product quality is compromised. In the worst case, a severely compromised product is shipped, a product that doesn’t properly address the user needs and is full of bugs making it expensive and difficult to enhance and adapt it. Now What? Dates on a product roadmap are neither good nor bad per se. As with many other things, it depends on how you use them and the context you are in. Whenever you work with an external, customer-facing product roadmap, I recommend not showing any specific dates. Instead, use timeframes that are big enough, so you don’t experience a death-march situation as described above. For example, you might want to choose six-months timeframes, or even more coarse-grained, annual ones like “this year” and “next year”. But when you work with an internal product roadmap that aligns development team and stakeholders, I would encourage you to consider stating... - Published: 2019-05-01 - Modified: 2022-08-16 - URL: https://www.romanpichler.com/blog/product-ethics/ - Categories: Product Leadership, Product Vision and Strategy - Tags: product manager, product owner Digital products can have a significant impact on the users--from saving lives to exposing people to harmful content, encouraging unhealthy habits, and contributing to climate change. It is therefore important that we take responsibility for the ramifications of our products and make ethically sound product decisions. This article offers five guidelines to put product ethics in practice and create products that truly benefit their users. What is an Ethical Product? An ethical product is an offering that does not cause any harm, neither to its users nor the planet. The former includes negatively impacting the people’s mental wellbeing, for example, by encouraging addictive behaviour or promoting harmful information. The latter comprises contributing to climate change by developing and providing the product. As product people, it’s our job to ensure that our products are kind—that they are ethical and do not cause any harm. The following guidelines help you with this. Intentions We all have to earn a living and every business needs to find ways to monetise its product, be it by generating revenue directly or indirectly, increasing brand equity, reducing cost, or other means. What’s more, earning money with software is not easy. Many users expect that digital products are free or cost next to nothing. But as product people, we should first and foremost want to enrich people’s lives by offering products that truly benefit them—rather than being driven by the desire to advance our careers, reap financial rewards, or receive praise. If we don’t put the users first, we are in danger of getting the balance wrong between enriching people’s lives and generating value for the business. In the worst case, we end up adopting practices that benefit the company and ourselves but are harmful for the users. This includes getting people hooked and encouraging them to spend as much time as possible using the product. Engagement then becomes a euphemism for addiction. Putting users first also makes sense from a business perspective in my mind: It is hard to build a great brand and sustainable business when a product has a negative impact on the users’ lives. Therefore, reflect on your motivation. Cultivate the intention of wanting to help people, to offer products that truly benefit them. Mental Wellbeing Sometimes, we take a rather superficial look at the user needs and forget to investigate how using our product can affect their mental wellbeing. Is it right to offer a product that harms the users’ mental health even if people would want to use it? For example, as helpful as an individual notification from a social media app might be, is it appropriate to constantly alert and disrupt the users, and risk to increase their restlessness and stress levels whilst reducing their attention span? Or is it acceptable to enable the distribution of content that receives plenty of views and comments but contains material that promotes self-harm, violence, or hatred? Personally, I don’t think so. It is our responsibility as product people to care for the users’ mental wellbeing and mitigate the impact our product has on it. This does not require a degree in psychology. Taking a real interest in the users and cultivating a warm-hearted attitude towards them is usually enough. To do so, make an effort to regularly meet users, observe how people interact with your product, and listen to any ideas and concerns they might have. This helps you empathise with the individuals and at the same time, discover opportunities for enhancing your product. Business Model Products are value-creating vehicles: They exist to generate benefits for the users and business. When digital products are offered for free, monetisation typically takes place in form of exposing users to ads and selling their data. But this only works if enough people sufficiently engage with the product. For example, while I have disabled most of the notifications on my Facebook account, I still regularly receive emails that encourage me to use the app, for example, by telling me “A lot has happened on Facebook since you last logged in. Here are some notifications you've missed from your friends. ” While every company has to generate revenue in order to pay for developing and hosting a free digital product, encouraging addictive behaviour or selling user data, without the individual being fully aware of it, is not justifiable in my opinion—the risk of negatively impacting users’ lives is simply too high. The solution, in my mind, is to change the underlying business model and move away from monetising digital products through ads and data sales. Consider, for example, what has happened in online media in recent years: More and more people are willing to pay for online content, for reading articles online and listening to music via streaming services like Spotify. What’s more, if a product has a compelling value proposition, then you are usually able to monetise it without offering it (entirely)... - Published: 2019-04-02 - Modified: 2023-02-06 - URL: https://www.romanpichler.com/blog/10-scaling-tips-for-product-people/ - Categories: Product Management Process - Tags: product manager, product owner, scaling, user feedback, user interface design Managing a growing product can be as rewarding as challenging: Involving more people and teams and scaling up is hardly ever easy. This article shares 10 practical tips to help you effectively scale as the person in charge of a product. 1 Involve the Right People A small group of qualified individuals who have the right skills and motivation can be more productive than many individuals who lack the necessary expertise and act out of obligation. This is true for product people and development team members alike in my experience. Therefore, make an effort to involve the right individuals. This will allow you to move faster, stay small for longer, and be more adaptive. While this probably sounds like common sense, I've seen more than one organisation trying to get more done by throwing people at a product. One company I worked with, for example, assigned developers who had worked on enterprise systems using an ancient programming language to develop a brand-new, embedded product with the latest technologies. No wonder that the individuals struggled and the product suffered. Your Scrum Master should be able to help you find the right people and address any impediments that might prevent you from doing so—for example, being assigned individuals without considering their skills and motivation. 2 Don’t Scale Prematurely I once worked on a new product development effort where more than one hundred developers in three locations had been allocated right from the start of the project. While initially, there wasn’t enough work to keep so many people busy, the development teams didn’t want to twiddle their thumbs and started writing software. This led to a bloated, over-complicated code base and a product that was difficult to adapt and expensive to maintain. Rather than scaling prematurely, stay as small as you possibly can until you are getting close to reaching product-market fit. This allows you to quickly respond to market feedback, experiment with new ideas, and make any architecture and technology changes that may be required in order to move into the growth stage. 3 Build an MVP Another great way to reduce the need to scale is launching a minimum viable product (MVP). Such a product typically requires less time and fewer people to develop than a more ambitious, feature-rich one. What’s more, it can be easier adapted to the market response in order to achieve product-market fit. How minimal your product can be depends on its market. For example, in the case of the original iPhone, Apple created a new market and could therefore offer a comparatively minimalistic product. Contrast this with the Apple Watch, which entered an existing market and directly competed with established offerings from companies like Samsung, Garmin, and Fitbit. 4 Help the Development Team Become Self-sufficient As your product grows, your workload usually increases too: Addressing a growing number of users requires more effort to understand their often heterogeneous needs and decide how to best address them. If you have a development team that still needs to be spoon-fed with detailed requirements at this stage, then your workload is likely to become overwhelming. To mitigate this risk, help the development team learn about the users and understand their needs as early as possible, for instance, by involving team members in user research (as part of the product discovery work) and exposing them to direct user feedback on early product increments. This will allow the team members to own the solution and make the right UX and technology decisions, increase people’s motivation, lay the foundations for adding more teams, and free you from having to create detail-rich user stories and still answer lots of questions during the sprint. 5 Grow Organically Back in 1968, Melvin Conway observed “that there is a very close relationship between the structure of a system and the structure of the organization which designed it. ” This means that if you start with, say, three development teams, the software architecture of your product will probably consist of three major subsystems—no matter if this architecture supports the desired user experience and features. To avoid this risk, start with one product person in charge of the product, one development team, and one Scrum Master. Once you’ve validated key UX and technology risks, scale by asking the team to split up. Then add more people to the newly formed teams. This approach is also called growing organically, as it mimics cell division in living beings. In addition to escaping Conway’s Law stated above, growing organically offers two more benefits: It evenly spreads the effort of bringing the new people up to speed instead of having one unproductive development team with all the newbies, and it allows you to measure the impact of adding more people on productivity and... - Published: 2019-03-04 - Modified: 2024-01-22 - URL: https://www.romanpichler.com/blog/strategy-map/ - Categories: Product Vision and Strategy - Tags: product discovery Without an effective strategy, it’s hard to achieve product success. But what does strategy entail? And which tools are best suited for making strategic decisions? This article offers my answers and introduces a strategy map--a guide to the strategic decisions required to make and keep products successful. Maps are the Foundations on which Adventures are Built When I was a little boy, I truly loved all things pirate. Even as an adult, I very much enjoyed reading pirate books with my children. One of them even came with a separate little map that could be unfolded to discover a hidden treasure. Coming up with a set of tools to capture important strategic decisions reminded me of treasure maps: It should guide you to product success, bearing in mind that not all treasure is silver and gold, as Captain Jack Sparrow put it. The map below shows the strategy tools I find helpful to make effective product strategy decisions. Please click on the image to enlarge it. As the Strategy Map above shows, you should be aware of the overall business and product portfolio strategy in order to make the right strategic product decisions, as these provide the necessary context. To put it differently, if you don’t know the business strategy and portfolio strategy, or if these plans don’t exist, then it will be hard for you to get the product strategy right and choose, for example, the right market and target group. Additionally, you should be able to correctly state the information captured by the product vision and strategy, product roadmap, KPIs, and business model on the map above. Please note that you should derive the KPIs from the value proposition and business goals so that they help you understand how much value the product is creating for the users and the business. The Strategy Map can help you check if you have any strategy blind spots. I find that some product people forget about the business strategy and the business model; others aren't aware of the portfolio strategy, for instance. If that's the case for you, then explore what it would take to fill the gaps and acquire the relevant information. This might simply involve talking to the right people like the head of product or the CEO. But it might also mean carrying out the necessary strategizing work, for example, when you lack a validated product strategy or an effective business model. Tools of the Trade Navigating the seas and reaching a treasure island was no easy feat for pirates who had to rely on tools like compass, sextants, and nautical charts. Once on the island, the treasure map, a compass, and digging tools would be crucial to find and unearth the treasure. Similarly, there are a number of specific tools and templates that can be helpful to capture the information shown on the Strategy Map above. Here are my favourites: Roger Martin’s business strategy approach for business strategy decisions; Product Portfolio Matrix and Innovation-Ambition Matrix for managing product portfolios; Portfolio Vision Board to describe the product portfolio strategy; Product Vision Board to capture product vision and strategy; GO Product Roadmap to describe the product roadmap; Alexander Osterwalder’s Business Model Canvas to state the business model as a stand-alone artefact to complement the product strategy or the Extended Product Vision Board to capture the relevant business model elements together with the product strategy and vision. Balanced KPIs (possibly using Dave McClure's pirate metrics). Please note, though, that product strategy is not about filling out templates and ticking boxes—but asking the right questions and being able to correctly answer them. Carrying out strategy work really is like going on an adventure: You have to be curious and receptive, cultivate a playful mindset, and be willing to discover and learn new things. Therefore choose the templates and tools that resonate most with you and that are helpful in your specific context. The Map is Not the Territory While I hope that you find the Strategy Map above helpful, don’t blindly follow it. Instead, consider if you should adjust it or create your own map for your very own product adventure. For example, you don’t need a portfolio strategy if your business only has one product, which is typically the case for early-stage start-ups. Similarly, you may disagree with my product-centric take on the business model and want to link it to the business strategy, which is totally fine. And if you work for a portfolio company like GE or Siemens that is essentially a holding of several independent or loosely coupled businesses, you may find that you need to add a corporate-level strategy that sits above the business strategy, as the latter will be focused on your individual business or business group. Additionally, consider reflecting on your... - Published: 2019-02-04 - Modified: 2026-05-21 - URL: https://www.romanpichler.com/blog/listen-to-understand-listening-practices-for-product-people/ - Categories: Product Leadership - Tags: empathy, mindfulness, product manager, product owner, teamwork Listening to users, customers, stakeholders, and development team members is crucial for us as product people. It allows us to build rapport, generate new insights, and make effective decisions. But listening deeply can be hard, especially when we are tired, distracted, or stressed. This article shares 12 techniques to help you improve your listening habits and become even better at understanding others. Listen to Understand, not to Answer “Most people do not listen with the intent to understand; they listen with the intent to reply,” wrote Steve Covey in his book The 7 Habits of Highly Effective People. It’s true: We often listen with a specific goal in mind, with the intention to reply, to share our perspective, or to convince the other person. As a consequence, we don’t pay full attention to what the other person is saying or filter what is being said; we only hear what supports our view. We obtain partial or selected pieces of information, which can cause us to draw the wrong conclusions and get the wrong end of the stick. To avoid these issues, start by taking a sincere interest in the individual and what the person has to say. Make a conscious effort to listen to understand, not to reply, correct, or criticise. Give the other Person Your Full Attention As the person in charge of the product, you are likely to have many duties that compete for your time and attention. It can therefore be tempting to glance at your phone or smart watch to see if an urgent message has arrived while listening to someone. But instead of multi-tasking, minimise any distractions, switch off your devices or close the appropriate applications, and give your full and undivided attention to the other person. Being attentive increases the chances that you receive all the information and take in everything the individual says. It also makes the speaker feel valued and respected. Consequently, the individual is likely to be more trustful and open with you. Listen for Facts, Feelings, and Needs When you communicate with people, you may find that you listen for the facts—what is being said. For example, the issues some users experience with the latest version of your product. While facts are undoubtedly important, you shouldn’t stop there. Listen also for what is not being said—the emotions and needs of the other person, as Andrea Cohen et al. recommend in their book Practicing the Art of Compassionate Listening. Feelings, such as excitement, enthusiasm, frustration, or sadness, tell you how a person is while speaking. They often manifest themselves in the individual’s body language. Raised voice and a red face are likely to indicate that the person is angry, for example. Needs are the underlying motives we have when we speak. They refer to our intentions and goals and describe why we say what we are saying. Therefore, don’t just take what someone says at face value. Consider how the person is feeling and why she or he is sharing the piece of information. What are the individual’s interests and concerns? What’s really going on here? If you are unsure or want to find out more, ask clarifying questions. Stay Intentionally Silent Many people, including myself, are uncomfortable with tolerating silence in conversations. I can be in a rush to conclude the conversation without being fully aware of it; or I might be enjoying it so much that I don’t want to stop. But silence is often necessary to encourage the other person to continue to talk and share something that might be uncomfortable or difficult. To create the necessary space, take three deep breaths or count to ten before you speak, giving the individual enough time to finish without feeling rushed. Additionally, being silent for a few seconds allows you to let what you have heard sink in and become aware of how you are before you answer. Listen with an Open Mind As the person in charge of the product, you may have strong views of what needs to be done to progress your product. While it’s great to have ideas and opinions, try to hold them lightly and make an effort to listen with an open mind. Don’t immediately judge and dismiss something you don’t like or agree with. Try to be receptive and appreciative of the other person’s perspective, even if you initially consider it to be wrong. Otherwise, it will be difficult to receive all the information and understand the individual’s needs and interests. You might even discover that some of your preconceived ideas were wrong or find alternatives that are even more appropriate. Pay Attention to the Individual’s Body Language Paying attention to non-verbal information—like voice pitch and volume, gestures, facial expressions, and eye movement—is important: It expresses the speaker’s feelings, and it helps you understand the individual’s interests. In fact, studies have found that over 60%... - Published: 2019-01-08 - Modified: 2023-11-09 - URL: https://www.romanpichler.com/blog/tips-for-rewriting-a-digital-product/ - Categories: Product Vision and Strategy - Tags: product discovery, product life cycle, software quality Rewriting an existing product is often a cost and technology-centric exercise that can feel like a joyless necessity. But instead of replacing like-for-like and providing a carbon-copy of the old product, you should see the rewriting effort as an opportunity to innovate, to create more value for the users and the business, as I explain in this article. See the Rewriting Effort as an Opportunity to Innovate A digital product is commonly redeveloped for two reasons: It has accumulated too much technical debt or its technologies are outdated, but the product is still needed—be it to generate revenue, support other revenue-generating products, or automate business processes and increase productivity. Consequently, rewriting efforts are often focused on replacing like-for-like: The users get the same product dressed up in new technologies. While this approach can works, it wastes the opportunity to innovate and create more value for the users and the business. Wouldn't it be great to make the product better, improve the user experience and add brand-new features? Take Microsoft Office as an example. The company enhanced its productivity suite in recent years by decluttering the user interface and adding new features like collaboration and Skype integration, not just by replacing existing code. First Things First But before you start compiling a product backlog with the new features the product should provide, take a step back and find out who actually uses your product, why people employ it, which user journeys they carry out, and which existing features they mainly use. This requires some user research and product strategy work, for example, observing users and conducting problem interviews, as well as analysing any analytics data you may have available. A great way to leverage the data you've collected and discover improvement opportunities is to create a consumption map. Such a map visualises the steps users take and any issues they encounter like waiting, delays, and errors, as I explain in more detail in my book Strategize. For revenue-generating products, you should also investigate if the product is still effectively differentiated: Do users have a compelling reason to choose it over competitors’ offerings? A great way to answer this question is to create a Strategy Canvas, as I describe in my article "Make Your Product Stand Out with the Strategy Canvas". Additionally, give the development team members the opportunity to carry out some technology exploration to ensure that the redeveloped product will be built in the right way. Would a microservices-based architecture or machine learning be beneficial, for example? Finally, capture your insights and describe the product’s current strategy: the people it serves, the value it creates for the users and business, and its key features, for instance, by using my Product Vision Board. If you find it hard to justify carrying out the necessary discovery work, then look at the inaction risk, the risk of not making the necessary changes and providing a carbon copy of your product: Which benefits would you lose, such as increasing user satisfaction by simplifying the product and saving maintenance cost by removing features? Then try to quantify these benefits and compare them to the discovery investment required. Explore Your Strategic Options Next, examine the options to move your product forward: Should you continue to provide one, cohesive offering? If so, can you remove some features or lean them out? It’s not uncommon in my experience that over time, features are added to a product in order to accommodate requests from powerful stakeholders—not necessarily because they benefit the majority of the users. These are prime candidates for removal. Additionally, consider if you can add or enhance features to make your product stand out, and if you can improve the user journeys, for example, by eliminating steps, improving touch points, and reducing delays. If, however, the user base has evolved into a larger, heterogenous group, consider creating different product variants to address the subgroups—think of Microsoft Visio Standard and Professional as examples for variants of the same product. Alternatively, you may want to unbundle one or more features into a new product, as Facebook did with Messenger in 2014 when the company released the messaging feature as a stand-alone app. Capture your decisions and document the new strategy for your product, for instance by creating a new, forward-looking Product Vision Board. Before you proceed, carefully investigate your board for any major risks and assumptions. If you find some, take the time to validate them. Otherwise you risk implementing an unvalidated and potentially incorrect strategy. Incrementally Replace the Product Chances are that the existing product has grown over many years. Replacing it in one go may require a significant amount of time and money and it carries the risk of discovering issues late in the process. Incrementally replacing your product, for example, by using bimonthly releases that progressively enhance the product, avoids these issues. What’s more, it allows... - Published: 2018-12-04 - Modified: 2023-05-02 - URL: https://www.romanpichler.com/blog/technical-debt-and-product-success/ - Categories: Product Management Process, Product Vision and Strategy - Tags: product life cycle, software quality, technology Similar to a company experiencing financial debt, products can incur “technical debt”: This happens when wrong or suboptimal architecture, technology, and coding decisions are taken. Consequently, the architecture may not be as loosely coupled as it should be, and the code may be messy rather than clean. This article explains why product people should care about technical debt and it offers strategies for addressing it. Why Technical Debt Matters for Product People As the person in charge of the product, you may not be terribly concerned about how clean and well-structured the code is. But the quality of your product matters: It directly impacts your ability to achieve strategic product goals and make your products successful: Technical debt makes it hard to experiment with new ideas, release new features, and quickly respond to user feedback. The messier the code and the less modular the architecture is, the longer it takes and the more expensive it is to change your product. In the worst case, you have to go through a rewriting exercise where some parts or even the entire product are being redeveloped. This is similar to financial debt: When the debt is not paid back, the interest payments can multiply and eventually cripple the business. Technical Debt and Your Product To understand if and to what extent your product is affected by technical debt, talk to the development team, for example, in the next sprint retrospective. I find that development team members usually have a good understanding where issues in the architecture and code are. Additionally, consider asking the team to collect data that shows how much technical debt there is, where it is located, and how bad it is, for example, by using code complexity, dependencies, duplication, and test coverage as indicators. There are a number of code analysis tools available that collect the appropriate data and show how adaptable the architecture and how clean the code is.   Once you understand the amount and severity of tech debt in your product, analyse its impact on meeting the product goals and achieving product success together with the development team. Take into account the cost of delay, the cost of not addressing the technical debt now but delaying it to a future point in time. Should you, for example, continue adding new features to the product for the next six months and plan in bigger technical improvement work afterwards? Or would it be better to address the worst debt now? Furthermore, consider the life cycle stage of your product. Technical debt is particularly bad for new and young products: If your product has a closely-coupled architecture with lots of dependencies, if it lacks (automated) tests and documentation, or if it is full of spaghetti code, then experimenting with new ideas and adapting the product to user feedback and new trends will be difficult and time-consuming. Similarly, if you want to extend its product life cycle, you may have to first remove (some of) the technical debt before you can make the necessary changes and add new features or create a variant. Having said that, it is a valid strategy to launch a minimum viable product (MVP) whose architecture, technology, and code has been intentionally compromised in order to reduce time to market—as long as the quality is good enough to adapt the product to feedback from the early market. But apply this strategy with caution: You will have to spend time addressing the technical debt incurred and putting your product on solid technical foundations. This should be done before reaching product-market fit, as you will otherwise struggle to scale up and keep your product growing. If, however, your product is in maturity—or even decline—and you do not intend to extend its life cycle but focus on maximising the business benefits it generates, you probably want to carry out as little debt removal work as possible. Options for Removing Technical Debt Once you’ve established how much tech debt there is and how soon it needs to be addressed, you face two choices: You can either make time for a focused effort and dedicate a period of time to removing the debt, or you can carry out the work in parallel to enhancing your product and adding new functionality. Whenever you face a significant amount of tech debt that constitutes a barrier to innovation, you should opt for a dedicated period to remove it. Apple did this with Mac OS X Snow Leopard, which was released in 2009 after nearly two years of work. While Snow Leopard didn’t provide any new functionality, it created the foundation for future releases by improving performance and reducing the memory footprint of the operating system, for example. I am not suggesting that you should necessarily spend a year or more refactoring your product, as Apple did. But it can be more effective to make a concentrated effort and invest a... - Published: 2018-11-06 - Modified: 2023-06-29 - URL: https://www.romanpichler.com/blog/sustainable-pace-product-management/ - Categories: Product Leadership, Product Management Process - Tags: product manager, product owner Working in product management is rewarding but demanding. As product people, we have a large set of diverse responsibilities, which often translates into a high workload. But continuously working too hard carries the risk of becoming chronically tired and stressed and sacrificing our health. This article discusses techniques that help you achieve a healthy, sustainable pace and avoid the danger of being constantly overworked. What is Sustainable Pace? Sustainable pace is an important agile principle. The Agile Manifesto defines it in the following way: “The sponsors, developers, and users should be able to maintain a constant pace indefinitely. ” The goal is to create a healthy work environment and avoid that people are routinely overworked, lose their creativity, make mistakes, and eventually sacrifice their health. A framework like Scrum offers specific techniques that ensure sustainable pace—unfortunately, only for development team members and not for product people. But sustainable pace is equally important for you, the person in charge of the product. You have a demanding job with a range of diverse responsibilities. These include interviewing users, working on the product roadmap, updating the product backlog, engaging with the stakeholders, and working with the development team, to name just a few. As all these duties compete for your time and attention, it is all too easy to do too much, work too hard, and exhaust yourself—which is neither good for you, nor for your product. Say No If you find that you are overworked and struggle to cope with your workload, then start by reflecting on the tasks you carry out. Are all of these part of your actual job? I find that product people often take on responsibilities that belong to other roles thereby making a demanding job even harder. A common example is looking after the development team. While it’s great to care about the team, facilitating effective collaboration within this group is not your responsibility. That’s the job of the Scrum Master. I know that some product people don’t have a Scrum Master working with them or that the Scrum Master’s work is not effective—the individual might be too stretched or not adequately qualified. But if that’s the case for you, then I recommend addressing the issue rather than covering another person’s job. The latter will stabilise an ineffective setup and cause you to be overworked or neglect some of your core duties, neither of which is desirable. Therefore, focus on your actual job—making or keeping the product successful. Do not take on additional responsibilities like improving the development process, leading the dev team, making UX design decisions, or creating a marketing strategy. That’s the responsibility of the Scrum Master, development team, and marketing stakeholder respectively, not yours. Have the courage to say no even if it’s difficult: There is no lasting benefit in you becoming the general dogsbody for the product. Be Proactive Next, minimise the amount of unplanned work and firefighting you encounter. I find that many product people are so busy with urgent tactical work, such as refining user stories, working with the development team, or answering a support request, that they neglect important strategic tasks like regularly assessing if the product strategy is still working. This can cause nasty surprises like a competitor leapfrogging you, which then leads to more, unplanned work, as you desperately try to catch up with the competition. Consequently, make enough time for strategic work. Regularly assess how your product is doing and how effective your current product strategy is, for example, by holding collaborative strategy reviews, as I describe in more details in the article “Establishing an Effective Product Strategy Process”. This will allow you to play a proactive game and be responsive rather than having to react to surprises. Share the Work If you find that you are simply too busy to regularly strategize and cannot let go of any responsibilities, then consider sharing your workload with development team, stakeholders, and other product people. With the Development Team If you spend a lot of time working on the product backlog trying to create perfectly crafted user stories or if you have to answer plenty of questions during the sprints, then you are probably not effectively sharing the product backlog work. Managing the product backlog should be a collaborative effort. The development team members should actively participate in the backlog work, discover, capture and update stories together with you, and help you prioritise the product backlog. This leads to better product backlog items, reduces the amount of questions you have to answer in the sprint, and frees up your time. Additionally, you are often able to delegate (some of) the refinement work to the development team—assuming that the team has acquired enough knowledge about the users and product and that you trust the individuals to make the right decisions. This will further reduce your workload and enable you to spend more time on... - Published: 2018-10-02 - Modified: 2023-10-09 - URL: https://www.romanpichler.com/blog/establishing-an-effective-product-strategy-process/ - Categories: Essential Articles, Product Management Process, Product Vision and Strategy - Tags: innovation, product manager, product owner, stakeholders, teamwork Developing a successful product is not down to luck or trying hard enough. Instead, product success starts with making the right strategic decisions. But as product people, we are often so preoccupied with the tactics—be it dealing with an urgent support request or writing new user stories—that we sometimes no longer see the wood for the trees. In the worst case, we neglect the strategic work and end up with an unsuccessful product. To avoid this pitfall, you should establish an effective product strategy process, as I discuss in this article. Why a Product Strategy Process Matters An effective product strategy process should ensure that a valid product strategy and an actionable product roadmap are always available—that a shared and valid approach to achieving product success is available at anytime, as the picture below illustrates. In the picture above, the product strategy describes how a visionary, inspirational goal is attained. It includes the product’s value proposition, market, stand-out features, and business goals. The product roadmap shows how the product strategy is put into action by stating dates, measurable goals, and selected features. It provides the context for making the right tactical decisions including prioritising and managing the product backlog. Having a valid strategy and actionable roadmap available at all times requires two complementing strategizing approaches, a timeboxed and continuous one, as I explain below. Timeboxed Strategizing Whenever you create a brand-new product or make significant changes to an existing one, you will benefit from creating and validating a new product strategy. This is best done as part of a dedicated strategizing period. This results in an innovation process like the one shown in the picture below. Please note that the picture above depicts strategizing and product development as sets of overlapping activities rather than distinct phases or stages: Carrying out some development activities like UX design and high-level architecture as part of the strategy work sets up the development work and avoids having to use a sprint 0. As it’s hard to correctly determine upfront how much time will be required to carry out the necessary strategy work, for example, observing and interviewing users, testing prototypes, and validating pricing assumptions, I like to time box the work. If you are not sure which time box is right for you, then start with one month and hold weekly review meetings where you assess the progress and decide if and how to continue. In addition to allocating enough time for the strategy work, I find it helpful to adopt a collaborative approach. Bring together the right people and form a product team. You will need development team representatives like a user experience (UX) designer, developer, and tester, key stakeholders such as a sales rep, marketer, and support person, and a Scrum Master, as the following picture shows. A collaborative approach offers you several benefits: It leverages the knowledge and creativity of the dev team and stakeholders, creates a shared understanding, and builds strong buy-in. This reduces risk that the development team members and stakeholders don’t understand or support the product strategy. Don't forget, though, that you lead the strategizing effort. This includes making a decision if no consensus can be reached. The other product team members should help you create and validate the new product strategy, and the Scrum Master/coach facilitates the process. Make sure that the people involved in the strategizing work continue to be involved as the focus shifts to developing and delivering the new product or features. The development team reps should continue to work on the development team; the stakeholders should continue to play their respective roles and be involved in reviewing and adjusting the strategy. Continuous Strategizing As helpful as it is to create a product strategy, it is not enough. The world doesn't stand still; markets and technologies change; new competitors emerge. It is therefore important that you regularly assess if your strategy is still working: Review the product performance using the appropriate key performance indicators. Analyse the data collected to understand how your product is doing. Do the metrics show a positive, flat, or negative trend? What conclusions can you draw from the analysis? What would help your product perform well? Look for new market trends. Are there any new technology, regulatory, or social developments, for example, machine learning, GDPR, and gig economy? Do they impact your product? Do they offer an opportunity to innovate, add, remove, or enhance features, or create a brand-new product? Talking to users, attending trade shows and conferences, and participating in the online communities can help you spot new trends. Keep an eye on the competition. Are your competitors launching new products or features? Are there new market entrants? Should you respond to the changes? If so, which actions are appropriate? Job postings will help you guess your competitors’ plans. Reviewing their products will tell you if your product is still sufficiently differentiated. Follow developments at your own company: Are there any changes to the business strategy? And if so, what are the consequences for your product? Are important stakeholders less engaged?... - Published: 2018-09-04 - Modified: 2022-04-28 - URL: https://www.romanpichler.com/blog/sprint-planning-tips-for-product-owners/ - Categories: Essential Articles, Product Management Process - Tags: product owner, scrum, Scrum Master, sustainable pace As its name suggests, the sprint planning meeting sets up the sprint and establishes what can be done. While it’s an important meeting, I find that some product owners struggle with it. The following tips help you reflect on how you use the meeting and discover how you can get the most out of it. Come Prepared Make sure you carry out the necessary prep work prior to the sprint planning meeting. Be clear on what you want the sprint to achieve, ensure that the product backlog is appropriately refined (or groomed), and have its high-priority items ready. This is necessary for the following two reasons: First, if you start sprint planning without a properly prepared product backlog, you are likely to perform backlog and planning work in a comparatively short, time-boxed meeting.  This makes the sprint planning work challenging, and it can leave the development team feeling exhausted and stressed rather than motivated to start the new sprint. Second, once the planning is done and a sprint goal has been agreed, you cannot, or at least should not, change the sprint contents: Sprints are protected from changes in order to allow the team to work in a focused manner and do a good job. Bear in mind that product backlog grooming should be a team effort and that you should involve the development team members in the backlog work. For advise on when to carry out product backlog grooming, please see my article “When should Product Backlog Grooming Take Place? ”. Focus on the Sprint Goal While there are numerous planning techniques available to determine how much work can be done in a sprint—from using net hours to velocity-based planning, you should not have to worry about how the team plans. It’s up to the team to choose the right planning techniques and determine the right tasks, and it’s up to the Scrum Master to support the team members and suggest appropriate techniques when necessary. As the product owner, you should focus on establishing a shared, meaningful sprint goal that guides the work of the team and explains why the work is carried out. If you don’t have a Scrum Master, then that’s an issue that needs to be addressed: Taking on Scrum Master duties is likely to either overwhelm you and / or cause you to neglect some of your product management responsibilities, as I explain in "Every Great Product Owner Needs a Great Scrum Master". A sprint goal might address a specific risk and help you acquire the relevant knowledge, or it might be about completing or optimising a piece of functionality. An example of the former would be “Find out if users are willing to share personal data as part of the initial registration process” to address a user-interaction risk. An example for the latter might be “Finish the dashboard so it can be released to the test users”. If you work with release goals, which is something I usually encourage, then every sprint goal should be a step towards the next release goal. While my experience suggests that many product owners don’t use sprint goals, I find them tremendously helpful. They provide purpose and alignment; they facilitate stakeholder communication; and they make it easier to analyse and action the data obtained from exposing a product increment to the users. But to fully leverage sprint goals, you must ensure that they are meaningful to the development team so that people support them. If you believe, for example, that addressing a user interaction or pricing-related risk should be the goal of the sprint, but the dev team insists on first addressing a crucial technical risk, then it may not be a good idea to force your goal onto the team. Instead, search for an inclusive and shared goal that everyone agrees with. Alternatively, use two separate goals, as long as this is the exception and not the norm: Working with one shared sprint goal is the default in Scrum, as this fosters close teamwork and collaboration. Additionally, it tends to make it easier to collect and analyse the relevant user feedback. I like to identify a candidate sprint goal as part of the grooming work. This avoids the risk of starting sprint planning without a firm idea why the sprint should be carried out.  Once a shared goal has been agreed, the development team performs the planning work and validates if the goal is realistic. If that’s not the case, then you will have to adjust the goal and make it less ambitious until it fits into the sprint.  You can download my sprint goal template, which helps you formulate clear and testable sprint goals. Be Present As the product owner, you may have many duties competing for your time and attention; attending yet another sprint planning meeting might not be your highest... - Published: 2018-08-14 - Modified: 2023-10-09 - URL: https://www.romanpichler.com/blog/strategic-options-for-mature-products/ - Categories: Product Vision and Strategy - Tags: product discovery, product life cycle Product strategy does not only matter for new and young products; it is equally important for older ones. This article discusses two main choices for mature products: extending the life cycle and revitalising the product, or leveraging maturity and turning the product into a cash cow. What Maturity Means A product is mature if it has stopped growing: The benefits it creates no longer rise. Instead, they have started to stagnate. In terms of the product life cycle model, the product has left the growth stage and entered maturity, as the following picture shows. To find out if your product is mature, you should track its performance. To do so, you must be clear on the value it creates for the users and business. A tool like my Product Vision Board can help you with this. Next, select the right key performance indicators (KPIs). These might include revenue, cost, profit, market share, engagement, net promoter score, and cancellation rate, for instance. Then measure how much value your product creates. If the data shows a largely flat performance over the last few months, then the product is likely to be mature. Ideally, you should continuously track the product performance and regularly review the product strategy—at least once per quarter as a rule of thumb. You should therefore become quickly aware of the fact that the product performance is stagnating and your product is entering the maturity stage—which I regard as an important strategic inflection point. This enables you to be proactive and thoughtfully respond to the change. Note that eventually every product enters maturity; no product can continue to grow forever. The only question is when this will happen. Option 1: Extend the Product Life Cycle Once your product has entered maturity, your first option is to move the product back into the growth stage thereby extending its life cycle, as the following picture shows. A number of techniques can help you make an ageing product attractive again including enhancing its capabilities and adding new features. Take the iPhone as an example. Apple has made considerable changes to the products throughout its life: it introduced apps, increased its size, improved the camera, and added face recognition, to name just a few. Sometimes, though, the opposite strategy is more appropriate. Instead of adding more features, you may want to remove some and declutter your product. Take Microsoft Word for example. Microsoft has made significant efforts to simplify the application in recent years, thereby making it easier for people to use the product. Another way to stimulate growth is to take your product to a new market or market segment. Think of YouTube Red, a variant of YouTube, for example. At the time of writing, the product offers advertising-free online and offline viewing of YouTube videos, as well as access to Google Play Music and YouTube Red Original series and films. (At the same time, the move has enabled Google to compete with companies like Netflix. ) Finally, you might consider bundling your product with other offerings to increase its attractiveness. For instance, iOS and Android bundle a mobile operating system with a number of pre-installed apps including a web browser, email client, and maps. Is Option 1 Right for Your Product? While rejuvenating the product and moving it back into growth may sound attractive, it is not necessarily the right thing to do for your product. If you should choose this option depends on a number of factors: The category the product belongs to continues to be attractive. You don’t want the product to turn into a cash cow. You are able to invest the time and money required to extend the life cycle. The product is not too deep into maturity; its performance has fairly recently stagnated. The product health including its code quality is reasonable. If the product category your asset belongs to has lost its attractiveness, then revitalising the product will be difficult. Take MP3 players, for example. The product category has lost its sparkle; fewer and fewer people own dedicated MP3 players; and most of us use our phones to listen to music on the go. If say Apple wanted to revitalise its iPods, then this would be hard to achieve (unless the company marketed them as niche products similar to turntables). Additionally, rejuvenating your product only makes sense when you don’t want or need it to become a cash cow. As its name suggests, a cash cow is a product that offers plenty of business benefits while it requires a comparatively low investment. Any product portfolio should contain a healthy mix of younger and older products. It can therefore be advantageous to accept maturity and let your product age gracefully, as I discuss in option 2 below. Extending the product life cycle also... - Published: 2018-07-03 - Modified: 2022-09-22 - URL: https://www.romanpichler.com/blog/growth-mindset-in-product-management/ - Categories: Essential Articles, Product Leadership - Tags: learning, mindfulness, skills Learning is crucial for us product people. As our products change and eventually mature, we must change the way we manage them. As our jobs change, and we have to grow into them and acquire new skills. Additionally, product management is a comparatively young profession that is still evolving; new models and techniques emerge. This article discusses how embracing a growth mindset helps you succeed as a product professional. Embrace a Growth Mindset Learning something new requires the right mindset or attitude. If you believe that you lack talent or are not smart enough, then you make it hard—if not impossible—for yourself to acquire new knowledge, skills, and behaviours. For example, I never used to think myself as somebody who is good at writing, and I wasn’t particularly good at it at school. But with effort, resilience, and patience, as well as the guidance from others, I have managed to become a reasonably skilled writer. The same is true for my product management expertise: Acquiring it has taken me many years, making plenty of mistakes, learning from other product people, and reading more books and articles than I can remember. I certainly don’t feel that I am done yet. I continue to learn new things and deepen my understanding. Now, you might say that’s just a sign that I lack talent. But achievement requires effort, and the better we want to become at something, the more effort is required. I remember once asking my saxophone teacher how he became so good, and he simply replied, “practicing eight hours per day”. Charlie Parker, one of the most famous and arguable best saxophonists ever, took this further and practiced up to 15 hours per day. I am not suggesting that innate talent doesn’t exist, but its role is often overemphasised. This leads to a fixed mindset, where people see themselves as good or bad at something—be it writing, singing, drawing, or product management—and they believe that there is not much they can do about it. But the opposite is true: A “person’s true potential is unknown (and unknowable)” and “it’s impossible to foresee what can be accomplished with years of passion, toil, and training”, as Carol Dweck—who coined the term growth mindset—writes in her aptly named book Mindset. Instead of labelling yourself and thinking that you are talented, smart, or clever (or possibly the opposite), see yourself as malleable and adaptable. With the right effort, you will learn new skills and deepen existing ones, you will develop and grow. By doing so, you adopt a growth mindset. Appreciate Failure and Make the Right Effort Learning a new skill can be fun and easy. But it can also be very challenging. Often, it involves stepping outside your comfort zone and making mistakes. Think of what it was like to learn to ride a bicycle, for example. I remember crashing numerous times until I was able to stay upright on the bike, riding wobbly and tentatively at first and slowly getting better over time. The same holds for product management: When you create a product strategy for the first time, for instance, you are likely to make plenty of mistakes. You may not use the right research and validation techniques; your target group may be too big and heterogenous; the value proposition may not be concise and compelling; the standout features of your product may not be terribly exciting; and the business goals may be unmeasurable. But that’s OK—as long as you are able to recognise that you made a mistake and you are willing to learn from it. Therefore, don’t let mistakes discourage you. See failure as a necessary part of the learning journey rather than something bad that should be avoided. Be patient, don’t put yourself under pressure, don't try to force success, and don’t beat yourself up if you don’t succeed. I can be very self-critical when I learn a new skill, for instance. I can have thoughts like “I am no good at this” and “I’ll never get it” when I make a mistake and struggle. While it’s normal to have doubts, acting on those thoughts would be giving in to a fixed mindset. Instead, practice self-compassion, reflect on your learning approach, and have faith in your ability to develop and grow. With the right effort you will get better. It might just take a little while. Cultivate an Open Mind Believing in our ability to learn and grow sounds like common sense. So why don’t we always show a growth mindset? An important reason is our attachment to what we know and who we think we are. If we are aware of it or not, we tend to be fond of the knowledge and skills that we have acquired; and the more we know, the more expertise we have on a given subject, the more attached and less open to new insights and change we usually are. If you’ve... - Published: 2018-06-04 - Modified: 2024-04-08 - URL: https://www.romanpichler.com/blog/digital-transformation-and-product-management/ - Categories: Product Leadership - Tags: product manager, product owner, scrum, skills Digital transformations often focus on new technologies, agile practices, and new business models. While these are undoubtedly important, a further success factor is sometimes overlooked: product management. In this article, I share my tips for establishing an effective product management function to achieve a successful digital transformation, offer the right customer experience, and help unlock the organisation’s innovation potential. Recognise the Importance of Product Management A digital transformation is a major change program that helps a company succeed in the digital age. Embracing new technologies like machine learning, micro services, big data, and Internet of Things (IoT) is part of that change, as is the introduction of agile practices including cross-functional and self-organising teams, DevOps, Scrum, and Kanban. Business models also tend to change when companies digitalise their business—customer relationships, pricing models, partner and supplier relationships, cost factors, and other aspects are likely to be affected. But to take advantage of new and existing digital assets, align them with physical products and services and create a seamless user experience, and increase the overall value created, companies require product professionals—dedicated, qualified product people who look after the digital assets. For some companies, this means introducing a new department or group, creating new roles, and career plans. That’s often the case in my experience for businesses in finance, media, travel, insurance, and other verticals that traditionally don’t have product management groups, and where product management is not represented at the executive level. Note that employing people who are called product owners or product managers does not necessarily mean that a product management function exists. I have seen more than one business that called their project managers and team leads “product owners”, but failed to give the individuals true ownership of the products and equip them with the necessary skills to manage them. The changes required to establish a product management group are far from trivial, and they require executive management support, as I discuss in more detail below. Companies with an existing product management group usually require up-skilling and retraining their product people, as well as adjusting roles and responsibilities and career plans. This helps the individuals embrace an agile mindset, take advantage of new techniques and tools—think of hypotheses-driven strategy validation, goal-oriented product roadmaps, and user stories—and effectively collaborate with the agile development teams. Additionally, companies need to consider how the individuals in charge of digital products collaborate with those responsible for the revenue-generating goods and services. While these changes are not as deep as introducing a new product management group, they still need to be carefully managed. Define Clear Product Roles and Responsibilities One of my clients called everyone in charge of a feature, product, and portfolio a “product owner” at the start of their digital transformation. Consequently, people were confused and unsure what it meant to play the role, and the organisation’s learning and development program wasn’t effective. This example is representative for many companies in my experience: product roles are often applied ineffectively. As I have argued before, a product owner or product manager should be in charge of a product—an asset that creates value for a group of users and the business. The individual should manage the product for an extended period of time, usually for several life cycle stages, not just a few weeks or months. This creates continuity of purpose, facilitates learning, and reduces wasteful handoffs. Individuals who own part of a product are not product but feature or component owners in my mind. They have an important job too, but their responsibilities differ: they are focused on their specific feature or architecture building block rather than trying to increase the value the entire product creates. People who look after a group of products are not product owners either, they are portfolio owners or managers. To get the roles definition right, start by identifying the company’s products. Consider the revenue generating assets as well as the supporting ones. Take, for example, an insurance policy that helps people protect their home, and the digital products that help customers select and buy the right policy. Then align the physical and digital assets to create a consistent user experience, no matter if the policy is bought online or in a branch, for instance. Finally, ask yourself who should own each product, and how many teams are required to develop the product. You may consequently have to identify additional people with more specialised roles like feature and component owner who support the overall product owner or manager of the larger offerings. Determine the Right Learning and Development Measures Once you have the right roles in place, take the next step and determine the necessary skills for each role. While there is likely to be some overlap, different roles have different skills profiles. A component owner, for example, typically requires strong technical skills, as the person will have to... - Published: 2018-05-08 - Modified: 2022-04-28 - URL: https://www.romanpichler.com/blog/product-leadership-in-scrum/ - Categories: Essential Articles, Product Leadership, Product Management Process, Product Roles - Tags: product owner, scrum, Scrum Master, self-organisation, skills Product owners can take on too many responsibilities, become too tactical and inward-focused, and lose sight of their main job: maximising the value a product creates. Instead of managing the team or establishing the right process, product owner should manage the product and exercise product leadership, as I explain in this article. Three Types of Leadership Scrum is a simple framework with three roles: product owner, development team, and Scrum Master. Each role provides a distinct type of leadership. As the product owner, you lead the product and are responsible for its overall success. The cross-functional development team makes the design and technology decisions; and the Scrum Master guides process and organisational change, as the following picture shows. While the three roles exercise different leadership, the people involved must effectively collaborate to achieve product success and align product strategy, roadmap, backlog, design and technology, and process decisions—without losing focus of their respective core responsibility.   Lead the Product As the product owner, you should lead the product and guide the development effort by providing an inspiring vision; a validated product strategy that clearly communicates the product’s value proposition, target group, stand-out features, and business goals; an actionable product roadmap that details the strategy and states how the product is likely to evolve; a prioritised product backlog that captures the functionality required; and by engaging the stakeholders in the right way, for example, inviting them to product strategy and roadmap workshops and sprint review meetings. While I’d like to encourage you to involve development team members and key stakeholders in the visioning, strategising, and roadmapping work, you should lead these activities with the aim to maximise the value your product creates. This may mean making tough decisions and saying no to some ideas and requests, while trying to be an effective, balanced leader—avoiding the pitfalls of being too authoritarian and not assertive enough. Providing the right product leadership is demanding; it requires a specific skills set and usually your full attention as the person in charge of the product. Consider all the things you have to do: be in contact with the users to understand their needs and validate ideas; manage the internal stakeholders and keep them in the loop; regularly review the product strategy and roadmap thereby considering market trends and the competition; work with the development team on the product backlog and answer questions that arise in the sprint; attend the sprint events—and the list goes on.   Nevertheless, product owners often step in and take on additional responsibilities, such as looking after the development team and resolving conflicts in the team, or making design decisions, when the Scrum Master or dev team do not provide the necessary leadership—be it that they lack the time or skills, or that there is no Scrum Master at all. As a consequence, product owners can become too tactical and inward-focused, too concerned with team and process issues, and neglect the strategic product work. This risks no longer seeing the wood for the trees. In the worst case, the strategy is no longer valid, but you do everything you can to steam ahead, asking the team to push out more and more features. On a personal level, taking on additional responsibilities is unhealthy and unsustainable: You will end up overworked if you try and keep up all the product work and take on dev team or Scrum Master duties. Do the Right Thing As the product owner, you are not responsible that the team members collaborate and manage their work effectively, that the right user experience (UX) is created, that the right software architecture is used, and that the right technology decisions are made. That’s the job of the development team. You are also not responsible that the right process and methods are used, that impediments are removed, that stakeholders and management understand agile principles and practices, or that the necessary organisational changes are made—be it establishing an effective product management group, adjusting roles and responsibilities, or providing the team with an environment that is conducive to creative work. That’s the responsibility of the Scrum Master. While it’s great to care, you should refrain from taking on additional responsibilities, as this will only stabilise an ineffective setup: If you can carry out Scrum Master work and look after the team, then why would it be necessary to hire a dedicated, qualified Scrum Master? If you can do the UX design, then why hire a designer? As hard as it may be, say no, provide the right leadership, and focus on your job—achieving product success, not managing the development team or the process. Notes  I have placed user research, sprint goal selection, and product backlog refinement between the product owner and development team in the picture above, as these responsibilities are shared by the two roles in Scrum. You... - Published: 2018-04-03 - Modified: 2025-06-16 - URL: https://www.romanpichler.com/blog/business-strategy-and-product-strategy/ - Categories: Product Vision and Strategy - Tags: product manager, product owner As product people, we can be very fond of the products we manage. While it’s good to care about them, we must not forget that they are a means to an end: Products only exist to create value for their users and the business. It is therefore important that your product helps your company move forward and supports the overall business strategy, as I discuss in this article. Business Strategy vs. Product Strategy A business strategy describes how a company wants to achieve its overall aspiration and create value for its users, employees, and shareholders. It’s distinct from the product strategy: The business strategy states how the company will be successful, whereas the product strategy describes how a product will achieve success, as the following picture illustrates. The business strategy provides the company with the basis for making the right investment decisions. This includes determining if a new product idea should be pursued and how much money should be spent on an existing product. At the same time, it offers you, the person in charge of the product, the necessary context to make the right strategic product decisions, for example, the market your product should serve and the business goals it should meet. It is therefore a key input for any product strategy work. Unfortunately, it’s not uncommon in my experience that organisations don’t have a business strategy, or that the strategy is not communicated. Statements like we want to grow, increase our profit margin, or gain more market share are not business strategies. Achieving growth is a business imperative; increasing margins and market share are goals that might be part of a business strategy. On their own, they are not enough. Elements of an Effective Business Strategy What does an effective business strategy look like? I find Roger Martin’s approach for creating such a strategy helpful. It involves answering the following five questions. What is your winning aspiration? Why does your organisation exist? What is the company’s vision? State the purpose of the organisation that provides continued guidance and helps identify the right strategic objectives. Think, for instance, of Google's vision "to organise the world’s information and make it universally accessible and useful. " Where will you play? Clearly describe the areas in which the company will compete to fulfil its aspiration. Who should benefit from your offerings? Do you intend, for instance, to address existing markets? Or do you aim to create new markets (also called blue oceans). Which geographies or regions do you want to address? Which product categories and channels will you require? Answering these questions requires making tough choices—saying yes to some options, and explicitly discarding others. How will you win? What is your competitive advantage? For example, cost leadership (low prices), differentiation (uniquely desirable products and services), or focus (niche markets)—three options originally suggested by Michael Porter. Answering this question requires you to understand the strengths and weaknesses of your business and the competition you face. What capabilities must be in place? What do you need to be really good at? Which new products or services do you require? Which existing products you should enhance, and which offerings you should remove? In other words, decide how you should adjust your product portfolio thereby creating the context to allow the product people to make the right strategic choices for their individual products. Which management systems are required? Which processes and structures are necessary to build the appropriate capabilities and reinforce your organisation’s strategic choices? This might involve creating or strengthening a product management organisation and hiring or developing product people who have the right skills to professionally manage digital products. Note that there is no perfect business strategy—just like there is no perfect product strategy. Instead, strategy is about increasing the chances of being successful. What's more, strategy is not fixed: as the market and competition change, your business and product strategies have to evolve. It is therefore important that you regularly review the business strategy, as well as the product strategy—biannual reviews for the former, and quarterly reviews for the latter, as a rule of thumb. Ownership of Business and Product Strategy Who’s responsible for ensuring that an effective business strategy exists? The answer is simple in my mind: executive management. The leadership team of any company must lead the effort to create, review, and adjust the business strategy. But things are different when it comes to product strategy. Product management should be in charge of the product portfolio and make the necessary product strategy decisions—within the context established by the business strategy. This requires that the product people know the business strategy, have the appropriate decision-making authority, trust, and support, as well as the right knowledge and skills, as the picture below shows. Regrettably, the division of labour shown above is not always used. I have worked even with mid-sized companies, where the leadership team was firmly in charge of product... - Published: 2018-03-12 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/be-a-balanced-product-leader-not-a-feature-broker-or-product-dictator/ - Categories: Product Leadership, Product Roles - Tags: product manager, product owner, stakeholders, teamwork Being an effective product leader is not easy: It requires embracing people's ideas as well as saying no, being neither too accommodating, nor too assertive. This post helps you recognise and overcome two common, ineffective leadership styles, feature broker and product dictator, and develop a balanced, successful leadership approach. Feature Broker and Product Dictator How do you best lead the stakeholders and development team as the person in charge of the product? One way to answer this question is to avoid unhelpful but common leadership styles. Two of these styles, feature broker and product dictator, are shown in the picture below. A feature broker is a product person who relies on others—the stakeholders, development team, management, users, or a customer—to come up with ideas and make product decisions. As its name suggests, this leadership style mediates between different parties and tries to broker a deal. A product dictator—also called a coercive leader—exhibits the opposite leadership style: the individual assumes that she or he knows best what needs to be done. Consequently, the person makes the product decisions and expects others to support them. While being a feature broker shows that the individual is able to connect with other people and appreciate their ideas, it carries the risk of trying to please everyone thereby creating a product that doesn’t do a good job for anybody. In the worst case, you end up with a feature soup, a loose collection of features requested by the users, customers, or stakeholders. Such a product typically has a weak value proposition, offers a poor user experience, and is therefore unlikely to become a success. Being a product dictator is equally undesirable, unless your product is in crisis. Being decisive and having a clear vision of where you want to take the product is certainly helpful. But if you believe that you are always right, and you know best, then you probably end up making wrong decisions: It’s very unlikely that one person has all the knowledge and skills required and can counteract all cognitive biases. Even if this was the case, this leadership approach creates an unhealthy work environment: The development team members and stakeholders are told what to do and are expected to fall in line to support the decisions—no matter if they agree or not. This dampens their motivation, wastes their creativity and knowledge, and leads to weak buy-in. What’s more, people are likely to blame you if the product does not deliver the desired benefits. To make things worse, you may end up worn-out and overworked, as you want to be involved in all decisions. Recognise Your Leadership Bias Feature broker and product dictator are extreme leadership styles, of course. But it seems that most of us, including myself, gravitate towards one of the two extremes and are inclined to act as a feature broker or product dictator. If that's the case for you, then don't feel bad. Recognising your leadership bias is a key step towards becoming a better, more effective product leader, as I explain below. If you are new in a product role or if you have just taken on a new product, and your knowledge about the users, needs, business goals, and competition is still weak, then you often end up asking the stakeholders and dev team for suggestions and are more likely to accept their requests. Similarly, if you work in an organisation where product management is not recognised as a function in its own right, or if you look after a bespoke product for a customer, you may get pulled towards the feature broker style. Additionally, if you find it generally difficult to say no to others and want to please people, or if you suffer from imposter syndrome and believe that others know much more about the product than you do, then this trait will draw you towards the feature broker style. If, however, the dev team and stakeholders are less experienced than you, or if you hold a senior position in the company, then people may well expect you to decide and tell them what to do. Even if you involve them in the decision-making process, people may require encouragement to speak their mind and think out of the box. Moreover, if you find it hard to trust others, if you are critical of yourself and other people, if you are a bit of a perfectionist or control freak, then you are likely to lean towards the product dictator pattern. Be a Balanced Product Leader Once you understand your leadership bias, you can take the next step and address its causes. This will help you become a more balanced and effective leader grounded in the middle of the leadership continuum shown in the picture below. If you gravitate towards the feature broker style, then empower... - Published: 2018-02-06 - Modified: 2023-10-19 - URL: https://www.romanpichler.com/blog/leading-through-shared-goals/ - Categories: Essential Articles, Product Leadership - Tags: product goal, product manager, product owner, sprint goal, stakeholders, teamwork Ensuring that development teams and stakeholders are moving in the same direction is crucial to achieving product success. But aligning people can sometimes feel like herding cats. In the worst case, they go off in different directions and create work results that don't fit together. In this article, I describe my framework for setting effective goals to help you guide and align the stakeholders and the development teams. Overview of the Goal-setting Framework The framework I have developed uses four different types of goals: product vision, user and business goals, product goal, and sprint goal, as the following image shows. You can download the framework below by clicking on the picture below. The goals in the framework above describe the outcomes you want to achieve. What's more, they are systematically linked—they inform each other. Let’s take a look at them in more detail. The Product Vision The first and possibly most powerful goal is the product vision. It describes the ultimate reason for creating a product and the positive change it should bring about. A sample vision I like to use is "healthy eating. " This example shows that the vision is best captured as a brief statement or slogan. What’s more, an effective vision inspires people; it provides motivation and purpose. As the vision is a big, hairy, audacious goal, it cannot be measured. In fact, you might never fully realise your vision. That’s okay, as long as it acts as the product’s true north that provides continued guidance. To learn more, watch the following video: https://youtu. be/_EyaHKVCAiw The User and Business Goals A user goal describes a problem users want to see addressed or a benefit people want to gain, for instance, "reducing the risk of developing type 2 diabetes. " A business goal states the benefits the company developing and providing the product wants to achieve. This might be diversifying the business, opening up a new revenue stream, or developing the main brand. Whatever user and business goals you choose, make sure that they are clear. It would be a mistake, for example, to state "improve people’s eating habits. " This user goal is too vague. Working with specific user and business goals offers better alignment and allows you to select the right key performance indicators. These help you understand if the product is creating the desired value and if you are making progress towards the goals. Product Goals With user and business goals in place, you can take the next step and determine specific product goals. Each goal should be a step towards meeting the user and business goals, and it should describe a specific and measurable benefit or outcome, for example, acquiring users, increasing engagement, generating revenue, or removing technical debt to future-proof the product. I find that product goals are especially valuable to align stakeholders and communicate the impact you want to achieve with your product in the coming months. The last goal in my framework is the sprint goal. Achieving this goal should move you closer towards meeting the overarching product goal. Each sprint goal is therefore a step towards a product goal. Sprint Goals The last goal in my framework is the sprint goal. Achieving this goal should move you closer towards meeting the overarching product goal. Each sprint goal is therefore a step towards a product goal. When setting a sprint goal, make sure that it states the desired outcome of a sprint, for example, "find out if users are willing to share personal information," "test integration with leading smart scales," or "finish the dashboard to release a first version and learn from the feedback. " I recommend that you derive the sprint goal from the product goal and that you state it on the sprint backlog or task board. This ensures that each sprint moves you closer towards the overarching product goal. (If your development team does not use Scrum, then it might still be helpful to agree on weekly or fortnightly goals that direct the work of the team members. ) The Connections between the Goals As you may have noticed, the goals in my framework are connected. The vision guides the selection of the user and business goals, which help you choose the right product goals; and a product goal is broken over time into several sprint goals. This way, the vision ultimately guides product delivery. As you move from the product vision to the sprint goal, the objectives become more and more focused and describe increasingly shorter time frames. A vision might cover the next five to ten years. A sprint goal, however, lasts only two to four weeks. However, the connections in my framework are not only top-down. They are bidirectional and also work bottom-up. If one or more sprint goals cannot be met, the product goal might have to be adjusted. If you struggle to achieve the product goals you have set, you... - Published: 2018-01-09 - Modified: 2023-10-09 - URL: https://www.romanpichler.com/blog/product-discovery-tips/ - Categories: Product Management Process, Product Vision and Strategy - Tags: product life cycle, stakeholders, teamwork, validation Product strategizing refers to the activities required to determine if and why a product should be developed. Carrying out this work makes it more likely to create a product that users want and need. In this article, I share my recommendations to help you improve your product strategy work. Bring the Right People Together Product strategy is a team sport. You should therefore involve the right people in the work and secure enough of their time. I find it helpful to form a team that consists of: Development team members: user experience (UX) designer, developer, tester; Key stakeholders, for example, representatives from marketing, sales, and support; A Scrum Master, agile coach, or product coach. Involving these individuals in the strategizing work allows you to leverage their knowledge and expertise, builds rapport, and creates support for key product decisions including the selection of a specific market segment and stand-out features. A UX designer, for example, might help you observe and interview users; and a developer and tester might advise you on technical feasibility, identify technical risks, and build prototypes; a sales rep might get you in touch with prospective customers and help you with competitor research; a Scrum Master might facilitate collaboration and advise on process issues—for instance, which process and tools should be best used to visualize and track the discovery work. (I prefer to use a Kanban-based process and a Kanban board to organise product strategy validation work, as I discuss in my book Strategize in more detail. ) Focus on Problem Validation, not Solution Building Your product strategizing should focus on nailing the value proposition, target group, business goals, business model, and stand-out features of the product—not determining individual product features, writing user stories, designing the user interface, or building the actual solution. Your goal should be to mitigate the risk of offering a product nobody wants and needs, not to figure out the product details. Having said that, it’s ok to address key UX and technology risks and evaluate important user interaction and architecture options as part of the strategizing work. But the bulk of the UX design, user story writing, and technology work should be done after you have successfully validated the problem. To get your focus right, consider using a tool like my Product Vision Board to capture your idea, and identify assumptions and risks. Do Just-Enough Strategizing Work Minimise the amount of time you spend on any upfront strategy work to accelerate time-to-market. You should aim to get an initial, good enough product out as fast as possible, and then adapt it to the market feedback.   But don’t rush the work, and resist the temptation to jump start building the actual product. Explore the key assumptions and risks in your product strategy and business model by systematically testing and addressing them in an iterative fashion using, for example, observations, interviews, surveys, and prototypes. If you can’t confidently state why people are going to use your product, who those individuals are, what makes your product stand out from the crowd, and why it’s worthwhile for your business to develop and provide the product, then you are not in a position to build the actual solution. Instead, continue the strategy work (persevere or pivot), or stop and move on to another product idea. Talk to the Users With all the product strategy work that needs to happen, it can be easy to lose sight of the most important success factor—the people who are going to use the product. There is no point in coming up with a smart business model and sophisticated user interactions, if you don’t understand the user needs, what they may struggle with, what works well for them, and what doesn’t. If the users don’t need your product or if they find it hard to use it, then you will find it hard to monetise it and achieve product success. Therefore, get out of the building, as Steve Blank recommends, and meet target users face-to-face, be it online or onsite. I know that’s not always easy. But to succeed, I find it paramount that you—the person in charge of the product—carry out user research yourself and develop a deep understanding of the user needs. When communicating with users, take a genuine interest in the people you meet. Listen attentively and let go of preconceived ideas about the problem you think the users have or the solution you believe they need. This allows you to discover what people really want and need thereby maximise the chances of creating a successful product. Don’t Handoff Product Strategy Work I've seen more than company where a group of people carried out the product strategy work and then handed it of to another group who would determine the detailed product functionality and deliver the product. But... - Published: 2017-12-04 - Modified: 2025-02-18 - URL: https://www.romanpichler.com/blog/leveraging-failure-in-product-management/ - Categories: Product Leadership - Tags: learning, mindfulness, product discovery, risk, validation Innovation and failure go hand in hand. It’s impossible to bring new products and features to life without taking informed risks and making mistakes. But effectively leveraging failure can be challenging on a personal and organisational level: As individuals and companies, we want to succeed, not fail. This article shares my recommendations on how to fail well and learn from it. Why Failing Can Be Hard If we like it or not, failure is an essential innovation ingredient. It’s impossible to successfully innovate without taking informed risks and making mistakes. YouTube, for example, failed as a video-dating site and succeeded by pivoting to video-sharing site; and Google Glass failed as a consumer product and was recently re-launched as a B2B product. As these examples show, you are bound to make mistakes whenever you try something new: You may discover that some of your ideas and assumptions are wrong or that you have executed them wrongly. As individuals and businesses, we should therefore appreciate failure—product success would otherwise be impossible to achieve. But deep in our hearts, many of us dread failure. Why is that? Most larger companies are great at maintaining existing products and leveraging them as cash cows in order to generate vital business benefits. This often leads to a conservative attitude, protection of the current assets, and focus on operational excellence and flawless execution. In such an environment, product innovation is the exception rather than the norm, and experimentation and making mistakes are discouraged. In the worst case, such a company experiences Innovator's Dilemma: It has lost its ability to embrace new opportunities and technologies and can't keep up with new competitors. But it would be wrong to say that it's all management's fault. As individuals, we sometimes see failure as a threat and consequently shy away from it. That's partly due to our conditioning—we usually don't get praised in school for failing, and we certainly don't get great marks for making mistakes. But I’ve noticed that failure becomes particularly difficult for me if it challenges my self-view. If I identify myself with what I know and do, then failure jeopardises my sense of who I am and how others might perceive me. This restricts me to my comfort zone—I keep doing what I do well—as this feels nice and pleases my ego. The drawback is that I don’t develop and grow, avoid challenging projects, and miss new opportunities. I’ve also noticed that when I badly want to succeed, I don’t want to be confronted with failure, and I consequently ignore it—sometimes without being aware of it. This makes me prone to confirmation bias, which is the tendency to favour information that confirms our preconceptions, and it puts me in danger of ignoring data that indicates failure. Instead of build-measure-learn, I now get build-measure-deny; instead of inspect-and-adapt, I end up with inspect-and-ignore—which is hardly a recipe for achieving product success. Luckily, there a number of things we can do to accept and leverage failure, as I discuss below. Create a Fail-Safe Environment If there is fear of failure, if people are worried about their jobs and career prospects when they make mistakes, then failure is unlikely to happen. Consequently, learning from failure and successful product innovation are difficult to attain. At the same time, companies must protect their cash cows to generate enough revenue and other business benefits, as I pointed out above. The following techniques make it possible to fail safely and protect mature assets. Innovation Lab: A dedicated research facility that is tasked with new product development. Many tech companies including Google and Microsoft use labs—which are sometimes also called research centres. The potential drawback is a disconnect with the rest of the company (ivory tower syndrome). Incubator: A temporary business unit created to bring a new product to life. As soon as the product is launched, the incubator is dispersed, turned into a permanent business unit, or spun off as a separate business. Incubators avoid the ivory tower syndrome of innovation labs. But it can be hard to create the right environment that removes people (temporarily) from their peers and encourages them to think outside the company norms. Hackathons: A dedicated event where people come together for one or more days to try out new ideas. Facebook’s Like button was conceived in a hackathon, for example. A potential drawback is solution focus—it may be more important to build a cool prototype than to understand if and why people would want to use the product or feature. 20% Rule: Engineers can spend up to 20 percent of their time exploring new ideas. Google Mail and Google Chrome browser were conceived this way, for instance. A drawback is a seemingly high investment in innovation. Whichever approach you choose, ensure that you create an environment that allows you to fail and learn fast: The earlier you fail, the cheaper... - Published: 2017-11-15 - Modified: 2025-07-22 - URL: https://www.romanpichler.com/blog/sprint-review-tips-for-product-people/ - Categories: Essential Articles, Product Management Process - Tags: product discovery, product owner, scrum, Scrum Master, stakeholders, user feedback, validation The sprint review is maybe the most important Scrum meeting for product people. Applied correctly, it increases the chances of creating a successful product. But I find that the meeting is not always used effectively. My article addresses this issue and shares practical tips for getting the most out of the sprint review. Use the Meeting for Product Discovery, Not Only Delivery The sprint review meeting serves two main purposes: Product discovery: Validate the latest product increment/prototype and discover opportunities to offer new and enhanced features. Ensure that the product provides the right functionality and user experience. One way to achieve this is to invite (selected) users and customers, as well as stakeholders, run a demo, and ask the attendees for feedback. Product delivery: Determine what is done and track the development progress. Maximise the chances that the product goal (outcome) can be achieved on time and on budget, and that the product will be delivered as expected. Many sprint reviews I have attended emphasised the second objective and neglected the first one. Don't make this mistake. If a product does not offer the right features, delivering it on time and on budget is of little value. Involve the Right People Collecting feedback from the right people is crucial to make effective product decisions: If you invite the wrong individuals or if key people are missing, you are unlikely to receive the feedback you need. You should therefore make sure that you invite the right individuals. As a rule of thumb, ask those people to attend whose input you need to validate the latest product increment and move the product forward. These are usually users and customers, as well as the key stakeholders. The latter may include people from marketing, sales, service and support, and other business units, depending on your product and organisation. Ask the Scrum Master to facilitate the meeting and establish ground rules. Alternatively, see if another product manager/owner can act as a facilitator. This frees you from having to moderate the meeting and allows you to focus on gathering feedback and determining the development progress. Split the Meeting When Needed Sometimes it’s helpful to split the sprint review meeting into two parts. In the first part, you and the development team get together. The team demos the product increment to you. You then give feedback to the team members and determine which items are done and how much progress has been made using a tool like the release burndown chart (which I discuss in more detail below). In the second part, the stakeholders and (selected) users and customers join the meeting. I find that as the person in charge of the product, you are often best suited to present the product increment: You are likely to better understand how a user would interact with the product and use the new functionality compared to a development team member. Additionally, you probably know better how to collect feedback that helps you learn if the right user experience and functionality are offered. Splitting the meeting allows you to have a focused conversation with the development team, determine the development progress, and address potential issues before users, customers, and stakeholders join you. This is particularly helpful when you didn’t have the chance to interact with the team during the sprint. Make sure, though, that the development team members attend the entire meeting and are present in the second part. Hearing feedback directly from users, customers, and stakeholders is invaluable. Encourage Feedback but Don’t Say Yes to Every Idea More than one sprint review meeting I’ve attended was quickly over: A development team member demoed the functionality to confused-looking attendees with the product owner in the background. Afterwards, the Scrum Master asked if there were any questions or feedback, but the individuals just looked at each other, a few said “nice job” and “looks good”, and left. The valuable feedback gathered in this meeting was zero. To avoid such a meeting, encourage people to actively participate and share their views, ideas, and concerns. Use open-ended questions, for example, “What do you think about the improvements we made to the registration feature? ” Try to understand why somebody likes or dislikes something. Receiving feedback such as “looks great” may feel good, but it does not offer any new insights. Why does the person like the feature? And is there anything that could be improved further? Additionally, do your best to attentively listen to the attendees and appreciate their views. But don’t be afraid to say no to ideas and requests if they are not helpful and realistic. Use the current product goal together with the product strategy to decide if you should take on a request. If you are unsure, use the next sprint to test if the idea or request would be beneficial for... - Published: 2017-10-04 - Modified: 2026-01-13 - URL: https://www.romanpichler.com/blog/empathy-tips-product-management/ - Categories: User Experience (UX) - Tags: empathy, product discovery, user feedback Being able to empathise with the users and understand their feelings and thoughts is key to offer a successful product. This article shares five tips to help you develop empathy for your users and create a deeper understanding of their needs. Why Empathy Matters Possibly the most profound challenge in product management is to understand the needs of users and customers. Without developing the right understanding, our chances of creating a successful product are slim. While there are numerous techniques available to uncover user needs—think of direct observation, problem interviews, focus groups, surveys, and prototypes, to name just a few—none of them is truly useful, if we do not empathise with the people that will use our product, if we do take a genuine interest in the individuals, and want to help them. Otherwise, we run the risk of pushing out feature after feature, without ever knowing why some stick, and others don’t. In the worst case, we build digital products that are harmful and encourage addictive behaviour, as we don’t see the humans behind the analytics data and financial numbers. Empathy in a Nutshell Empathy is our capacity to relate to each other on a very fundamental level: to understand other people's feelings and to take the perspective of the other person. Say a friend tells you how sad she is after splitting up with her partner. Your natural reaction will be to feel sad for her, to mirror her feelings. Or another friend shares with you how happy he is after finding a new job. You are then bound to feel happy for him. The best explanation of empathy I have found is the one below. While it is in our nature to empathise, there are some conditions that increase our ability to be empathic, while others decrease it. The following tips want to help you empathise with users and develop a deeper understanding of their needs. Empathy Tip 1: Meet Users Face to Face Meeting real users on a regular basis should be part of every product person’s job. Unfortunately, that’s not always the case. As product people, we are sometimes shielded from the users by management, sales, or support. But without meeting the beneficiaries of your product, you cannot truly understand their feelings and needs. In the worst case, you create an ineffective empathy map or persona based on hearsay and half-knowledge, but not on personal experience and insight—which is a common mistake in my experience. And while it’s great to have analytics and quantitative data available, I for my part find it impossible to empathise with numbers. Therefore, make sure that you meet users face to face and preferably in person, at least once every three months. While a video call call might work, I wouldn’t recommend it if you haven’t met the individual before, as it's harder to empathise with the person if you are not in the same room. Empathy Tip 2: Take a Genuine Interest in the Person Understanding another person requires a friendly, kind, and open attitude. Be respectfully curious about the individual’s thoughts and feelings, no matter if you find the person likeable or not. Now, that’s easier said than done for me, as I can be critical about others and myself. But I know that having the courage to openly engage with a "difficult person"—someone I find challenging to relate to—helps me see the individual for what she or he is: a fellow human being with hopes and dreams, worries and fears just like me. Additionally, appreciate the opportunity to meet users, and be careful not to view the meeting as a tick-box exercise, as this might instrumentalise the other person: You might be more interested in collecting the right information as quickly and efficiently as possible rather than engaging with the individual. But such an approach significantly reduces your ability to empathise and consequently collect the missing information. At the same time, be kind to yourself. Recognise that being worried, stressed, tense, tired, or restless will make it harder to be empathic. If you are not in the right frame of mind, it's more difficult to reach out and connect with others, as you are likely to be caught up in your own thoughts, emotions, and concerns. Similarly, if you are primarily concerned about your own success, if you are mainly motivated by meeting a business goal or improving a product KPI, then this is likely to get in the way of developing empathy. While every product has to provide a business benefit, you should try to let go of your own and your company's ambition to understand the person in front of you. Remember that only when a product addresses a real user need, will it be possible... - Published: 2017-09-18 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/choosing-the-right-planning-horizons-for-your-product/ - Categories: Product Roadmap, Product Vision and Strategy As product manager and product owners, we need to forecast the likely development of our products. This creates a shared understanding of the benefits and features a product will provide thereby aligning the development team and stakeholders. But which timeframes and planning horizons should we take into account? And how far into the future should we look? Read on to find out my recommendations. Planning Horizons and Planning Model “Bring me that horizon,” says Jack Sparrow at the end of the movie The Curse of the Black Pearl while steering his pirate ship into the open waters. While Jack may seek freedom rather than the line that separates earth from sky, he could easily determine how far it is—there is only one physical horizon on our planet, and the distance can be calculated using a standard formula. But in product management, there are several horizons that need to be considered—how many depends on the product planning model you use. Therefore, before determining timeframes, make sure that you have a suitable model in place like the one below, which I developed while writing my book Strategize. In the product planning model above, the vision describes the ultimate purpose for creating the product; the product strategy states how the vision will be realised; and the product roadmap states how the strategy will be implemented. The product backlog contains the details necessary to develop the product as outlined in the roadmap including epics and user stories. A sprint goal describes the purpose of a sprint and states why it’s worthwhile to undertake the sprint. Say I want to create an app that helps people become more aware of what, when, and how much they eat. My vision, then, would be to help people live more healthily; the strategy could be to create an app that monitors their food intake in conjunction with a smart watch or fitness band, and smart food scales. The product roadmap would communicate how the product is likely to grow, stating the benefits it should provide together with desired timeframes or dates. The product backlog might contain epics and user stories like “As Mary, I want to get an overview of my daily calorie intake,” and a sample sprint goal could be “validate that people are willing to share personal data before using the app’s main features” or “finish the dashboard so it can be released”. Timeframes With the right planning model in place, you can take the next step and consider appropriate timeframes. The picture below shows the planning horizons I like to work with. Note that the planning horizon in the picture above becomes increasingly shorter from vision to sprint goal while the planning artefacts become more specific and focused. This is due to a simple but fundamental correlation: the further we look into the future, the less we can see. What’s more, take the numbers stated as recommendations and adjust them to your product. Only look as far into the future as you realistically can—without resorting to speculation or wishful thinking. As the picture shows, I prefer to work with a big, ambitious vision like “help people eat healthily” that looks three to five years into future and thereby provides a continuity of purpose for everyone involved in developing and providing the product. When it comes to product strategy, I like to consider the current life cycle stage. For a brand-new product, the strategy should communicate what it takes to get to launch, enter the introduction stage, and serve the early market. After launch, the product strategy should describe how to achieve product-market fit and enter the growth stage. Once that’s happened it should state how to achieve sustained growth, and so forth. This may result in a planning horizon of six to 18 months for your strategy—even though some products require longer to leave a stage. Take the Apple Watch as an example. The product was launched in April 2015, but I am not convinced that it has entered the growth stage. Product roadmaps benefit from a twelve-months horizon in my experience (assuming the product strategy covers at least the next twelve months). Additionally, I like to include quarterly product goals on the roadmap like acquiring new users, increasing engagement, generating revenue, and removing technical debt. Shared goals create focus and alignment, and they make it easier to understand if the product is providing the desired benefits. While a product backlog may contain outstanding work for years to come, I find such a backlog unworkable in practice. Instead, I prefer to work with a concise product backlog that is focused on the next roadmap goal, as I describe in more detail in the article “The Product Roadmap and the Product Backlog. ” Such a backlog is comparatively easy to update and change—which is particularly helpful for young products. A sprint goal, finally, should cover the next one to two weeks, guide the daily work of the development... - Published: 2017-08-09 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/product-owners-and-technical-skills/ - Categories: Product Roles - Tags: product owner, skills, teamwork As a product owner, you look after a digital product and work with a development team. Does this mean that you require technical skills? Should you be able to program and write code? Or is it sufficient that you take an interest in software technology and leave the rest to the team? This post shares my answers and recommendations. How can you tell if you would benefit from having technical skills as a product owner? To answer this question, I find it helpful to look at how the role is applied. If you manage a digital product that end users employ, such as a web or mobile app, then you usually do not require in-depth technical skills, such as, being able to program in Java, write SQL code, or know which machine learning framework there are and if, say, TensorFlow is the right choice for your product. But if you look after a technical product—a product that is integrated into a larger offering like a physics engine, which forms part of a computer game—then you will require the appropriate technical skills in order to formulate technical requirements and define software interfaces (APIs). For instance, if you were responsible for a physics engine, then you would probably have to be able to program in C++, use UML, and apply the right software architecture and design patterns. The same applies if you are a component owner, someone who looks after an architecture building block like a service, component, or layer that forms part of a digital product: You will benefit from having hands-on experience in the appropriate technologies. Independent of your specific product job, you should take an interest in software technology and be aware of major trends like artificial intelligence (AI) and Internet of Things (IoT). I would argue that every product owner should have at least a basic understanding of core concepts, such as, object orientation, design patterns and architecture principles, as well as agile development practices, such as, test-first, refactoring, and continuous integration. This knowledge helps you make the right product decisions, for example, investigate how AI and machine learning can improve your product or allocate time for architecture refactoring work. It also helps you empathise with the development team and understand some of the challenges the team members experience whilst designing, programming, and testing the product. Learning to program can help you acquire the relevant knowledge—I am certainly grateful that I had the opportunity to learn to write code and architect software systems. But do make sure that you focus on your actual job—to ensure that your product creates as much value as possible for the users and your company. It’s more important that you understand the value your product creates for its users, who the product serves, what makes it stand out, and what business benefits it should deliver than being able to know if a layered or service-based architecture is more appropriate, for example. Additionally, don't interfere with the development team’s autonomy by making technical decisions, which can be tempting for product owners with strong technical skills in my experience. It’s the team’s job to decide how the product is built, not yours. If you feel that people lack the necessary skills to make the right technical decisions, then discuss this observation with the team in the next sprint retrospective and agree on the right improvement measures, rather than you taking over and telling people what to do. Finally, recognise that playing the product owner role and working in product management is as exciting as it is demanding. Don’t feel bad if you lack technical understanding. See it as an opportunity to learn and grow, and expand your product management practice. - Published: 2017-07-03 - Modified: 2024-09-30 - URL: https://www.romanpichler.com/blog/conflict-resolution-tips-product-managers-product-owners/ - Categories: Product Leadership, Stakeholder Management - Tags: product manager, product owner, stakeholders, teamwork Experiencing disagreement and conflict is part of our job as product managers and product owners. We work with a broad range of people from different departments, and it's only natural that we don't always agree and sometimes clash. But constructively navigating conflict can be challenging. This article shares my recommendations for dealing with difficult people and successfully addressing conflict. It's a Common Challenge “You just can’t make up your mind. I really wish that for once, you gave us clear priorities,” Jane said accusingly at the end of the workshop and walked out of the room.   It felt like a slap in the face, an unprovoked attack. How could she say something so wrong? Does this story sound familiar? I certainly find that as product managers and product owners, we sometimes have to deal with pushy, stressed, or unhelpful stakeholders and team members—with people who are just being difficult. If we reflect on the nature of our work, then this shouldn’t come as a surprise: Product management is as much about people as it is about products. Friction and conflict commonly appear when people from different departments work together. What’s more, innovation and effective teamwork are only possible if we can leverage conflict and disagreement. Don’t Ignore the Conflict It would be easy brush aside the issue and forget what Jane said. With so many things competing for your attention, should you really worry about Jane’s remark? But what would happen if you did ignore the conflict? Chances are that you would feel aversion towards Jane, even if you are not fully aware of it. Next time when you meet, this might cause you to say something you later regret, which would make things only worse. What’s more, tolerating wrong behaviour sets a precedence and creates an unhealthy work atmosphere; disrespect invites disrespect. Therefore, do not ignore conflict. See it as an opportunity to improve your product management practice and leadership skills. This, of course, is sometimes easier said than done: Addressing the issue requires courage. Jane might a powerful or influential individual like senior management stakeholder. Additionally, you have to be willing to honestly reflect on your own intentions and actions, and be open to change your behaviour. Regain Your Composure When exposed to unkind behaviour, it can be hard for me not to lose my calm. But before responding to Jane and telling her what you think, stop and reflect. Become aware of how you are, how you are feeling. Are you disappointed, upset, or angry? If so, then that’s ok.  But bear in mind that negative thoughts and emotions cloud your perception; they will make it difficult to have a constructive conversation with Jane. What’s more, negativity affects your own wellbeing; it makes you unhappy. Holding on to anger, a wise man once said, is like grasping a hot coal with the intent of harming someone else: The only thing certain is that you will get burned.   Even if anger, fear, or worries seem to have a tight grip on you, they will weaken and go away if you do not feed them. Acknowledge them, but do not engage and identify with them. Additionally, bring to mind the positive qualities of the difficult person. Jane surely can’t be all mean and evil. Think of moments when you saw Jane help others, make a constructive contribution, or commit other acts of kindness. Remind yourself that anybody who acts in unskilful ways must be unhappy deep inside. This will help you empathise with the difficult person and develop compassion, rather than villainising the individual and holding a grudge against her.  Finally, tell yourself that as human beings, we have all acted in inappropriate ways and said unkind things; I'm certainly not perfect by any means. Put Things into Perspective Next, ask yourself why you perceive the person as difficult. What makes the individual so hard to deal with? Why did you respond in the way you did? Why did Jane’s remark make you feel angry or hurt, for example? Was it purely because of what Jane said, or has it something to do with you? I notice that my own response to unskilful behaviour is particularly strong when deeply held opinions and beliefs are challenged. If I think of myself as someone who is decisive and knows what’s right for his product, then I am likely to be more affected by Jane’s remarks—independently of her intention. Similarly, I find that when I am stressed or tense, any wrongdoing I experience feels worse than when I am relaxed and content. Finally, look at the data and calmly consider what actually happened. Jane’s remark might have felt like a slap in the face. But did she mean to be nasty? And did you contribute to the conflict in any way? Was there anything unhelpful you might have said or done to Jane, intentionally or unintentionally? This doesn’t excuse Jane’s behaviour, of course. But it helps put things into perspective and move on from blaming... - Published: 2017-06-20 - Modified: 2023-02-06 - URL: https://www.romanpichler.com/blog/4-daily-scrum-tips-for-product-owners-product-managers/ - Categories: Product Management Process - Tags: product owner, scrum, self-organisation, teamwork The Daily Scrum is an important meeting for agile development teams: It facilitates self-organisation and helps maximise the chances of reaching the sprint goal. Despite its importance, the meeting is not always effective. This articles share my recommendations on how you as the product owner can help make the Daily Scrum a success. Tip #1: Know what it's all about The Daily Scrum meeting, sometimes also referred to as stand-up meeting, wants to help the development team manage its work. In Scrum, the team collectively agrees to a sprint goal and is responsible for meeting it. This includes tracking progress of the work on a daily basis and discussing any changes that may be required. The Daily Scrum supports self-organisation by encouraging the team members to talk about: The progress made by the team members; What people intend to work on next, and If anybody needs help—if there are any impediments or blockers. The Daily Scrum is meant to be a quick meeting that lasts no more than 15 minutes. It should be held at the same place and time every day; I find it’s best to have the meeting in the morning. Tip #2: Should you attend? I recommend that you participate in the Daily Scrum at least twice a week as the person in charge of the product. This allows you to understand what’s happening in the current sprint, and if and how you can help. You may find, for example, that some user stories are done and can be reviewed; or you may discover that the team is struggling with some acceptance criteria and requires your input. Additionally, you may want to ask the team to help refine product backlog items or update the product roadmap, for instance. Be aware that the meeting is not intended to solve any problems. Therefore, don’t turn it into a product backlog or roadmapping workshop. If you hear that the team members have questions about acceptance criteria, for example, then answer them after the meeting. Similarly, if you require the help of the team to work on the product roadmap, then hold a separate workshop. Additionally, don't forget to balance your various duties. These include not only working with the development team, but also meeting users and customers, and engaging with the stakeholders. If you religiously attend the Daily Scrum, then check if the balance is still right. Tip #3: Don't interfere Recognise that the meeting is not for you, but for the development team. Refrain from interfering with the team’s self-organisation and do not assign tasks or criticise individuals, as this would damage the team's autonomy and weaken the commitment. If you are concerned about the sprint progress, then say so in a honest but constructive way. Do not tell the team what to do. It’s up to the team members to manage the sprint and meet the sprint goal, and it’s up to you to manage the product and the entire release (made up of several sprints). If you find that the team members look at you and tell you what they have done, you know something is wrong: People report the project status to you instead of taking charge of their work. Therefore, share with the team what you see happening and ask people not to address you but each other. Alternatively, stop attending the meeting until you’ve discussed the issue in the next sprint retrospective where process improvements should be agreed (see below). Similarly, if it's hard for you not to suggest who should do what or what should be done next, then stop attending the meeting in order to give the team the necessary autonomy to self-organise and take full control of their work. You should also investigate why you find it hard to let go and trust the team to do a good job: Are you anxious to meet an ambitious product goal? Do you doubt the team's ability to meet the sprint goal? And what can you do to feel more at ease? Tip #4: Let the ScrumMaster do their job Know that it’s the ScrumMaster’s job to ensure that the Daily Scrum takes place and that it is effective. If you feel that something is wrong, however, that the team members don't track their work well, that people don’t attend the meeting or arrive late, or that the Daily Scrum often overruns, for instance, then discuss your concerns with the development team and ScrumMaster in the next sprint retrospective. But don't take on ScrumMaster duties. Remember that your job is to manage the product—not the team or process. If you don’t have a ScrumMaster or if the individual is not available or qualified, then recognise this is as an impediment to achieving product success that needs to be resolved—by hiring a qualified ScrumMaster or helping the... - Published: 2017-06-06 - Modified: 2024-01-22 - URL: https://www.romanpichler.com/blog/balance-your-portfolio-with-the-product-portfolio-matrix/ - Categories: Product Vision and Strategy - Tags: product life cycle The product portfolio matrix is a handy tool that helps you make the right product portfolio decisions. This post explains how you can effectively apply it to manage a portfolio of digital products. The Matrix Reloaded The product portfolio matrix, also called growth–share and BCG matrix, wants to help you achieve the right blend of young and established products in order to maximise the overall value a portfolio creates. The matrix categorises products as question marks, stars, cash cows, and pets (also known as dogs). The picture below shows the grid with its four quadrants and product types; cash cows are represented by the dollar sign and pets by a cross. Question marks are products with high growth that don’t yet deliver significant business benefits—be it generating revenue, selling other products or services, enhancing the brand equity, or saving money. Stars show high growth and deliver the desired benefits. Cash cows are products characterised by low growth, but they offer plenty of business benefits. Pets, finally, exhibit low growth and offer few benefits. When you apply the product portfolio matrix to the offerings in an established company, you’d like to see a healthy, balanced portfolio with enough question marks and stars that have the potential to become cash cows. You also need sufficient cash cows that generate the desired business benefits at a comparatively low cost and are therefore able to help fund the development of new products, question marks, and stars. Finally, you’d like to minimise the number of pets, as they incur cost but deliver only limited benefits. From Question Mark to Cash Cow The quadrants of the portfolio matrix form an interesting relationship: Products start out as question marks. If they are to become successful, they must develop into stars and then morph into cash cows. Both development steps require effort, time, and money. You may have to change or enhance the features, user experience, and architecture of the product; you may have to adjust the business model and opt for different marketing and sales strategies; and some products require a pivot—think of Youtube, which started out as a dating website, and Flickr, which was an online game before it became a photo-sharing website. Once a product has become a cash cow, it is able to offer the desired business benefits at comparatively low cost, as existing features are largely incrementally enhanced. A revenue-generating product is now most profitable (hence the term cash cow). Eventually, though, cash cows will lose their ability to provide business benefits and become pets. These products provide few benefits but still consume money to maintain them. The following picture shows the desired development sequence from question mark to pet. As every successful product will become a pet and eventually die, it is crucial that you are able to replace ageing cash cows with stars and stars with question marks. At the same token, you must invest enough in new product development initiatives to generate new question marks—assuming that you want to grow organically. Your product portfolio therefore requires regular adjustments, and portfolio management should be a common activity. As a rule of thumb, review your product portfolio once per quarter and initiate the necessary changes. Product Portfolio Matrix and Product Life Cycle As you may have noticed, the development sequence discussed above is correlated with the product life cycle: Question marks tend to be products in the introduction stage; stars are products in growth; cash cows are mature offerings; and pets are declining products. The picture below illustrates this relationship. Note that the picture above does not account for life cycle extensions—prolonging the life expectancy of a product by adding new features, optimising existing ones, creating variants, or taking it to a new market or market segment, for instance. Such a measure extends the product’s status as a star and prevents it from prematurely becoming a cash cow. Avoid these Common Mistakes In theory, the development from question mark to pet and retirement should be straight forward and result in a healthy portfolio. But in practice, I see companies make three common portfolio management mistakes: focussing too much on stars and cash cows, not retiring pets, and clinging on to unsuccessful question marks. Don't Focus too much on Stars and Cash Cows The first mistake is focussing too much on cash cows and stars and neglecting question marks and new product development initiatives, something particularly bigger companies are prone to in my experience. This is due to their tendency to optimise structures and processes for managing existing, successful assets, which makes it hard to deal with the amount of innovation and risk present in new and young products. But focusing too much on stars and... - Published: 2017-05-10 - Modified: 2024-11-05 - URL: https://www.romanpichler.com/blog/the-t-shaped-product-manager/ - Categories: Essential Articles, Product Leadership, Product Roles - Tags: product manager, product owner Product management is a multi-faceted discipline. This makes our work interesting and varied. But it can also make it hard to see which skills we need to develop so we can do an even better job or take on more responsibility. In this post, I discuss balancing product-specific skills with generic product management capabilities. I suggest developing a t-shaped skills profile that ensures that you have the necessary deep skills to progress your product, as well as the broad skills required to systematically deal with common, recurring product management challenges. Balance Specific and Generic Skills To do a great job as a product manager or Scrum product owner, you will benefit from two skill sets: a product-specific and a generic one. As their name suggests, product-specific capabilities focus on a specific product or product category. They include a deep understanding of the users with their needs, the competition, and the market trends. They also require you to have a deep knowledge of the product itself, including its value proposition, key features, user journeys, business goals, and KPIs. Finally, they imply an insight into how the company works and how things get done—what the company goals are, which processes are used, and who the decision makers and influencers are. As product-specific skills are crucial, I find that many product people strive to develop these capabilities. But as important as they are, they are not enough. In addition to deep product skills, you require generic or transferable product management capabilities, such as, effectively capturing the product’s value proposition, segmenting the market, validating product strategy assumptions, selecting the right KPIs, prioritising the product backlog, and analysing user feedback and data. These skills are not specific to an individual product, but transferable. They equip you with the expertise to methodically solve common product management challenges and they enable you to move between jobs and verticals if you wish to do so. Balancing the specific and generic skills leads to a T-shaped skills profile and makes you a T-shaped product person as the following picture shows. The horizontal bar is the ability to effectively apply product management concepts, techniques, and tools to different products in different markets and companies. The vertical bar on the T above represents the depth of related skills and expertise specific product, product line, or product portfolio. Grow Your Horizontal Skills Strong horizontal skills enable you to work methodically and manage different products in different companies. As these skills form a large set, I like to divide them into three subgroups: strategic, tactical, and leadership capabilities, as the picture below shows. Strategic skills include the ability to develop an effective product strategy, actionable roadmap, and working business model. Tactical skills help you capture requirements, manage the product backlog, and validate ideas for new features and feature enhancements. Leadership skills enable you to effectively guide the development team and lead the stakeholders, create an inspiring vision, and reach sustainable agreements, to name just a few. To become a competent product professional, you should strive to develop all three types of skills—leadership, strategy, and tactics. Even if you currently fill a tactical product role, increasing your product leadership and product strategy skills will help with your current job: You will be able to collaborate more effectively with the individual who sets the vision and decides the product strategy and earn their respect and trust. Additionally, it will enhance your employability, enable you to progress your career and take on a role that includes strategic responsibilities in the future. And competent and well-skilled product people increase the chances of innovating successfully and maximising the benefits digital products provide. To get started, explore how strong your skills in each of the three groups are. Ask yourself, for example, how much you know about creating and validating a product strategy, about product roadmapping, and business model development. Then focus on those skills where improvements will help you most with your current job. Here are some of the questions it asks you: Do you know how to formulate an inspiring vision for a product? Do you know how to make effective decisions and generate strong buy-in? Are you able to create and evolve product strategy? Can you describe different segmentation techniques? Do you know what a product strategy is and what its key elements are? Can you describe the business model of your product? Can you develop an actionable product roadmap that clearly states the specific outcomes your product should create? Are you able to select and apply the right KPIs? Do you know when and how to review, adjust, and change your product strategy and product roadmap? Do you know how to prioritise product backlog items? Can you state different prioritisation techniques and explain when which is most appropriate? Do you understand how to validate your product including the user experience and the features? Do you know when to choose which technique? Develop Your Vertical Skills Deep product-specific skills are important to make the right product decision and move your product in the right direction. Here... - Published: 2017-04-19 - Modified: 2025-09-04 - URL: https://www.romanpichler.com/blog/how-to-increase-your-product-leadership-power/ - Categories: Product Leadership - Tags: empowerment, product manager, product owner In this article, I explain how you can increase your ability to influence and guide others and boost your level of empowerment as the person in charge of a product. The Three Empowerment Factors in Product Management As product people—product managers and product owners—we usually don’t hold any positional power. Unlike a line manager, we cannot reward people by offering a pay rise or bonus, for instance. We cannot tell people what to do either, as the development team members and stakeholders don’t report to us. This puts us in a challenging position: We must lead others to achieve product success, but we cannot leverage traditional management instruments. Luckily, there are three power sources you can tap into to boost your level of empowerment: your referent and expert power and the support you receive from your organisation. The image below shows the three factors. Increase Your Referent Power Your first power source is your ability to influence others based on your personality and interpersonal skills. It’s the capability you can immediately boost simply by being a decent person. To do so, cultivate skilful qualities like empathy, compassion, courage, truthfulness, patience, humbleness. This will earn you the respect and trust of your followers and at the same time, it will make you a happier person. How cool is that? Stating a list of wholesome qualities is easy, of course. But putting them into practice when faced with tight deadlines, ambitious goals, or difficult individuals is hard. It’s all too tempting to fall back onto less skilful habits and become impatient, tense and stressed, say something we regret afterwards, or pass on the pressure to the development team. To boost your referent power, I recommend focussing on one virtue at a time and practicing it repeatedly—without expecting too much too quickly. For instance, if you find yourself getting impatient when talking to a development team member or if you dislike one of the stakeholders, then recognise this as an opportunity to practice patience or kindness—don't view it as a weakness or deficiency. Next, consider how you can take a small but concrete step to change your behaviour and strengthen the virtue. For example, take three deep breaths before answering a question from a difficult team member, try to understand the other person's needs, and communicate without any aversion or ill-will. (See my article "Dealing with Difficult Stakeholders and Team Members" for more guidance on this topic. ) Challenging situations are great opportunities to grow as a human being, and by doing so, you increase your ability to influence and lead others. Strengthen Your Expertise Knowledge is power, and your expertise is your second power source. The more you know, the more people will listen to you, trust and respect you, and follow your suggestions. To increase your expertise, strengthen your understanding of the market or domain and the product, as well as your product management savviness. Get to know your (target) users and customers, observe them using your product or competing offerings, talk to them about the problem the product should help them address or the benefit it should provide, and analyse any relevant analytics data you have to see how people currently interact with the product. As a rule of thumb, make sure you get out of the building at least once every three months. Nothing beats meeting real users. Additionally, keep an eye on market developments, new trends and technologies, and the competition. Do regular research, attend trade shows and conferences, and consult journals, magazines, and user forums, for example. You may want to combine reviewing the market development together with the product performance in form of regular strategy and roadmap review meetings (as I discuss in more detail in my book Strategize). But that’s not all. It’s great to know your product and market. But if you are not able to formulate a coherent product strategy, develop an actionable product roadmap, or prioritise the product backlog, then people are unlikely to regard you as a true expert. You should therefore also work on your product management skills and become a well-rounded product professional. “Intelligence is a privilege, and it needs to be used for the greater good of people,” says Doctor Octopus in the movie Spider-Man 2. Who could disagree with that? Secure the Right Support from the Organisation Your third power source as a product leader is the support offered by management. With the right management sponsor, you have a powerful ally at your side and a much better standing in the organisation. Consequently, you are more likely to be respected and followed. But unlike the other two power sources, you cannot control management sponsorship—it depends on the individuals involved and the degree to which... - Published: 2017-03-14 - Modified: 2023-01-13 - URL: https://www.romanpichler.com/blog/product-manager-vs-product-owner/ - Categories: Essential Articles, Product Roles - Tags: product manager, product owner, scaling, scrum For years, people have debated what the difference between the product manager and the product owner role is, if the roles can coexist or not, and which one should be used. This article shares my thoughts on the topic and reflects on the origin of the product owner role. What? As you might know, the product owner role originated in Scrum, where it is responsible for "maximising the value of the product ... " This sounds like a text-book product management responsibility to me. Nevertheless, the product owner is often regarded as a tactical role tasked with managing the product backlog, detailing requirements, and interacting with the development team. How come? There are two major reasons for this misunderstanding: The nature of Scrum and the use of the role in SAFe, which is a popular agile scaling framework. Scrum as a simple framework focused on helping teams develop complex products. It is not a product management framework. Consequently, it does not cover common product management practices, such as, product strategy development, product roadmapping, business modelling and financial forecasting; and the only product management tool it offers is the product backlog. Additionally, SAFe uses a product owner role which is different from the Scrum product owner. The latter has full-stack product ownership: The individual owns all aspects of a product, the vision, strategy, and tactics. But the SAFe product owner owns only the tactical product decisions and hence has partial ownership. Consequently, the role is complemented by a SAFe product manager who is outward-facing and makes the strategic product decisions, as shown in the picture below. Splitting product ownership in this way is a common scaling technique. But calling the tactical role “product owner,” as SAFe does, is an unfortunate mistake: Having two product owner roles with different levels of authority and responsibility creates confusion and gives rise to misunderstandings. Scrum vs. SAFe Product Owner Note that I have always viewed the Scrum product owner as an agile product manager. I would hence not agree with the notion that the product manager role is only outward-facing and strategic in nature. Traditionally, product managers were responsible for strategic and tactical decisions, for example, creating a product roadmap and a requirements specification. So What? So why did Scrum introduce the product owner role in the first place? Why didn’t the framework use the term product manager? An early version of Scrum did, in fact, use the product manager role. In a paper presented at the OOPSLA conference in 1995, Ken Schwaber who is one of the creators of Scrum and the individual who mainly coined the Scrum terms, used the term product manager. Subsequently, the name was changed to product owner, though. Here are three reasons for this change: First, when Scrum was developed in the 1990ies, product management was different from what it is today. Product managers used to do the upfront market research, product planning, and requirements definition work. They would then hand off a requirements specification to a project manager who would work with development and test to deliver the product. The product manager would return only to issue change requests or help with the product launch. This is in stark contrast to how things are done in an agile context, where product people are required to collaborate with development teams on an ongoing basis—without neglecting the users and the internal stakeholders. Secondly, Scrum is applied outside the realm of product development and commercial software products. Many organisations that have adopted Scrum like banks, retailers, and media companies traditionally don’t have a product management group and hence don't employ any product managers. But they do use digital products that either help market and sell their revenue-generating offerings, such as an online banking app, or they develop internal software assets that are used to automate business processes, increase productivity, and reduce cost. By offering the product owner role, these organisations can start working in an agile way without first having to establish a product management group and initiate an organisational change process. Instead, employees from the appropriate business units can—with some training and coaching—act as product owners. (In the long run, however, establishing a product management function may well be beneficial, as I discuss in my post Five Tips for Introducing Product Management to Your Company. ) Last but not least, the term product owner strengthens the idea that the person in charge of the product must be empowered and respected. This is particularly important in an agile context where collaboration is valued, and development team members and stakeholders frequently contribute to product decisions, for example, by discussing the latest product increment in the sprint review meeting. If no agreement can be reached, the product owner makes the necessary decision thereby avoiding a deadlock where people potentially argue for hours and... - Published: 2017-02-24 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/unanimity-based-product-decisions/ - Categories: Product Leadership - Tags: product manager, product owner, stakeholders, teamwork Unanimity is a powerful approach to take advantage of the collective wisdom of the stakeholders and development team members and generate strong buy-in and shared ownership of a decision. But it can be challenging to apply, and if used incorrectly, it can create mediocre results. This post helps you leverage unanimity to make successful product decisions. It explains when and how to use it, and it discusses common traps and how to avoid them. Benefits and Limitations Deciding by unanimity means that everyone required to make the decision agrees with it. Applied correctly, it results in better decisions and it creates strong buy-in and shared ownership. It is particularly helpful when the stakes are high and you have to make a high-impact or complex product decision, for example, if you should pivot, create a product variant to address new market segment. But unanimous agreement is certainly not a silver bullet. Do not use it if: You face an emergency and a decision must be made quickly, for instance, when you are in danger of missing a critical release date; The decision is low impact and no big deal; The people who need to contribute to the decision are not able or willing to collaborate, for example, the individuals cannot meet face-to-face. If that's the case, choose a different decision rule instead, for example, consent, majority vote, or product person decides after discussion. To take full advantage of unanimity, you require a collaborative mindset, a collaborative decision-making process, and a tool to help you understand if you have found a solution that everyone agrees with. Mindset To reach unanimous agreement, people must understand each other’s perspectives and feel and think together. This, in turn, requires that everybody involved in making the decision is heard and listened to. What’s more, people must have an open mind and let go of their preconceived notions and ideas, appreciate other people’s ideas, and jointly look for opportunities to discover with new, better ideas. If the individuals cling to their ideas and believes, if they think that they know best and that their ideas should win, or if they act in selfish ways and want to get the best deal for themselves or their department, then the group will struggle to reach unanimity. As the person in charge of the product, you should lead by example and demonstrate the right attitude, be collaborative and appreciate ideas even if they sound unconventional. You will also benefit from involving an experienced Scrum Master, coach, or facilitator who helps you with setting the ground rules and facilitates the discussion. Process Deciding by unanimity can take time and involve an element of struggle, particularly when you make a complex decision: Everyone required to contribute to the decision must have the opportunity to equally share their ideas and perspectives, and the group members must share diverse perspectives. Only after that’s happened can you start looking for common ground and convergence. The picture below depicts this approach, which is based on the book The Facilitator’s Guide to Participatory Decision-Making. At the start of the decision-making process depicted above, you want to encourage people to generate different ideas and share diverse perspectives using free-flowing open discussion or structured brainstorming, for example. Suspend judgment at this stage and don't criticise the ideas. You want to generate plenty of diverse suggestions before you evaluate them. Resist the temptation to prematurely reach agreement. Otherwise you may end up with a mediocre solution based on familiar options and weak buy-in. In the worst case, you experience design by committee where people broker a weak compromise—which is the opposite of what a unanimity-based product decision should deliver! Ensure that everybody fully participates and don’t allow individuals to dominate. Otherwise you won’t be able to leverage the collective creativity and knowledge of the group, and the decision-making process might get highjacked by the HIPPO and the decision dictated. Once everybody has been heard, take the next step. Encourage people to understand each other’s perspectives and motivations and look for common ground. This is likely to involve some struggle, as some individuals—possibly yourself—may still be attached to their ideas. Give them time to let go and embrace other people’s suggestions. Consider testing some of the ideas by running experiments—be it observing or interviewing users or exposing prototypes to them. Sort ideas into categories, distinguish opinions from facts, and summarise key points. A great solution often combines elements of different ideas, and it can significantly vary from what you had in mind at the beginning of the process. Finally exercise judgement using the data that you have collected and come to agreement. Participating in this process can be difficult: it requires that people tolerate ambiguity, constructively deal with conflict, let go of their own ideas, and embrace someone else’s suggestion. Choose a safe, comfortable environment; don’t rush the process and allow for enough time; and involve a skilled ScrumMaster or coach who helps you guide people through the process. Agreement Scale One of the... - Published: 2017-02-01 - Modified: 2024-02-02 - URL: https://www.romanpichler.com/blog/reflections-on-user-stories/ - Categories: Product Backlog & User Stories - Tags: product owner, teamwork User stories are a simple, straightforward tool. But successfully applying them can be surprisingly hard. This post offers four refections to help you improve your user story practice. Users As its name suggests, a user story describes how a user or customer uses the product--a digital product is captured from the perspective of the users. This avoids a solution-centric view where we worry more about how to provide and implement the product features than why and how people will use them. Understanding who the users are and how the product will benefit them is central to discovering and creating the right stories. In other words, if you do not know who your users are and what problem they want to see addressed or which benefit they would like to experience, then you should not create stories! Otherwise, you are in danger of speculating about the product features rather than deriving them from the user needs. I’d like to take this further and suggest that you should meet the users. This is not to say that the users will be able to correctly tell you what the product should do—it’s your job to figure this out.  I know that product managers and product owners don’t always have access to the users and are sometimes shielded from them by the sales team or management. I also understand that development team members tend to see users even less frequently. But if you want to leverage user stories to develop a successful product, then you should do try to observe and talk to the people who will use it. How else can you truly understand their needs and empathise with them? Conversation When I first came across user stories over 15 years ago, I was surprised by their lack of detail. I was used to working with use cases, and it took me a while to get my head around their sketchiness. They seemed less like requirements and more like notes. And that’s exactly what stories are meant to be—notes that capture the essence of a conversation. On its own, a user story is pretty useless. It needs to be complemented with a conversation between the person in charge of the product, the product manager or product owner, and a cross-functional development team. Maybe it’s helpful to take a quick look at the context in which user stories emerged. Stories were first used in Extreme Programming in combination with the role of an onsite customer. The onsite customer is a member of the user community who is collocated with the development team. The individual would discuss with the team what should be built in the next iteration, and captured the conversation as stories to remind everyone of what was discussed. Agile approaches happily accept tacit knowledge, knowledge that is not explicitly expressed and written down, and they prefer face-to-face conversation over documentation. Why? To speed things up, to allow the team to quickly implement some functionality and to validate it by exposing it to the users. I find it even better to co-create user stories by inviting the development team members to help discover new stories and amendments to existing ones—based on the feedback and data gathered from the users. This leverages the team’s collective knowledge and creativity and tends to result in better, clearer stories. To do so, make collaborative story work part of your product backlog grooming or refinement process. But if you cannot have at least a meaningful conversation, if product owner and team cannot discuss new stories together so that the team understands the stories and can make suggestions for improving or splitting them, then you should not use user stories. The conversation is not optional; it is an essential part of user stories. Without it, the story is not usable or it becomes bloated with details.  If you find that you need to capture more details or hand-off requirements, then use a different approach like use cases instead. Use cases tend to be more effort to create and update but they offer more structure. They come with pre- and post-conditions, triggers, a main success scenario, alternative success scenarios, and exception scenarios. This allows you to describe the product functionality in more detail, which may be necessary when working with remote teams. Simplicity User stories are a very simple tool—we simply tell stories about how users are likely to interact with the product and capture their essence. That’s it. Unfortunately, I have seen a fair amount of stories that were far from simple and straightforward. I find it helpful to remember that in the early days of agile, people didn’t talk so much about user stories. Instead, they used the term story cards. The reason for this is simple: stories were captured on paper cards. These have two advantages: they facilitate collaboration and visualisation. Everybody can write on... - Published: 2017-01-25 - Modified: 2022-04-28 - URL: https://www.romanpichler.com/blog/when-should-product-backlog-refinement-take-place/ - Categories: Essential Articles, Product Backlog & User Stories - Tags: product owner, refinement, user feedback A refined product backlog facilitates the development of a successful product: It incorporates new insights and learning, and it provides items that are ready to be implemented. But when should you work on the backlog? Before the new sprint starts or afterwards? And how can you decide which option is appropriate? In this post, I discuss four options with their benefits and drawbacks to help you make the right choice. Option 1: In the Sprint Review Meeting Your first option is to work on the product backlog in the sprint review meeting. Assuming that the development has developed a "done" product increment and the right people are present, you can use the attendee's feedback to make the relevant product decisions and update the product backlog, as the Scrum Guide suggests and the following picture shows. This approach ensures that the backlog is updated before the next sprint starts. This allows you to immediately action any new insights thereby mitigating the risk of taking the product in the wrong direction. Additionally, the backlog is collaboratively worked on. This creates strong buy-in from the people participating in the sprint review meeting. But it only works if the attendees are able to provide relevant feedback, are willing to collaborate and can quickly agree on the necessary backlog changes. What's more, the feedback must not require further analysis or give rise to bigger product backlog changes. Don't use this option if a significant amount of uncertainty and change is present in your product backlog, for example, if you work on a new product or extend your product's life cycle. Option 2: In a Separate Workshop Prior to Sprint Planning Your second option is to have a separate product backlog workshop prior to the next sprint planning meeting. The workshop should include you as the Scrum product owner, the development team, and the Scrum Master. Collaboratively analysing the data and working on the backlog, mitigates the risk of drawing the wrong conclusions due to cognitive biases like confirmation bias; it leverages the creativity and knowledge of the team, increases understanding and buy-in, and leads to better requirements. As the picture above illustrates, my preference is to hold the workshop right at the beginning of the next sprint. This violates the Scrum rule that the sprint planning meeting must be the first event in every sprint. But it allows you to respond to the feedback in the subsequent sprint without rushing or dropping the sprint retrospective or working late or at the weekend. What's more, it provides the benefit of separating the data collection from the analysis: It enables you to review the feedback without the people present who provided it. It also give you more time to assess the feedback, derive the right insights, make the right product decisions, and change the product backlog accordingly. This makes it easier to deal with difficult feedback and requests, and to carry out bigger product backlog changes. Note that this approach still assumes that you can collect the relevant feedback in the sprint review meeting, for instance, by carrying out a product demo, usability test, or solution interview. If you decide to release the product increment to (selected) users, then this option is unlikely to be appropriate for you, as it often takes several days to collect the relevant data in my experience. Option 3: In a Separate Workshop After Sprint Planning If you validate your product decisions by releasing software to (selected) users, then this option may suit you. It suggests that you hold a product backlog workshop involving the development team and Scrum Master after the next sprint planning has taken place, as the picture below shows. This approach assumes that you require several days to gather the relevant user data before you can analyse it and make the appropriate backlog changes. It also assumes that you don't have to wait for the data to arrive to decide on the next sprint goal. Instead, you can continue with the next sprint while collecting the data. While option three allows you to validate your product quantitatively, it too has a drawback: As sprints are protected, the earliest point in time you can respond to the backlog changes is sprint+2. It is therefore advisable to start with option one and two, and use option three once the crucial risks in the backlog have been addressed. Additionally, you should focus on different features in sprint n+1 compared to sprint n in order to avoid the danger of continuing to move your product in the wrong direction. Option 4: Continuously If you don't need to wait until the end of the sprint before you release a new or improved piece of functionality, then you will benefit from continuously collecting data, analysing it, and changing the product backlog accordingly. You may want to set a side 30 minutes every morning to look at the latest data and draw the right conclusion from it, preferably with the help of the development team or some of its members. Note that option... - Published: 2017-01-12 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/make-your-product-stand-out-with-the-strategy-canvas/ - Categories: Product Vision and Strategy Few products are ground-breaking innovations with zero competition. Chances are that alternatives for your product exist. You should therefore ensure that your product stands out from the crowd and that people have a compelling reason to choose it over competing offerings. The Strategy Canvas is a great tool to achieve this, as I explain in this post. The Strategy Canvas The Strategy Canvas was developed by Kim and Mauborgne, the authors of Blue Ocean Theory. It was originally intended as a business strategy tool to discover new markets. Luckily, the canvas can also be applied to individual products, as the following example illustrates. The Strategy Canvas above ranks the first iPhone against its rivals, including the Nokia N95 and the BlackBerry Curve. The horizontal axis of the canvas captures the key factors companies compete on to provide their products. In the example above, there are twelve factors, which range from offering different models to stylish design. The vertical axis of the Strategy Canvas describes the offering level, the degree to which the competitors offer the factors. Video, for instance, was not offered on the original iPhone but it was provided by its competitors; a camera was available on the first iPhone but it’s quality was inferior compared to the competition; but its media player was better, and the iPhone offered two new factors, a touch screen and a stylish design. By assessing the degree to which the iPhone and the competitor products fulfil the twelve factors, two lines are created. The dark one represents the value curve of the smartphone industry in 2007; the light one the first iPhone. When comparing the two lines, we see that the they diverge. This means that the first iPhone was clearly differentiated. Apple achieved this by removing certain features, such as physical keyboard, stylus, and video; reducing some, including voice quality and e-mail integration; and improving others, for example, mobile Internet and media player. Additionally, the two new factors—the touch screen and stylish design—gave the phone a significant competitive advantage and helped Apple disrupt the mobile-phone market. The sample canvas is based on Disruptive Product Innovation Strategy: The Case of Portable Digital Music Players. Applying the Canvas to Your Product Before applying the Strategy Canvas, you should be clear on your product's value proposition—the main problem it solves or the primary benefit it provides—and the market segment you want to serve. I capture these pieces of information using my Product Vision Board. (The canvas therefore complements the board in my approach. ) Additionally, you should know who your main competitors are. Start creating the canvas by determining the key factors. Make sure you choose those factors that define the current standard in your market and are used to advertise and sell products, rather than the ones that favour your own product. Product reviews and test reports can help you discover the right factors, since they compare a product against the expected standard. Additionally, limit the number of factors you use to about ten. This creates focus and avoids an overly complex canvas. With the key factors in place, rank the competing offerings and your own product taking into account the degree to which they fulfil the factor. This is not meant to be a scientific exercise but based on the information you have collected whilst identifying the key factors. Consider if a factor is fulfilled not at all, hardly, to some extent, or fully, and rank the products accordingly. With the scores in place, represented as dots or circles, connect them to create the value curves. Think about joining up the curves of the competitors to create clarity, as I did in the Strategy Canvas above. While this carries the risk of overlooking some details, it simplifies the canvas and makes it easier to see where the main opportunities are for making your product stand out. If the value curve of your product is too close to the curve of the competition, then you haven’t differentiated your product sufficiently. You will subsequently find it hard to explain to your users and customers why they should choose your product. What you would like to see instead is a value curve that significantly diverges from the industry standard, like the white-dotted one in the Strategy Canvas above. This is achieved by eliminating, reducing, and raising the appropriate key factors, and by creating new ones. The Eliminate-Reduce-Raise-Create Grid can help you with this. Use the Strategy Canvas not only for brand-new products. Regularly check if an existing product is still adequately differentiated or if the competition has caught up with it. Take the iPhone. If we consider how the smartphone market has changed since the launch of the iPhone, we see that the competitors have matched the original iPhone’s features. Trying to stay ahead of the competition, Apple has introduced and raised several factors over the years, including the ability... - Published: 2016-12-05 - Modified: 2023-06-13 - URL: https://www.romanpichler.com/blog/decision-rules-to-make-better-product-decisions/ - Categories: Product Leadership - Tags: product manager, product owner, stakeholders, teamwork As product managers and product owners, we make a myriad of decisions—from shaping the product strategy and determining the product roadmap to deciding the detailed functionality of our products. But do we make all these decisions effectively? And do we always secure the necessary buy-in? This post helps you make better decisions. It discusses five common decision rules and explains when to apply them. Decisions, Decisions “Is everybody OK with changing the product goal for Q3? ”, asks Julie, the product manager. As nobody says anything, she assumes that everyone agrees. She thanks people for attending and closes the meeting. But in reality, most people are still thinking about the change proposed. To make things worse, it’s not clear who has the final say on product roadmap changes. Is it the product manager, the attendees, or the management sponsor? If it’s unclear how a decision is made and whose input is required, people will be unsure if a decision has actually been made and if it should be actioned. Some people will start to implement the decision, while others ignore it instead of following it through. But if you want people to move together in the same direction, you need to give them a clear indicator if a decision has been made: you should clearly state how the decision is reached and whose input is required. In other words, you should apply the right decision rule. There are six common decision rules, unanimity, consent, majority vote, product person decides after discussion, delegation, and product person decides without discussion, which I explain below. I base my description on the books The Facilitator’s Guide to Participatory Decision-Making and We the People. Unanimity Deciding by unanimity means that everyone required to make the decisions supports the proposed solution or idea. A unanimity decision creates strong buy-in and shared ownership, and it leverages the collective creativity and knowledge of the people present—everybody involved contributes to the decision. It is particularly helpful when the stakes are high and you make a strategic product decision, for example, if you should pivot, create a product variant to address new market segment, or change the goal of the next major release on the product roadmap. The drawback of this approach is that it can take a comparatively long time to reach unanimity within a group, as it requires developing a mutual understanding and evaluating competing ideas. You may even have to schedule several meetings to come to a conclusion, particularly if you test different ideas as part of the process. Watch out that an unanimity-based approach does not degenerate into design by committee where people agree on the smallest common denominator and broker a weak compromise. This is unlikely to result in a sustainable agreement and translate into a successful product. As the saying goes, “a camel is a horse designed by a committee. ” Similarly, don't allow an individual to dominate and high-jack the decision-making process. Unanimity does mean that everybody is happy with the decision and fully supports it. When applying this decision rule, you will benefit from an experienced facilitator who guides everyone through the decision-making process and helps people reach agreement. Your ScrumMaster or agile coach might be able to help you with this. Consent Consent is the absence of objections: A decision is made when nobody disapproves. Deciding by consent requires that a proposal has been created—either as part of the decision-making process or by delegating the task to another group. Once the proposal has been discussed and a shared understanding has been established, ask the participants to clearly state if they object or consent to the proposal. If there are any objections, investigate their causes and ask why people object. Then amend the proposal or ask a group of people to rework it. Iterate the steps above until everyone involved in the decision-making process can live with the proposal and has no longer any meaningful objections. Applying this decision rule is beneficial when you don’t have the time to decide by unanimity or a good-enough solution is sufficient. Remember the product roadmap scenario from the beginning of this article? Using consent would have been a great way to understand if the development team and stakeholders agree with the proposed roadmap change. The drawback of the decision rule is that does not give you the same degree of buy-in as unanimity: Not objecting to a proposal does not necessarily imply that people are happy to support it. When deciding by consent, be careful not to shortcut the decision-making process by subtly pressurising people to agree or not considering all meaningful objections. For consent to work, everyone involved in the decision-making process must be OK with the proposal—no matter which role the person plays or how junior the individual might be. Majority Vote As its name suggests, majority vote means that more than half of the people required to decide agree with the proposed solution... - Published: 2016-11-22 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/should-product-owners-be-servant-leaders/ - Categories: Product Leadership - Tags: product manager, product owner Being an effective product professional requires leadership: Product management teams, stakeholders, and development teams need guidance and direction to collaborate and achieve product success. Can the servant-leadership model help you with this challenge? What Is Servant-Leadership? Servant-leadership is a leadership model that is based on the idea that “one wants to serve, to serve first. Then conscious choice brings one to aspire to lead,” writes Robert Greenleaf, the creator of the model. Leaders should “make sure that other people’s highest priority needs are being served” so that they “become healthier, wiser, freer, more autonomous. ” Sounds crazy? To me, servant-leadership means leading from the heart: recognising that genuinely caring for the people we work with and building strong relationships with them are prerequisites for achieving great things together. If we don't empathise with the people we want to lead, they are unlikely to trust and follow us. Caring for the followers, the people we work with, is not unique to servant-leadership. It plays a key part in other leadership approaches, too. Transformational leadership urges leaders to show genuine concern for the needs and feelings of their followers, for example, and Goleman’s leadership styles recognise affiliative leadership as an approach that puts people first.  In Scrum, servant-leadership has long been regarded as the default leadership approach embodied by the ScrumMaster. Can Servant-Leadership Benefit You? Servant-leadership encourages you to reflect on our motivation to be a product leader. Why do you aspire to lead others? Is it to succeed together and help the people grow and develop? Or is it to gain status, power, or money? There is nothing wrong with gaining respect plus a bonus or pay rise. But if these motivators dominate your thinking, there is a risk of not primarily caring for the people you lead but rather seeing them as means to advance your ambitions. This will negatively affect your relationship with them and reduce their willingness to trust and follow you. Servant-leadership also helps you question your approach to achieving success. Is the end—a successful product—more important than the means—how we got there? Do you expect that people just do their job, perform, and deliver? Are working extra hours and weekends normal to get a product out? Or do you take a genuine interest in the people you work with, show kindness to them, and encourage the development team members to go home when they look tired and worn out? Don't get me wrong—I am no utopian. I know that great products are the results of hard work. But if you want sustained success and a work environment that is healthy and conducive to creative work, then you must care for the people you lead. This starts with taking a real interest in the individual, making an effort to be present, and attentively listen to them. The beauty of this approach is that it benefits not only your followers, but it is beneficial for you too. Being kind and caring makes you a happier person, and it increases your referent power. This, in turn, makes it more likely that other trust you and follow your lead. - Published: 2016-11-02 - Modified: 2023-02-15 - URL: https://www.romanpichler.com/blog/ten-product-backlog-tips/ - Categories: Essential Articles, Product Backlog & User Stories - Tags: product delivery, risk, teamwork, user feedback Working with the product backlog can be challenging, and many Scrum product owners wrestle with overly long and detailed backlogs. This article shares ten practical tips that help you take full advantage of your product backlog. 1 Complement your Product Backlog with a Product Roadmap I find that the product backlog is best used to capture the product details. In this sense, it is a tactical tool that facilitates product delivery. If that's the case, then you will benefit from completing your product backlog with a product roadmap. A product roadmap sketches the overall journey you want to take your product on. I like to work with goal-oriented product roadmaps, which contain product goals that describe the benefits or outcomes your product should create in the course of the next six to twelve months.  This picture below illustrates this setup. 2 Focus your Backlog with a Product Goal Use a product goal like acquiring users, increasing conversion, or future proofing the product by reducing technical debt to direct and focus your product backlog. Any items in the product backlog should help meet this goal. If that's not the case, you should remove them. While this approach may sound radical, it will result in a concise product backlog that is comparatively easy to update and change If you complement your product backlog with a product roadmap that contains the product goals your product should meet, as I recommended in tip #1, you can use the next goal on the roadmap and copy it into your product backlog. This nicely connects your product backlog and product roadmap. 3 Start with a Short and Sketchy Product Backlog Starting with an incomplete product backlog with largely coarse-grained items is particularly beneficial when you create a new product or add new features. Collect the user and customer feedback on early product increments to decide which functionality should be implemented, to evolve the product backlog, and to refine its items. Note that is alright to have a longer, more detailed backlog when your product is mature and your focus is on incremental changes and bug fixes. 4 Collaborate with the Development Team Involve the development team members in the product backlog work, for example, by running collaborative product backlog workshops. This allows you to benefit from their knowledge and creativity and discover technical risks and dependencies. It also increases the understanding and buy-in of the team members and results in better, clearer requirements. Ask your Scrum Master to facilitate the sessions to help you focus on offering product leadership while ensuring that everyone is heard and nobody dominates. 5 Prioritise the Backlog Use uncertainty and risk to decide how soon an item should be implemented. Addressing uncertain items early on allows you to test your ideas, to fail fast, and to learn how to continue. Complement risk with cost-benefit and take into account dependencies when necessary. If you struggle to prioritise your product backlog, see my article "Prioritising a Product Backlog When Everything is Important. " 6 Get the Backlog Ready A key purpose of the product backlog is to direct the work of the development team: High-priority items are pulled into the sprint transformed into a product increment. To ensure that this can happen, you have to break larger items into smaller ones until they are ready for sprint planning: the items should be clear, feasible, and testable. This facilitates choosing a realistic sprint goal, and it helps the development team members do their work without having to constantly ask you for clarification during the sprint. 7 Regularly Update the Product Backlog The product backlog is not a static, fixed plan. Instead, it evolves based on the insights you gain from collecting user feedback and building the product. You should therefore regularly update and refine it together with the development team. Analyse the feedback and data collected from exposing the latest product increment to the users and apply the new insights to the product backlog: remove and add new items, and update existing ones. This maximises the chances of building a product that users want, and it keeps the product backlog up concise and usable. 8 Say No Have the courage to say no and decline ideas and requirements that do not help you meet the product goal and move you closer to realising the product vision. This ensures that your product has a clear value-proposition, and it prevents your product from getting bloated. If the idea or requirement is important but cannot be realised in the next months, then consider adding it to the product roadmap. 9 Look beyond User Stories While user stories, and functional requirements in general, are important, they are usually not enough. Also consider the user... - Published: 2016-10-21 - Modified: 2025-02-18 - URL: https://www.romanpichler.com/blog/mindfulness-tips-for-product-managers-and-product-owners/ - Categories: Product Leadership - Tags: mindfulness, product manager, product owner As product managers and product owners, we are busy people with a diverse range of responsibilities. This makes it all too easy to hurry from one meeting to the next, to try to accomplish several things at once, and to get lost in the busyness of our work. Unfortunately, this approach is not only unproductive, it also affects our wellbeing. Mindfulness offers a different path: becoming more aware of what we do and how we do it so we can make better decisions and be more creative. This post shares six practical mindfulness tips to help you work better and feel happier. What is Mindfulness? Mindfulness means paying attention to the present moment, to what is actually happening. It helps us become more aware of what we think and feel, and how we are—content, tense, relaxed, stressed, happy, angry, indifferent, restless, worried, or calm. But what’s the big deal? Surely all of us know how we are. But do we really? I find I can be so busy and caught up in activities, thoughts, and emotions that I am not (fully) aware of how I am and what’s going on in my mind and around me. Here is a simple test: Close your eyes and gently observe your breath. Chances are that your concentration is quickly interrupted by a thought or feeling, such as, “I must not forget to look at the latest analytics data,” or “I wish the sales guys were less pushy”. I find that if I am preoccupied with thoughts and ideas, likes and dislikes, then this colours my perception of reality. When I am happy and content, everything seems OK—even an nagging problem with my website isn’t that bad and can wait. But when I am discontent, tense, or tired, small things can seem big and bad. The website issue is now a major disaster that must be resolved immediately. Mindfulness helps me respond in an appropriate, skilful way. It reduces the risk that I misjudge things and take the wrong actions. Practising mindfulness has been very beneficial for me personally and for my work. Why is Mindfulness Beneficial for Product People? Mindfulness provides a number of well-known benefits, such as, improved creativity, productivity, and wellbeing, and it has become popular at companies like Apple, Google, and Nike. I find that mindfulness is particularly helpful for product managers and product owners. There are two main reasons for this: First, we have a demanding, multi-faceted job that requires us to carry out diverse tasks—from shaping the product strategy, providing input to the marketing collateral, analysing user data, to crafting user stories together with the development team. This broad range of duties combined with little or no power to tell others what to do, makes our work interesting and demanding. But it carries the risk of becoming restless and stressed, and in the worst case, fall ill or change jobs. Mindfulness helps us become aware of how we really are, so we can early adapt what we do and how we do it. Secondly, a major success factor for every product person is to develop empathy for the users and customers. If we do not care about the people who should benefit from the product, if we are not genuinely interested in solving one of their problems or providing a real benefit to them, we will struggle to offer a product that does a great job and becomes successful. Luckily, mindfulness practice strengthens our capacity to empathise with others—and ourselves. It teaches us to be calm, open and non-judgemental, qualities that I have found extremely useful when interacting with users and customers as well as internal stakeholders, such as, senior managers and sales reps. Tip #1: Don’t Rush As product managers and owners, we are prone to overcommitting and taking on too much work. With so many responsibilities, it seems logical to work as hard and fast as possible. But rushing from one task to the next and from one meeting to another is likely to reduce your productivity. As the old saying goes: Haste makes waste. If I rush things, then I am likely to make mistakes. What’s more, I get tense, restless, and stressed. This reduces my attention span and it negatively impacts my sleep. In the worst case, I am trapped in a downward spiral, getting more and more irritable and finding it increasingly hard to keep up with the demands at work. Do whatever you do purposefully and at a sustainable, healthy pace. Don’t cram too much into your day. If you feel that there is too much work, then prioritise ruthlessly and learn to say no. Focus on the most important tasks; delegate or postpone. The development team may be able to refine some of the user stories without you, for example. The sales team may not require a separate update on the new release, if you encourage them to attend the next sprint review meeting. A simple trick that helps me stop rushing is to walk mindfully, as you would when you go for a nice walk. Here is one example of how this... - Published: 2016-09-19 - Modified: 2023-10-09 - URL: https://www.romanpichler.com/blog/is-scrum-right-for-your-product/ - Categories: Product Management Process - Tags: product life cycle, scrum Scrum offers a powerful way to develop products. In fact, it is often seen as the standard way to create digital products, and I have met more than one company where the product managers were suddenly told to be agile and do Scrum. But like every process, Scrum has its benefits and limitations. Is it the right approach to develop and grow your product? Or would you be better off using an alternative? When is Scrum Most Helpful? A process like Scrum is a great fit for your product when it is brand-new or young, and when you extend its life cycle, as shown in the picture below. This means that not every product will benefit from Scrum: Products that are maturing or declining won’t benefit from Scrum—at least not to the same degree. The picture above shows the traditional, bell-shaped product life cycle curve with three key events: launch—the product first becomes available; achieving product-market fit (PMF)—your product is ready to serve the mainstream market; and end of life—you decide to discontinue the product. Note that your product’s actual trajectory may differ significantly from the one above: it may be much steeper or flatter. To to leverage the product life cycle model, you have to define the business benefits your product delivers and then track them over time. For revenue-generating products, revenue is commonly used, for example. But if your product exists to sell another product or service, then the number of active users might be the appropriate metric. The younger your product is, the more it is likely to benefit from Scrum. Why? When working on a brand-new product, trying to achieve PMF, or struggling to keep the product growing, you typically face many unknowns and a substantial amount of uncertainty and change. You may not fully understand the value it should create for its users and customers, the features and user experience (UX) it should provide, the business goals it should serve and the business model it should use, and the technologies that should be used to develop it. Scrum is a great fit at this stage: Your product will benefit from an iterative, cyclic process that allows you to quickly test an assumption, address a risk, generate new insights, and come up with new ideas. This accelerates learning and mitigates the risk of developing the wrong features, providing the wrong UX, and applying the wrong technologies, as I describe in more detail in my post The Scrum Cycle. But as your product grows and eventually matures, the amount of uncertainty and change gradually declines. After achieving PMF, you usually understand how to meet the user needs, and know how to develop, market, and sell the product to the mainstream market. Your focus tends to switch to penetrating the market and fending off competitors by keeping your product attractive and refining it. This typically results in smaller, often incremental product changes. A good example is the latest iPhone 7, where Apple largely optimised existing features like camera and battery life. Scrum consequently becomes less helpful at these life cycle stages: The development team members are often no longer required to work together towards a shared goal to test an assumption or to deliver a piece of functionally. If, however, you decide to revitalise a maturing product and extend its life cycle, for instance, by taking it to a new market or unbundling a bigger feature, you usually face a significant amount of uncertainty and change. In the picture above, the life cycle extension is shown by the arrow that reverses the ageing process of the product and takes it back into the growth stage. In this case, Scrum becomes helpful again! If you are in doubt if you should use Scrum or not, consider how much uncertainty is present in your product. Do you understand how to address the market needs and solve the users’ problem? Do you know how to develop, market, and sell the product? And more specifically, can the users confidently tell you which functionality they require and which aspects of the product need to be improved? Do you mainly provide incremental enhancements or bug fixes? Are the architecture and technologies fit for purpose and stable? Are you regularly struggling to agree on a shared, meaningful sprint goal? If the answer to these questions is yes, then Scrum is probably not the best framework for your product. To gain more clarity, use the next sprint retrospective to investigate if your process is still helpful, or if you should switch to an alternative. What’s the Alternative? Once your product no longer exhibits a significant amount of uncertainty and risk, is growing steadily, or has started to mature, a Kanban-based process may be the right choice, as the following picture illustrates. Unlike Scrum, Kanban does not regard protected, goal-driven iterations as mandatory. You can use it to implement an agile process with the flexibility to work on different items... - Published: 2016-08-16 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/product-roadmap-vs-release-plan/ - Categories: Product Roadmap - Tags: GO product roadmap, release burndown, scrum Release planning and product roadmapping are both important practices to achieve product success. But what’s exactly the difference between a release plan and a product roadmap? How do the two tools fit together? This post answers these questions so you can apply the two planning artefacts effectively. What is a Release Plan? A release plan forecasts how a major release is developed. It’s a type of project plan—albeit an agile one—and it usually covers the next three to six months. I use the term major release to refer to a version of your digital product that introduces a noticeable change, for instance, by adding or optimising functionality or enhancing the user experience, and it typically results in a new product version—think of Windows 10 or iOS 9. 3, for example. Release plans come in different shapes and sizes depending on the process used. In Scrum, the release burndown chart is the default release plan. It helps you track the progress from sprint to sprint, anticipate if the relevant product backlog items can be delivered on time and budget (or how long it will take and how much it will cost), and make the necessary adjustments, such as, reduce or remove a feature, or add a new team member to the team. The following picture shows a sample release burndown chart. In the chart above, the vertical axis captures the remaining effort in the product backlog required to create the next release, and the horizontal axis captures the number of sprints necessary or available to develop the release. The first data point on the chart is the estimated effort of the entire product backlog before any development has taken place. To arrive at the next data point, you determine the remaining effort in the product backlog at the end of the first sprint. Then draw a line between the two points. The burndown line shows the progress that has been made, and after a few sprints you should see a trend emerge and be able to forecast future progress. The forecast is represented by the dotted line in the chart above. What is a Product Roadmap? A product roadmap communicates how a product is likely to evolve across several major releases. Unlike the release plan, it is a product plan that looks beyond an individual project or release: It describes the journey you want to take your product on over the next 12 months or so—much like a roadmap helps you plan a road trip. Product roadmaps vary in their format. I prefer to work with goal-oriented roadmaps (also called outcome-based roadmaps). As their name suggests, these roadmaps focus on the goals the upcoming releases should provide. The picture below shows the GO Product Roadmap, a specific goal-oriented roadmap format that I have created. You can download the roadmap template from romanpichler. com/tools or by clicking on the following image. Let’s take a quick look at the rows of the GO roadmap in the picture above from top to bottom. The first row captures the date or the time frame when a new product release should be available—for example, 1 March 2015, or first quarter 2015. As explained in my post 10 Tips for Creating an Agile Product Roadmap, I recommend using dates or timeframes on internal product roadmaps and omitting them on external ones, that is, on roadmaps that are shown to (prospective) customers. The second row states the name of the release like iOS 9. 3 or Windows 10 mentioned before. The third row is the most important part of the GO roadmap. As its name suggests, it states the goal you want to achieve, the benefit you want to offer. You can think of the goal as a release goal if you work with major releases that package up feature enhancements or releases to make them available at the same time to the users. Sample goals include acquiring users, improving the user experience, and removing technical debt. The fourth row lists the product’s features that are necessary to meet the goal. Derive the features from the goals and ensure that they help create the desired benefits. Focus on what really counts; limit yourself to five features per goal, and keep the features coarse-grained. The fifth and final row captures the metrics to determine if a goal has been met—for example, x amount of users employ the product for at least thirty minutes per day within two weeks after the release becomes available. Stating the metrics ensures that the goals on your roadmap are specific and measurable. How do the Release Plan and Roadmap Relate? I find it helpful to think of the product roadmap as a high-level plan that sketches out the major stages of a road trip, including overnight stops. The release plan then states how each... - Published: 2016-07-20 - Modified: 2024-09-30 - URL: https://www.romanpichler.com/blog/10-tips-creating-agile-product-roadmap/ - Categories: Product Roadmap - Tags: GO product roadmap, stakeholders, teamwork, validation A product roadmap is a powerful tool to describe how a product is likely to grow, to align the stakeholders, and to acquire a budget for developing the product. But creating an effective roadmap is not easy, particularly in an agile context where changes occur frequently and unexpectedly. This post shares ten practical tips to helps you create an actionable agile product roadmap. 1 Focus on Goals and Outcomes Whenever you are faced with an agile, dynamic environment—be it that your product is experiencing significant change or that the market is dynamic with new competitors or technologies introducing change, you should work with a goal-oriented product roadmap, sometimes also referred to as outcome-based. Such a roadmap focuses on product goals, benefits, or outcomes like acquiring customers, increasing engagement, and removing technical debt. Features might still exist, but they should derived from the goals and used carefully. I like to recommend using no more than three to five features per goal, as a rule of thumb. To help you develop your agile product roadmap, I have created a goal-oriented roadmap template called the GO Product Roadmap. It consists of five elements: date, name, goal, features, and metrics, as the picture below shows. You can download the template for free from romanpichler. com/tools, and you can find more information on how to use it in my article The GO Product Roadmap. 2 Do the Necessary Prep Work Before you create your roadmap, capture and validate the product strategy. I like to regard the strategy as the path chosen to realise your vision and the roadmap as an actionable product plan that communicates how the strategy is implemented. In other words, I like to derive the roadmap from the strategy. An effective strategy should describe the product's value proposition, the target market. standout features, and business goals. Make sure that you can confidently state these, that you have done the necessary product strategy work. Otherwise, you risk creating a product roadmap that is not realistic and actionable. I like to use my Product Vision Board to describe the product strategy. The board captures the vision, the target group, the problem to be solved or the benefit to be provided, the key features of the product, and the business goals. You can download the Product Vision Board template from romanpichler. com/tools/ for free. 3 Tell a Coherent Story Your product roadmap should tell a coherent story about the likely growth of your product. Each goal should build on the previous one, particularly as long as your product has not reached maturity. To come up with the right roadmap narrative, follow these two tips: First, break the user, customer, and business goals stated in the product strategy into specific and measurable subgoals. Then order the subgoals so that they form a coherent story. If I wanted to offer a healthy eating product, for example, that helps middle-aged men reduce the risk of developing type-2 diabetes, the the goal of the first, initial release (MVP) might be to build a user community. The goal of the second release might be to increase engagement, and the goal of the third one might be to generate revenue. Second, resist the temptation to add goals and features to the product roadmap to please powerful stakeholders or broker a deal. While I am a big fan of collaborative product roadmapping, this should not result in weak product decisions and compromises, see my tips Secure Strong Buy-in and Have the Courage to Say No below. 4 Keep it Simple Be careful not to add too many details to your product roadmap. Keep your roadmap simple and easy to understand. Capture what really matters and leave out the rest by focusing on the goals. Keep the features on your roadmap coarse-grained and derive them from the goals. Do not show epics or user stories on your product roadmap but keep them in the product backlog. Use the product roadmap as a strategic product plan and the product backlog as a detailed one that facilitates execution, as the picture below shows. 5 Secure Strong Buy-in The best product roadmap is worthless if the people required to develop, market, and sell the product don’t buy into it. A great way to get to agreement is to collaborate with the key stakeholders and involve them in creating and updating the product roadmap. This allows you to leverage their ideas and knowledge, it creates shared understanding, and it makes it more likely that people will support the plan. Running a collaborative roadmapping workshop is a great way to engage everyone and create a shared product roadmap, as the following picture illustrates. Make sure, though, that you ask a skilled facilitator, for instance, your Scrum Master, to facilitate the workshop. This includes choosing the right decision rule, for example, consent, and ensuring that everyone is heard and nobody dominates. (See... - Published: 2016-07-11 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/tips-for-working-development-team-for-product-managers-product-owners/ - Categories: Product Leadership, Product Roles - Tags: product manager, scrum, Scrum Master, teamwork The development team is a key partner for every product manager and product owner: the team designs and builds the actual product. But it's not always easy to effectively guide and work with the team. This post shares eight tips to make your collaboration with the development team even more effective, thereby increasing the chances of creating a successful product. Manage the Product, not the Team Focus on your job as the product manager or product owner, and manage the product, not the team. Provide guidance on the product, including its market, value proposition, business goals, and key features. Care about the team members. But let the ScrumMaster or coach tackle people, process, and organisational issues; and recognise that the development team should determine what needs to be done to implement the user stories and other product backlog items. It's a common mistake to step in and take on the ScrumMaster role if there is no ScrumMaster or if the individual is struggling to do a good job. While this may hep you in the short-term, it's going to hurt you in the long run.  Taking on too many responsibilities means spreading yourself too thinly: something will have to go. You will either neglect some of your product responsibilities or put your health at risk. Neither is desirable. (For more guidance on the relationship between the product owner and ScrumMaster see my post Every Great Product Owner Needs a Great ScrumMaster. ) Treat the Team as an Equal Partner Remember the Golden Rule? Treat others how you want to be treated. The team members are not your resources but the people who work with you and create the product. If your relationship with the team is poor, then your product is likely to suffer. To establish a healthy relationship, assume that the team members want to do their best. Respect their UX/UI and technology decisions and their right to determine how much work can be done. Be honest and open. Provide constructive feedback and share your concerns. But don’t tell people how to do their job and refrain from assigning tasks. Development teams should manage their own work (using a sprint backlog or Kanban board). If the team struggles, then it's the ScrumMaster’s job to help the team—not yours (as discussed above). Help the Team See the Bigger Picture Developing a successful digital product requires more than technical knowledge. It’s virtually impossible to develop the right solution without understanding the product context, including who the customers and users are, what value the product creates for them, what makes the product stand out, and how it benefits the business. You should therefore help the team acquire the relevant market and domain knowledge—for instance, by involving the team in product discovery work, inviting them to join you when you visit customers— and ensure that they are aware of the product strategy and product roadmap as well as the business goals and KPIs. This will not only lead to better technical decisions and a better product. It also eases your workload: understanding the bigger picture allows the team to be more self-sufficient. Involve the Team in Product Decisions While you own and manage the product, the development team should understand and support important product decisions. The best way to achieve strong buy-in is involving the team members in the decision-making process. This also leverages their creativity and knowledge and is likely to lead to better decisions. There are a number of techniques that help you achieve strong buy-in including the following ones: Leading through shared goals: Creating a vision, release goals, and sprint goals everyone agrees on; Involving the team members in research and validation activities, for example, observing users or building MVPs and jointly analysing the resulting data; Engaging the team in developing and updating the product roadmap; Collaborating on the product backlog: prioritising items and creating user stories. Be aware that collaboration requires leadership. As the person in charge of the product, you should be open and collaborative but decisive at the same time. Aim to build consensus with the development team, but don’t shy away from difficult conversations. Don’t settle for the smallest common denominator and have the courage to make a decision if no agreement can be achieved: Great products are not based on weak compromises. Spend Enough Time with the Team but Don’t Neglect your Other Duties Make time to collaborate with the team in order to work on user stories, answer questions, and participate in meetings. If you are not available or difficult to reach, you are not guiding the team. In the worst case, people get fed up with trying to get hold of you or waiting for an answer and stop consulting you. Consequently, you may end up with a product that requires extra rework or has features that cannot be released. If, however, you feel overwhelmed by the team’s questions, then coach the team to help people see the bigger picture and... - Published: 2016-06-28 - Modified: 2022-04-28 - URL: https://www.romanpichler.com/blog/scaling-the-product-owner/ - Categories: Essential Articles, Product Roles - Tags: product owner, scaling, scrum In theory, the product owner is one person. But in practice, managing a larger, complex product is usually a shared effort. But how can product ownership be split without resulting in decisions by committee and creating a weak or even inconsistent product? In this post, I discuss different techniques to help you scale the product owner role successfully and I explain when each technique should be applied. Scaling and the Product Life Cycle To understand if and when the product owner role should be scaled, I find it helpful to consider the product’s life cycle stage. As long as a product is young and hasn’t reached product-market fit—or is close to achieving it—I recommend having a single person in charge of the product. Here is why: Young products tend to require a significant amount of experimentation and rework in order to get the product launched, adapt it to the feedback of the early market, and get it ready for product-market fit. At this stage, effective decision-making is paramount. Having a single product owner in place supports this: if no consensus can be achieved about what to do next, the product owner decides. Having one person in charge of the product is viable, as it is usually comparatively small and only a small number of development teams—one or two—are likely to develop it at this stage. But once the product is becoming more successful and start growing, once it attracts more features and becomes richer and requires more teams to develop it, a single person can usually no longer manage the product—without being overworked or neglecting some responsibilities. What’s more, the product now changes less frequently and radically, which makes it easier to share responsibilities amongst a group of product people, as the picture below shows. Scaling Option 1: Feature and Component Owners Once you’ve achieved product-market fit and entered the growth stage, you should consider sharing the product work by asking other people to own product features and / or components. I view a feature as a product capability, such as, the ability to search for a product on a website, and a component as an architecture building block, for instance, the data access layer. (I discuss the difference between products, features, and components in more detail in my post What is a Digital Product? ) The initial product owner should be in charge of the overall product, take care of the product strategy and roadmap, and manage the stakeholders, but still be involved in managing the product backlog and making prioritisation decisions. The feature and component owners manage their assets: they capture new ideas and requirements, test them using feedback and data, and collaborate with the teams developing the features and components. The following picture illustrates this approach. Scaling Option 2: Unbundling and Product Variants The alternative to sharing the responsibility of managing a product is to break up the latter. A common technique to do this is unbundling a feature and releasing it as a separate product—like Facebook did with the Messenger app in 2004. This reduces the scope of the original product and it creates a brand-new one, managed by a new product owner and developed by its own team(s). Another technique is creating product variants—think of iPod shuffle and iPod Touch, for example. Applying this technique avoids feature bloat of the original product; and similarly, to unbundling, it introduces new offerings that are looked after by their own product owners and built by their own teams, as the picture below illustrates. You can, of course, combine option one and two, and first introduce feature owners in addition to an overall product owner and then spin-off features or create variants. Scaling Option 3: Strategic and Tactical Product Roles The third option to scale product ownership is to introduce a strategic and a tactical product role. The strategic role is sometimes called product manager and the tactical one is referred to as product owner, even though in Scrum, the product owner role comprises both, strategic and other responsibilities. Otherwise, a Scrum product owner cannot maximise the value her or his product creates. Frameworks like SAFe use this option as a default, but I recommend you apply it carefully: Splitting product responsibilities along the strategic-tactical dimension works well if a tight integration of strategic and tactical decisions is not required. This is typically the case when the product has entered maturity: it is now incrementally enhanced to defend market share and maximise its business benefits; bigger changes are unlikely to occur—unless you decide to extend its life cycle, for instance, by taking to a new market or segment. If you use this scaling option at an earlier life cycle stage, then you face the risk of strategic decisions not effectively guiding tactical ones, as well as tactical insights, such as user feedback on specific features or a slower than anticipated development progress, not informing the strategic decisions, particularly... - Published: 2016-06-14 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/what-is-a-digital-product/ - Categories: Product Vision and Strategy - Tags: product definition, product life cycle As product professionals, we create a product strategy and product roadmap; we manage the product backlog; we release minimum viable products and product increments; and we are responsible for achieving product success. But what is a product? While it might seem a trivial question, it is surprisingly hard to answer for many organisations. But a poor understanding of this fundamental concept can lead to unclear roles and responsibilities and result in ineffective product management practices. This article offers my definition of what a digital product is and how it differs from features, components, projects, and the user experience. Product What is a product? It might be tempting to say, something we can market or sell. But when it comes to digital products, this definition has only limited applicability. Take the search function on your company’s website. Is that a product? Or is the entire website the product? And how would others, including people from development, marketing, and sales, answer this question? I view a product as an entity that creates specific value for a group of people, the customers and users, and for the organisation that develops and provides it, as the picture below shows. The former is achieved by solving a problem—think of Google Search or Bing that address the challenge of finding information on the Internet—or by providing a tangible benefit—take Facebook that allows people to stay in touch with family and friends. Creating value for the business is accomplished by directly generating revenue, like Microsoft Office and Adobe Illustrator do, helping promote or sell other products or services, think of iTunes and Google Chrome, for example, or increasing productivity and reducing cost, as in-house developed IT applications do. Finding a problem that's worth solving—or a benefit that people would not want to miss once they've experienced it—and discovering a viable business model are two key prerequisites for successfully offering a product. Products go through different life cycle stages: they are created and launched; they develop, grow, mature; and eventually, they die. Some digital products exist for many years and even decades. One of my clients, a company specialised in digital engineering products, offers a product that contains 30-year-old code, for instance. This distinguishes products from projects. Product vs. Project A project delivers a specific product release—think of Windows 10 or iOS 14. 5—and it is a temporary endeavour: The project is finished when the new release becomes available. But products have a different life cycle and typically exist for much longer. The ancestor of Windows 10, Windows NT, was launched in 1993, and iOS was introduced with the first iPhone in 2007, for example. Similarly, products have different success criteria compared to projects. A project is successful if the new release is deployed on time and budget, and if it delivers the agreed scope. A product, however, achieves success if it meets creates the desired value for the users, the customers, and the business. Revenue-generating products typically become successful and profitable when they have achieved product-market fit and entered the growth stage. This may be months, and in some cases, years after the initial development project was finished. The job of a product manager or Scrum product owner is therefore different from a project manager's: product people are in it for the long run—assuming that the product prospers and grows. Features and Components If an asset does not create value for its customers and users and for the company, then I don’t regard it as a product. Take an e-commerce site like Amazon. com or JohnLewis. com. Both offer search and check-out capabilities so that customers can find and buy goods. While these are important steps in the user journey and may require a complex technical solution involving third-party systems, I would be inclined to view them not as products but as features: end-user facing product capabilities that they do not provide value on their own to the customers and the business. I don’t go to Amazon or John Lewis just to search or to checkout. Instead, I want to buy the right product at the right price with minimum hassle. A feature does therefore not address a need or solve a problem on its own. Instead, several features have to interact to create the desired value. Similarly, a user-interface layer or a (micro) service that talks to a payment gateway are not products but components, or more accurately, architecture building blocks—even if they are developed by a dedicated team. Both building blocks may offer a benefit to a group of people—the developers of other components and services—but they don’t create any measurable value for the company. If you manage a feature or component, then that’s perfectly fine. But I don’t think you should be called a product manager or product owner. The terms feature owner or component owner describe your role more accurately: they clearly communicate your responsibilities and avoid confusion and unrealistic expectations. (See my post The Agile Product Owner Responsibilities for more information on how distinguishing between products, features, and components helps you define the right roles and responsibilities. ) Web vs. Mobile Digital products are... - Published: 2016-05-10 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/minimum-viable-product-mvp-minimum-viable-feature/ - Categories: Product Vision and Strategy - Tags: product discovery, validation A minimum viable product (MVP) is often mistaken as the first general release of a product, the initial offering that is good enough to address the early market. But for most products, an MVP should be a much earlier and cruder version that acts as a learning device—a means to test a crucial assumption and make the right product decision. This post shows how I used MVPs and MVFs—minimum viable features—to write my latest book, Strategize. Minimum Viable Product #1 Writing a book is a complex and at times challenging endeavour: it took me over two years to write and publish my book Strategize: Product Strategy and Product Roadmap Practices for the Digital Age. As I had to commit a substantial amount of my time to the project (and my company's money), I wanted to reduce the risk of writing a book that nobody really wants and needs. Using minimum viable products (MVPs) helped me address this challenge. My first MVP had little resemblance with the finished product: my product strategy and roadmap workshop was the initial minimum viable product. This helped me better understand which strategy and roadmap-related challenges product managers commonly experience and which advice they require. Taking into account the attendees' questions and feedback allowed me to refine the book’s value proposition—and improve the workshop at the same time. What’s more, writing the book helped me consolidate and deepen my product strategy and roadmap knowledge and thereby benefited my teaching. Minimum Viable Product #2 While the workshop helped me validate the need the book should address, it did not address another key risk: writing the book in the right way so that the need was properly met and the product sufficiently differentiated. My second MVP helped me with this challenge. In September 2014, I had a first version of the book available for review—my MVP number two. The feedback I received was mixed. There were some encouraging reviews but also some critical ones. In hindsight, I am particularly grateful for the negative feedback as it helped me learn the most. As a consequence, I reworked the book: I moved away from trying to tell a cohesive story about creating an effective strategy and actionable roadmap for a sample product featuring selected tools and techniques. Instead, I opted for a broader collection of related strategy and roadmap tips. This increased the scope of the book and made it applicable to a larger number of products. But it required me to cover additional topics—something I tackled by using minimum viable features. Minimum Viable Features A minimum viable feature (MVF) is similar to an MVP: it tests an idea and acquires relevant knowledge. But instead of testing strategy-related assumptions, an MVF tests solution-specific ideas. It’s sometimes also referred to as a feature-fake or experimental feature, a partially implemented feature that is good enough to test if people would want to use it.  My posts on market segmentation and eliminating product features are sample MVFs is created for Strategize. MVFs allowed me to test how people responded to the new topics and gather quantitative data, including the number of post views, social media shares, and comments. While engaging with the attendees of my workshops and the reviewers of my book was invaluable, the test groups were comparatively small. The blog posts allowed me to reach a larger audience and reduce the risk of collecting non-representative data. Working with MVFs provided me with an additional advantage: it helped me write the book incrementally. This made the writing job less daunting and easier to manage but required integration effort. But the additional work was well worth it: the benefits of using MVFs outweighed this drawback. Leveraging Negative Feedback and Failure While minimum viable products and features were very beneficial for my book, they are no silver bullets, of course. There are two challenges I had to overcome to use the techniques effectively: not getting too attached to an idea and accepting failure. If we want to use MVPs and MVFs as learning vehicles, then we have to allow the product to evolve and change based on the tests we run—and not necessarily how we initially imagined it. I did not anticipate, for instance, that describing product strategy and roadmap techniques in form of a cohesive story would not work out. I was very fond of the idea and initially found it hard to let go. But it was the right thing to do, as subsequent reviews showed. In hindsight, I am glad I made the change. Additionally, minimum viable products and features are likely to generate feedback and data that shows that we made a wrong decision. Personally, I don’t always find it easy to appreciate invalidating feedback. But I also know that I am unlikely to create the right product if the responses are only positive. What helps me is trying not identifying myself with the product while doing everything I can to get it right. This way I haven’t failed when the response to an MVP or MVF is negative; I... - Published: 2016-04-11 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/five-tips-for-introducing-product-management-to-your-company/ - Categories: Product Leadership Product management plays a vital role in the digital age: it enables innovation and growth. It’s therefore not surprising that more and more companies establish product management groups—including retailers, publishers, and banks that traditionally don’t employ product managers. But successfully introducing product management is not easy: I have seen a number of businesses struggle with this challenge. This post provides five tips to help you succeed with introducing product management to your company. 1 Establish a Clear Vision Establish a clear vision for introducing a product management group and explore why your company would benefit from it. There are a number of advantages such a group can offer, including being able to launch more products, serving the right markets and segments, providing the right features, making better product decisions faster, aligning the stakeholders more effectively, and establishing clear roles and responsibilities. But the core value proposition of product management is enabling growth: A product manager is responsible for making and keeping a product successful. This includes taking an idea for a new product or feature and working with development, marketing, and sales (and other business groups) to make it available to the customers and users, as well as killing a product if product success cannot be achieved. Without qualified product managers and a dedicated product management function, product decisions are not made effectively in my experience; time, energy, and money are wasted. In other words, product managers are key to achieving sustained organic growth. 2 Secure Management Buy-in Introducing a new product management group is not trivial. Instead, it requires organisational changes that have to be supported by executive management. To put it differently, if the executives don't buy into creating a product function and if they don’t sponsor—and to some extent—lead the effort, then the chances of establishing the new group are slim. To get executive management on your side, help them understand how a product management group would benefit the company. But don’t stop there: address how the managers would benefit from the change and how it would impact their jobs. The personal benefits can include higher salaries (assuming that these are linked to the company performance and that the new group will increase growth) and reduced workload by allowing the executives to focus on the business strategy. This requires, however, that the executives are willing to grant decision-making authority to the product managers and trust them to manage the company's products. Management still retains some control, though, by sponsoring new and existing products; product roadmaps and key performance indicators help the managers understand how the products are performing and decide how much funding they should receive. Finally, help the executive team decide where product management should sit within the organisation. I have seen product management groups embedded in marketing and in development, for example. But I prefer product management as a separate, major business function that is equal to marketing, sales, and development. This recognises the importance of the group and helps the product managers do a great job. The head of product should therefore be a member of the executive team. 3 Involve the People Whose Jobs Change Introducing product management will impact a number of individuals and departments. For example, if the sales group currently decides which features a release provides, then the group will be significantly affected: The product managers will now make feature and release decisions. People are likely to resist the necessary changes if they don’t understand why they are necessary, or feel that they are forced on them and that their concerns and needs are not taken into account. I therefore recommend that you involve the key people affected by introducing a product function and collaborate with them. If the sales group loses decision-making power, for example, then talk to them and listen to their concerns. Show the salespeople how they can take advantage from the changes and how they can continue to influence the product and ensure that their needs are taken into account. For instance, the sales group is better able to focus on their actual job, and they can shape the product by attending product strategy and roadmap workshops and sprint review meetings. 4 Get the Right People on Board A while back I worked with a company that had just established a new product management group. While the newly appointed product managers were very enthusiastic, most of them lacked important product management skills. As a consequence, they struggled to fill their roles effectively and failed to earn the respect and trust from their colleagues in marketing, sales, and development. To help your newly formed group get off to a good start, make sure that the right people are on board. This often requires hiring a new head of product who has the right product management experience and leadership skills. If that’s difficult, then you may want to consider employing a temporary head of product to kick start the group. Similarly, you may want to hire experienced product managers to inject the necessary product... - Published: 2016-03-24 - Modified: 2024-05-09 - URL: https://www.romanpichler.com/blog/10-tips-writing-good-user-stories/ - Categories: Product Backlog & User Stories - Tags: product definition, product manager, product owner, requirements, teamwork User stories are probably the most popular agile technique to capture product functionality: Working with user stories is easy. But telling effective stories can be hard. The following ten tips help you create good stories. 1 Users Come First As its name suggests, a user story describes how a customer or user employs the product; it is told from the user’s perspective. What's more, user stories are particularly helpful to capture a specific functionality, such as searching for a product or making a booking. The following picture illustrates the relationship between the user, the story, and the product functionality, symbolised by the circle. If you don't know who the users and customers are and why they would want to use the product, then you should not write any user stories. Carry out the necessary user research first, for example, by observing and interviewing users. Otherwise, you take the risk of writing speculative stories that are based on beliefs and ideas—but not on data and empirical evidence. 2 Use Personas to Discover the Right Stories A great technique to capture your insights about the users and customers is working with personas. Personas are fictional characters that are based on first-hand knowledge of the target group. They usually consist of a name and a picture; relevant characteristics, behaviours, and attitudes; and a goal. The goal is the benefit the persona wants to achieve, or the problem the character wants to see solved by using the product. But there is more to it: The persona goals help you discover the right stories: Ask yourself what functionality the product should provide to meet the goals of the personas, as I explain in my post From Personas to User Stories.  You can download a handy template to describe your personas from romanpichler. com/tools/persona-template. 3 Create Stories Collaboratively User stories are intended as a lightweight technique that allows you to move fast. They are not a specification, but a collaboration tool. Stories should never be handed off to a development team. Instead, they should be embedded in a conversation: The product owner and the team should discuss the stories together. This allows you to capture only the minimum amount of information, reduce overhead, and accelerate delivery. You can take this approach further and write stories collaboratively as part of your product backlog refinement process.  This leverages the creativity and knowledge of the team and results in better user stories. If you can't involve the development team in the user story work, then you should consider using another, more formal technique to capture the product functionality, for example, use cases. 4 Keep your Stories Simple and Concise Write your stories so that they are easy to understand. Keep them simple and concise. Avoid confusing and ambiguous terms, and use active voice. Focus on what’s important, and leave out the rest. The template below puts the user or customer modelled as a persona into the story and makes its benefit explicit. It is based on by Rachel Davies' popular template, but I have replaced user role with persona name to connect the story with the relevant persona. As ,I want so that . Use the template when it is helpful, but don't feel obliged to always apply it. Experiment with different ways to write your stories to understand what works best for you and your team. 5 Start with Epics An epic is a big, sketchy, coarse-grained story. It is typically broken into several user stories over time—leveraging the user feedback on early prototypes and product increments. You can think of it as a headline and a placeholder for more detailed stories. Starting with epics allows you to sketch the product functionality without committing to the details. This is particularly helpful for describing new products and features: It allows you to capture the rough scope, and it buys you time to learn more about how to best address the needs of the users. It also reduces the time and effort required to integrate new insights. If you have many detailed stories in the product backlog, then it’s often tricky and time-consuming to relate feedback to the appropriate items and it carries the risk of introducing inconsistencies. 6 Refine the Stories until They are Ready Break your epics into smaller, detailed stories until they are ready: clear, feasible, and testable. All development team members should have a shared understanding of the story’s meaning; the story should not be too big and comfortably fit into a sprint; and there has to be an effective way to determine if the story is done. 7 Add Acceptance Criteria As you break epics into smaller stories, remember to add acceptance criteria. Acceptance criteria complement the narrative: They allow you to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story, make it testable, and ensure that the story can be demoed or released to the... - Published: 2016-03-24 - Modified: 2025-02-18 - URL: https://www.romanpichler.com/blog/the-product-owner-responsibilities/ - Categories: Product Roles - Tags: product definition, product manager, product owner, scrum In theory, the product owner’s responsibilities are simple: The individual should maximise the value the product creates according to the Scrum Guide. But what does this mean in practice? In reality, the application of the product owner role varies greatly, as products and organisations differ. But my experience shows that there are two key factors that determine the duties of a product owner: the scope and the depth of ownership. This blog post discusses these two factors to help you apply the role successfully. Ownership Scope: Product, Feature, or Component Owner? To get the product owner responsibilities right, start by asking what the individual owns. Is it a product, a feature, or a component? While this may sound like a trivial question, it can be a tricky one to correctly answer: I have seen more than one company where people lacked a shared understanding of what a digital product is. If that's the case, it tends to be unclear what it means to manage or own a product. Some individuals look after an entire products, whereas others manage a feature or a component. The following picture summarises the differences between the three terms. Many product owners I have met weren’t product owners but feature owners or component owners. While there is nothing wrong at all with being a feature or component owner, the responsibilities significantly differ from a product owner: A product owner owns the entire product. Consequently, the individual should focus on making and keeping the product a success—by ensuring that it offers a strong value proposition to the customers and users and that it creates the desired business benefits. A feature owner, in contrast, is focused on one or more individual features. The individual’s responsibility is to ensure that the features performs well, for example, that the drop-off number of the checkout feature is low. Similarly, a component owner looks after one or more component, such as, the user interface or data access layer. The person makes sure that the architectural element works as expected. To do so, the individual usually has to have the appropriate technical skills. The picture below illustrates the three different owner roles. Using feature and component owners is a scaling technique: It can help you grow your product by dividing the product responsibilities. A common approach is to have one overall product owner who manages the entire product and several feature and component owners who look after its parts. Ownership Depth: Strategic or Tactical Product Owner? Say you are a product owner in the sense discussed above. Then that’s great. But to what extent do you own the product? Are you responsible for the tactical and strategic decisions, or do you focus on the tactics? Strategic responsibilities include deciding on the product strategy, developing the product roadmap, and managing the stakeholders; examples of tactical duties are managing the product backlog, writing user stories, and working with the development team. Individuals who own strategic and tactical decisions are sometimes referred to as “big” product owners. Product owners who focus on the tactics are called “small” product owners. Depending on the ownership depth, small and big product owners have different responsibilities, as the diagrams below show. I view a small product owner as a partial product owner. Unfortunately, the definition of the role in Scrum—the framework that gave birth to it—is not clear. While the Scrum Guide states maximising value of the product as a responsibility, it only lists tactical duties like managing the product backlog and working with the development team. I find it not uncommon that small, tactical product owners work with a product manager who owns the strategic product decisions. This setup is usually chosen to help grow the product—it’s another scaling technique. It can work well when the product is stable, and especially when it has become mature. It is less suited for younger products, which tend to experience more change and therefore require a closer alignment of strategic and tactical decisions. - Published: 2016-03-09 - Modified: 2023-02-06 - URL: https://www.romanpichler.com/blog/10-leadership-qualities-product-manager-product-owner/ - Categories: Product Leadership - Tags: product manager, product owner Learn how to develop 10 important leadership qualities that help you become a successful product manager and effective product leader. Grouped in pairs, the qualities balance and complement each other. Collaborative and Decisive As the person in charge of the product, you usually don’t have the authority to tell people what to do. Instead, you need to collaborate with the development team and the other stakeholders to help you build, market, and sell a new product or new features. This allows you to benefit from their knowledge and it generates strong buy-in. The following three techniques help you collaborate: Invite the key stakeholders to joint workshops and review meetings, actively listen to their ideas and concerns, and seek consensus on important decisions. If no consensus can be achieved, have the courage to make the decision. Don’t shy away from tough calls and don’t let powerful stakeholders take over. I’ve seen product managers act as feature brokers—mediators who try to negotiate a deal between the stakeholders. Unfortunately, that’s hardly the right strategy to create a successful product, as it involves making weak compromises and agreeing on the smallest common denominator. Instead, focus on the customers and users, do what’s best for them, and balance collaboration with the necessary decisiveness. Strategic and Tactical Thinking strategically and looking at the big picture are important qualities to be a successful product manager. This includes being clear on the product’s value proposition, target market, key features, and business goals; being able to describe how the product is likely to evolve over the next six to twelve months; measuring the product performance; and being aware of market developments and trends. Being strategic, however, is not enough to succeed with digital products. As the product manager, you have to pay attention to the details—from getting the user interaction right to providing right functionality. You should therefore complement being strategic with being tactical. Carrying out the necessary tactical work and collaborate with the development team, for example, by writing user stories and updating the product backlog together with the team members. Balancing the two qualities avoids focusing too much on the problem space and forgetting about the actual product, as well as getting lost in the details and no longer seeing the wood for the trees. What's more it makes sure that strategic decisions are translated into the right actions, and new insights generated from the tactical work informs the product strategy. Enthusiastic and Critical Being a product manager is a demanding job. To play the role successfully, you have to be enthusiastic and motivated. You should have a vision for your product and truly believe that your product will benefit the customers and users and that it’s a worthwhile investment for the company. Otherwise it will be hard to inspire others and sustain the necessary energy to manage it, particularly when the going gets tough and problems appear. Too much enthusiasm can cause you to be too pleased with your product, ignore problems, and overlook opportunities. You should therefore balance being enthusiastic with being critical. Don’t be satisfied with the status quo, look for opportunities to make the product even better and create more value for the customers and users, as well as for the business. Challenge your own ideas and assumptions, experiment with new approaches, and develop and grow as a product professional. User-focused and Business-savvy A successful product does a great for the customers and users: It either addresses a problem or provides a tangible benefit to them—think of a product like Google Search that solves the problem of finding information on the Internet and a product like Facebook that provides the benefit of staying in touch with family and friends. It’s therefore important that you are user-focused and clearly understand why people want to buy or use your product. Techniques such as, regularly interviewing and observing customers and users and frequently reviewing the relevant analytics data, help you with this. As important as a compelling value proposition and a strong user focus are, they are not enough. To sustain developing and providing the product, it must also create value for the company—be it by directly generating revenue or by helping sell another product or service. You should hence complement being user-focused with being business-savvy. Understand how the product helps execute the business strategy, clearly communicate its business goals, and use the right key performance indicators (KPIs) to measure the product performance. Data-informed and Intuitive “In God we trust; all others must bring data,” famously said Edwards Deming. To succeed as a product manager, you should use data to test assumptions and generate new insights—rather than believes and opinions. This increases the chances of making... - Published: 2016-02-23 - Modified: 2023-02-06 - URL: https://www.romanpichler.com/blog/balanced-product-scorecard-template/ - Categories: Product Vision and Strategy Product scorecards are an important product management tool: They help you track the performance of your product. Unfortunately, many scorecards show only financial and customer key performance indicators (KPIs). While these indicators are undoubtedly important, ignoring other KPIs can create distorted view of reality and result in wrong decisions. This articles introduces a balanced product scorecard—a scorecard that provides a complete picture of the product performance thereby helping you to make the right product decisions. Financial and Customer-Focused Scorecards A product scorecard is similar to a car dashboard: Like the control panel displays speed, fuel consumption, and other vital information, a product scorecard shows the KPIs of your product—the metrics that measure how well your product is doing. Most product managers I have worked with record only financial and customer KPIs on their scorecards. The former measure the financial performance of a product and include revenue, cost, profit, and customer lifetime value. Customer indicators focus on the customers and users; sample KPIs are market share, engagement, retention, and conversation rate. This focus has three common causes: Financial and customer KPIs are important to understand the product performance, senior management expects to see them, and they are easy to collect. But a product scorecard that’s limited to these indicators is unbalanced—it can create a wrong view of how the product is performing. Say your product is meeting its revenue and profit goals and customer engagement and referral rate are also high. This seems to suggest that your product is doing well and that there is no reason to worry. If at the same time, team motivation and code quality are deteriorating, then you should be concerned, as this indicates that meeting the business goals and achieving success will be much more difficult in the future. A Balanced Product Scorecard Template The scorecard I have created and work with complements financial and customer indicators with product, process, and people KPIs. This mitigates the risk of overlooking important data and it provides a well-rounded, balanced view of the product performance. You can download the template, which is inspired by the work of Norton and Kaplan, from romanpichler. com/tools and by clicking on the image below. The Five Sections of the Balanced Scorecard The top section of the scorecard shown above states the business goals, which are the benefits your product should deliver, such as generating revenue, saving cost, helping sell another product or a service. Stating these goals communicates what the product performance is measured against. Make sure that your business goals are measurable. While it is notoriously tricky to come up with correct targets for brand-new and young products, you should still try to quantify the goals so you can measure progress against them. Below the business goals are four sections: financial, customer, product and process, and people. The first two capture the relevant financial and customer indicators—the metrics that help you measure the financial and customer-related performance of your product. Examples of the former are revenue, cost, profit; customer indicators include market share, conversion rate, and customer feedback. The product and process section encourages you to track and display KPIs that tell you to how the product is being used and developed. Sample KPIs are user interaction like most/least used features, drop-off points, code quality like number of bugs and code complexity, schedule variances, such as the ability to meet goals on time and on budget, and open impediments or blockers. The people section shows how engaged and supportive the development team members, the key stakeholders, and the management sponsor are. Relevant indicators include team motivation, sickness and turnover rate, development of the team knowledge and skills, and the level of stakeholder engagement and management support. Product, Process, and People KPIs It's important that you capture product, process, and people indicators on a product scorecard, as they complement the financial and customer data: together, they provide you with a complete view of the product performance. Additionally, most of them are leading indicators—they tell how likely it is to achieve success in the future. Take code quality as an example code. If the code quality is decreasing—more defects, higher code complexity—then it will be harder to meet the business goals in the future. But the majority of financial and customer indicators are lagging—they look at the outcome of past actions. As mentioned before, considering only financial and customer data can create a false sense of security: you might assume that your product is doing well only to be surprised that team members are leaving, the number of bugs is increasing, or the development process is no longer working and release dates are difficult to meet. Similarly, if the development team works flat out and has no time to investigate new tools and technology, then knowledge and skills in the team is not improving. This may make it difficult to respond to new trends and leverage new technologies—in addition to the risk that the team members are becoming... - Published: 2016-01-12 - Modified: 2023-12-18 - URL: https://www.romanpichler.com/blog/product-management-leadership-styles/ - Categories: Essential Articles, Product Leadership - Tags: product manager, product owner Succeeding in product management requires more than having the right product expertise. While creating a valid product strategy, developing an actionable product roadmap, and effectively prioritising features are undoubtedly important, these skills are not enough. You also have to successfully lead others and apply the right leadership styles, as I explain in this article. There is No One Right Way to Lead  When you hear the term leadership, you might first and foremost think of a senior manager like the head of product, Director of Product Management, VP of Product, or Chief Product Officer. But leadership is present when an individual guides a group of people to achieve a desired outcome. Product managers and Scrum product owners can therefore also act as leaders: They guide the stakeholders and development teams to create the desired outcomes and achieve product success. See my article Decoding Product Leadership for a more detailed explanation. How you best lead others depends on the context. While many people, including myself, favour a visionary leadership style in product management—someone who leads through a shared vision—this approach style is not always helpful. Take a product in crisis that is about to miss a critical release date or has stopped working due to a major bug. This is hardly the right time to shine as a visionary leader and guide people by establishing a long-term, aspirational goal. As leadership is context-dependent, it is helpful to be aware of different leadership behaviours and understand they are appropriate. Goleman’s classification of six leadership styles helps us with this. It distinguishes visionary, affiliative, democratic, coaching, pacesetting, and coercive styles. Every leadership style has its place—none is always right. Instead, they complement each other. If you want to excel as a product professional, then you should be able to apply all of them. Think of the styles as leadership tools that have their unique strengths and weaknesses. Visionary Leadership Style A visionary leader leads through shared goals including an inspiring product vision. Such a vision describes the purpose for creating the product and acts as the product’s true north that pulls people in the right direction. A visionary leader says, “come with me”, and lets people work out the details of how to get there. Being a visionary leader is particularly helpful when you create a new product or a major product update. It encourages shared ownership and responsibility. It provides motivation and direction. But as mentioned before, this leadership style requires that people have the time, expertise, and willingness to figure out how to achieve an overarching goal. This is not always the case, for instance, when the product is in crisis or when people don’t buy into the vision. Affiliative Leadership Style An affiliative leader puts people first, creates harmony, and builds strong relationships. This makes people feel appreciated and improves collaboration. What’s more, applying this leadership style helps you establish trustful relationships, and it facilitates building new teams. It is not dissimilar to servant leadership, an approach that suggests that leaders should first and foremost care for the people they lead. As helpful as it can be to be an affiliative leader, recognise that caring for individuals and teams should facilitate delivering successful products and achieving the desired outcomes. Don’t make the mistake of ignoring issues and avoiding difficult conversations. Instead, tackle them in a candid and empathic way. Additionally, be aware that helping the development team members bond is the job of the Scrum Master. You should therefore be careful not to take on responsibilities that belong to others and that may overwhelm you. Democratic Leadership Style A democratic leader involves people in making decisions and builds agreement through participation. This leadership style increases responsibility and shared ownership, and it leverages the knowledge and ideas of the people you lead. It is ideal for making important product decisions that require strong buy-in and for generating and evaluating new ideas, for example, creating a new product strategy and building a product roadmap. Bear in mind, though, that if applied incorrectly, democratic leadership can result in long-winded decision-making processes and delayed decisions. In the worst case, decisions are made by committee, and weak compromises are brokered. You should therefore make sure that people involved in the decisions share a common goal or vision. What’s more, carefully decide who to involve and which decision-making rule and process you want to employ, as I explain in more detail in the article Making Effective Product Decisions. Coaching Leadership Style While coaching isn’t always seen as the job of product people, it should still be part of your leadership toolkit: It helps you transfer product and domain knowledge to the development team and the stakeholders, and it is very helpful for developing junior product people. When coaching someone, make sure that the individual is open to being coached and... - Published: 2015-12-14 - Modified: 2023-07-18 - URL: https://www.romanpichler.com/blog/10-tips-for-product-key-performance-indicators-kpis/ - Categories: Product Vision and Strategy - Tags: KPIs Product key performance indicators, or KPIs for short, are metrics that measure the performance of a product. They help you understand if the product is creating the desired value. Without KPIs, you end up guessing how your product is doing. But choosing the right indicators is not always straightforward, and I have seen many product people struggle with it. This post shares my tips on how to select those KPIs that really help you understand how your product is doing. 1 Use the User, Business, and Product Goals to Choose the Right KPIs To select the right key performance indicators or KPIs, you must be clear on the user and business goals your product serves. If your product directly generates revenue, then revenue is likely to be a key indicator, for example. If you are not sure what these goals are, then ask yourself how the product benefits the users and the company. Why would people want to use it and why would the business want to invest in it? Then take the next step and capture the goals using, for instance, my Product Vision Board. You can download the tool and find out how to use it at romanpichler/tools/product-vision-board. Additionally, use any product goals that you have set for your product to derive further KPIs and complete your set of indicators. Product goals are specific benefits or outcomes that your product should create. These goals should be derived from, or at least aligned with, the user and business goals. I capture them on a product roadmap like my GO roadmap, as I explain in more detail in my article How to Choose the Right KPIs for your Product. 2 Make the Goals Specific Knowing the business goals of your product is a prerequisite for selecting the right KPIs. But it is not enough. To effectively apply the indicators, analyse the resulting data, and take the right actions, the goals must be specific and realistic. Establishing such goals can be challenging, particularly for brand-new and young products. The next tips will help you with this. 3 Use Ratios and Ranges Work with ratios and ranges to describe your goals, as Alistair Croll and Benjamin Yoskovitz recommend in their book Lean Analytics. Instead of stating that a new product should create x amount of revenue per year, you could say that the product should increase the company’s revenue by five to 10% within one year after its launch, for instance. While you might not be sure that goal will be met, at least you have drawn a line in the sand against which progress can be measured. If it turns out that the goal is too ambitious, then you move the line and adjust the target. 4 Avoid Vanity Metrics Stay clear of vanity metrics, measures that make your product look good but don’t add value. Take the number of downloads for an app as an example. While a fair amount of people might download the product, this tells you little about how successful it is. Instead of measuring downloads, you should choose a relevant and helpful metric, such as daily active usage or referral rate. 5 Don’t Measure Everything that Can Be Measured Don’t measure everything that can be measured and don’t blindly trust an analytics tool to collect the right data. Instead, use the business goals to choose a small number of metrics that truly help you understand how your product performs. Otherwise, you take the risk of wasting time and effort analysing data that creates little or no insights. In the worst case, you action irrelevant data and make the wrong decisions. 6 Use Quantitative and Qualitative KPIs As their name suggests, quantitative indicators, such as daily active users or revenue, measure the quantity of something rather than its quality. This has the benefit of collecting “hard” and statistically representative data. Qualitative indicators, such as user feedback, help you understand why something has happened, for instance, why users aren’t as satisfied with the product as expected. Combining the two types gives you a balanced outlook on how your product is doing. It reduces the risk of losing sight of the most important success factor: The people behind the numbers, the individuals who buy and use the product. 7 Employ Lagging and Leading Indicators Lagging indicators, such as revenue, profit, and cost, are backwards-focused and tell you about the outcome of past actions. Leading indicators help you understand how likely it is that your product will meet a goal in the future. Take product quality as an example. If the code is becoming increasingly complex, then adding new features will become more expensive and require more time. Meeting profit targets and delivery dates will therefore become harder. Using backward and forward-focused indicators allows you to tell if you have met the business goals and helps you anticipate if the product is likely to meet the goals in the future. 8 Look beyond Financial and Customer Indicators Financial indicators, such as... - Published: 2015-11-17 - Modified: 2024-09-30 - URL: https://www.romanpichler.com/blog/stakeholder-engagement-analysis-power-interest-grid/ - Categories: Product Leadership, Stakeholder Management - Tags: scrum, stakeholders Being a successful product manager or product owner requires more than building a product with the right user experience (UX) and features. If the stakeholders don’t support your product, then it will be difficult to achieve success. It is therefore important to engage the right stakeholders and to work with them in the right way. This post discusses a proven technique to analyse stakeholders, the power-interest grid, and it shares my recommendations for engaging with different stakeholder groups in the right way. Identify the Stakeholders A stakeholder is anyone who has a stake in the product, who is affected by it, or who shows an interest in it. While this definition includes customers and users, it is commonly used to refer to the internal stakeholders. Note that some frameworks, such as Scrum, have their own stakeholder definition. In Scrum, the stakeholders are all interested parties apart from the product owner, the development team, and the ScrumMaster. To identify the stakeholders, ask yourself whose help you need to develop, release, and provide the product. The answer to this question will be specific to your product and company. For a commercial product, the group is likely to include representatives from marketing, sales, support, and management. But it might also comprise legal, finance, and human resources. For an in-house product, your stakeholders may be operations, the affected business units, and management. Analyse the Stakeholders Once you have identified the stakeholders, take the next step and analyse them to understand how you should engage with them. This focuses your efforts, generates the desired buy-in, and allows you to spend your time wisely. A common stakeholder analysis technique is the power-interest grid, which was originally published by Colin Eden and Fran Ackermann in their book Making Strategy. As its name suggests, the grid assesses the stakeholders by taking into account their power and their interest. The grid assumes that stakeholders take a low or high interest in your product and that they have low or high power. A stakeholder is typically interested in the product if it noticeably affects the individual. Someone has a high power if the person can influence the product decisions, for instance, if or when a feature is implemented. Taking into account low and high power and interest results in four quadrants and stakeholder groups, players, subjects, context setters, and crowd, as the following picture shows. Each stakeholder group on the grid above requires a different engagement form, as I explain below. Collaborate with the Players Stakeholders with high interest and high power are called players. These individuals are important partners for you as the product manager or product owner. You should therefore collaborate with them closely, for instance, by inviting them to product strategy and roadmapping workshops and sprint review meetings. Aim to secure their buy-in, leverage their ideas and knowledge, and establish a close and trustful relationship with them. Additionally, ensure that the individuals are involved with the product on a continued basis to avoid loss of knowledge and hand-offs. It is undesirable, for instance, that the marketing group sends a new representative every time a strategy workshop or review meeting takes place. Instead, one marketer should represent the group on a continued basis. Bear in mind that collaboration requires leadership. You should be open and collaborative but decisive at the same time. Aim to build consensus with the players but don’t shy away from difficult conversations. Don't settle for the smallest common denominator and have the courage to make a decision if no agreement can be achieved. Involve the Subjects Subjects are individuals with high interest but low power. They feel affected by the product and are keen to influence it but they can't veto or change decisions. Subjects can make great allies who can help you secure understanding and buy-in for your product. Keep them engaged and involve them on a regular basis, for instance, by inviting them to sprint review meetings and encouraging them to share their feedback. But don’t make the mistake to say yes to every idea and request subjects raise. Use the product strategy and roadmap to assess if an idea is helpful or not. If in doubt, consider running a brief and cheap experiment to find out if adding a feature would be beneficial, for example. Consult the Context Setters People with low interest but high power are called context setters or referees. They affect the product’s context but they take little interest in the product itself. An example is the person in charge of the development group: If the individual does not help staff the development team properly, then the success of the product may be at risk. Make sure that the context setters feel that their opinions, concerns, and ideas are heard and understood. Regularly consult them, for instance, by having one-on-one meetings. This ensures that their ideas and concerns are heard and it helps avoid nasty surprises. Don’t let the context setters intimidate you and don’t allow them to dictate decisions. Be strong and have the courage to say no even if faced with... - Published: 2015-10-22 - Modified: 2024-02-02 - URL: https://www.romanpichler.com/blog/user-stories-failure/ - Categories: Product Backlog & User Stories - Tags: product manager, product owner, requirements User stories are a powerful agile technique to describe requirements from the perspective of the customers and users. Unfortunately, I find it not uncommon that user stories are applied unsuccessfully and fail. This post describes two common failure causes and discusses how you can avoid them. Wrong Context As their name suggests, user stories tell a story: They describe in plain language how a customer or user employs the product. Instead of specifying every little detail, user stories offer an informal way to capture the requirements. This works, if the stories are complemented with a conversation that takes place between the product manager/product owner and the development team. In this conversation, the product person tells the story to the team; the team members ask questions and suggest adjustments. Ideally, the conversation takes place face-to-face with everyone being in the same room. The benefits of this informal and collaborative approach are twofold: It leads to better requirements and it saves time by shifting from written requirements to tacit knowledge. Unfortunately, I see organisations apply user stories even if an effective conversation is very hard to achieve. Instead of discussing and refining the stories together, they are handed off to the development team. Often, the team is remote and has limited knowledge about the market and the product. To account for the missing conversation, the product manager or owner tries to write elaborate, detail-rich, and precise stories. This turns user stories into something they were not designed to be: formal requirements. If you find yourself in a similar situation, then you have two choices: Make sure that an effective conversation does take place, for instance, by having regular onsite workshops or using videoconferences to discuss and adjust the stories with the development team. Alternatively use a different requirements description technique, such as use cases. Use cases offer more structure and make it easier to precisely describe a requirement, for instance, by using pre conditions and exception scenarios. Wrong Job User stories describe end user requirements. They were not designed to capture technical requirements. You can, of course, tell stories about how a product is built and use technical stories. But I find that natural language is not well suited to capture technical requirements and I prefer to work with a modelling language like UML (Unified Modeling Language). Why bother describing an interface or API in natural language when you can model and visualise it using a UML artefact? If you find that your teams heavily rely on technical requirements, then this may indicate that you work with component teams – teams that are organised around architecture building blocks, such as components, services, and layers. An effective way to reduce the need for technical requirements is to reorganise the teams by forming feature teams – teams that implement user stories end-to-end in form of a vertical slice. But it’s not only technical requirements that should not be captured as user stories. Complex user interactions, such as workflows and scenarios, and user interface requirements are also difficult to describe as a user story. Take, for instance, an online shop that requires the users to discover a product, select it and place it in the basket, and to pay for it. If you attempted to describe these steps with one story, you would either end up either with a big compound story or you would use the acceptance criteria to describe the workflow. Neither is desirable in my mind. A better solution is to use stories to describe discrete functional requirements and to complement them with other techniques, such as story maps, scenarios, workflow diagrams, and storyboards. I discuss this approach in more detail in my post User Stories are Not Enough to Create a Great User Experience. - Published: 2015-09-22 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/the-go-portfolio-roadmap/ - Categories: Product Roadmap Products don’t exist in isolation. Instead, they are often related to other products, which they help sell or they share features and components with. Think, for instance, of the Microsoft Office suite or the iPod product line. If your product is part of a family, then you will benefit from a portfolio roadmap, a plan that shows how the products are likely to grow together. This post introduces such a plan, the GO Portfolio Roadmap, and it describes how this roadmap can help you manage your product family. The GO Portfolio Roadmap Portfolio roadmaps come in different shapes and formats. Based on my popular GO Product Roadmap, I have developed the GO Portfolio Roadmap. Both roadmaps are goal-oriented and use goals to anticipate how a product or a product family is likely to grow. The following picture shows the structure and the elements of the GO Portfolio Roadmap. You can download the template for free from romanpichler. com/tools/the-go-portfolio-roadmap/ or by clicking on the picture below. As the template above shows, the GO Portfolio Roadmap combines the roadmaps of several related products into a single plan. The portfolio roadmap is based goals; you create it by identifying the desired benefits the portfolio members should deliver. The goals invite you to describe why it is beneficial to develop the products and the overall portfolio rather than focusing on individual features. I find that goal-oriented roadmaps are particularly beneficial in the presence of change and uncertainty. What’s more, they make it easier to align stakeholders and help create a shared understanding of how the portfolio is likely to grow. Let's take a brief look at the elements of the GO Portfolio Roadmap. The top section displays the release dates or timeframes. It then states the portfolio members, product A and product B. Each product has its own goals, features, and metrics, which are identical to their counterpart on the GO Product Roadmap: Each goal describes the desired benefit a major release should provide; the features are the key deliverables necessary to meet the goal; and the metrics state the measurements used to determine if the goal is met. (For more information on the goals, features, and metrics, please refer to my post The GO Product Roadmap. ) You can customise and extend the GO Portfolio Roadmap by adding more products and by including more portfolios with their products. A Sample GO Portfolio Roadmap Let’s see how the GO Portfolio Roadmap can be applied. The following sample roadmap consists of one portfolio, the Healthy Eating product family, and two fictitious products, the Beach Body app and the Training app. The former is aimed at people who would like to lose weight to look slimmer; the latter targets athletes who would like to improve their performance by adjusting their diet. As the picture above shows, major releases are planned for both products on a quarterly basis. While the Beach Body app has been available for a while, the Training app is a brand-new product. If the latter reuses features of the former and if those features have to be refactored before they can be reused, then the roadmap above contains dependencies. These dependencies have to be managed, and the roadmap may have to be reworked, for instance, by delaying the launch of the training app to Q2. This illustrates one of the main benefits of a portfolio roadmap: It is easier to spot dependencies compared to using separate product roadmaps. At the same token, if your portfolio roadmap suffers from many dependencies, then this may be an indication that the products are not defined appropriately. You may have to unbundle some products and promote their features to new products, for instance; you may choose to do the opposite and bundle smaller products into a larger one; or you may want to encapsulate shared assets, components, or services into a platform (which would then be added to the portfolio). As developing and updating a portfolio roadmap tends to be more challenging compared to a product roadmap, I recommend that you develop a solid product roadmapping practice before you employ a portfolio roadmap. What's more, make sure that the assets in your portfolio are indeed products--not features or components. Otherwise you don't need a portfolio roadmap; a product roadmap will do. - Published: 2015-08-19 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/three-common-product-roadmapping-mistakes/ - Categories: Product Roadmap - Tags: stakeholders The product roadmap is a great tool to describe the likely growth of a product. But there are three common mistakes I see people make: View the roadmap as a guarantee; show epics and user stories on the roadmap; and speculate about the likely development of the product. This post discusses the three product roadmapping mistakes to help you avoid and rectify them. Guarantee A product roadmap is not a guarantee but a high-level plan that describes the likely growth of your product based on what you currently know. It’s good to have confidence in your roadmap and it is great to be committed to your product. But your product roadmap is not fixed; it will change particularly if your product is immature or if your market is dynamic. Clearly tell your stakeholders that the roadmap is not a hard-and-fast plan. Choose the right roadmap format and the right level of detail. Review and update the roadmap regularly and invite the key stakeholders to collaborative product roadmapping workshops. Take look at my post Getting Stakeholder Engagement Right find out how you can effectively identify and involve the stakeholders. You can find out more about choosing the right roadmap format and level of detail in my post Goals vs. Features: How to Choose the Right Product Roadmap Format. Epics and User Stories Don’t put epics and user stories on the product roadmap. While it’s helpful to consider how the product is likely to evolve, you should focus on its key capabilities and leave out the details. A detailed roadmap has several drawbacks: It makes it hard to understand how you want to progress your product; it makes it more difficult to achieve agreement with the stakeholders; it is more prone to change; it carries the risk of turning the roadmap into a tactical tool that competes with the product backlog; and it restricts the freedom of the development team to make a commitment and pull the right amount of work into the sprint. Capture the epics and the user stories in the product backlog, not on the product roadmap. Use the roadmap to describe the big picture and the backlog to describe the details, as I discuss in my post The Product Roadmap and the Product Backlog. Speculation and Wishful Thinking Don’t create a roadmap if you don’t have a valid product strategy available or if you cannot look beyond the first public release. The former implies that you have nailed the market segment, the value proposition, the key product features, and the desired business benefits. The latter means that you can realistically anticipate the longer-term growth of your product. If you are working on a brand-new product, for instance, and are about to launch your first minimum viable product (MVP) then you may not be in a position to create a product roadmap for the next 12 months without resorting to speculation. You may be better off waiting until you have analysed the users’ response to the MVP. Delay the creation of your product roadmap until you have a valid product strategy in place and you understand how to implement the strategy. Otherwise you are likely to end up with a speculative and unreliable roadmap that is useless. This may cause the stakeholders to lose trust in the product roadmap and in your planning abilities. - Published: 2015-07-14 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/product-backlog-right-details/ - Categories: Product Backlog & User Stories - Tags: product life cycle, requirements, scrum The product backlog is a great tool. But using it effectively can be difficult. One of the challenges is to get the level of detail right. An overly detailed backlog is unwieldy and hard to manage. But a product backlog that is too coarse-grained is also not helpful: It provides too little guidance for the development team. This post helps you strike the right balance between too much and too little detail. It shows you how determine the right amount of detail for your product backlog. Theory and Practice In theory, your product backlog should be prioritised with the high-priority items at the top and the low priority items at the bottom. The top items should be detailed and fine-grained. But as their priority decreases, they should become more and more coarse-grained. You could capture your top items as small user stories that are ready to be implemented in the next sprint. But further down in the backlog you would use epics, which are big sketchy stories. How detailed an items is therefore depends on its priority, as the following picture shows.  If your product backlog does not look like the one above, does this mean it is wrong? The Product Life Cycle I find that a product backlog like the one pictured above is optimised for a young product. At this stage, you typically have to experiment with new ideas and change your product frequently, for instance, to discover the right user experience and features or to enhance and optimise them. As a consequence, you want to be able to easily change your backlog, keep it concise, and use only a small amount of detailed items. Otherwise, updates are too much effort and take too long. But as your product stabilises and eventually matures, you have learned to better understand the market, the customer needs, and how to address them. This increases your ability to anticipate how your product is likely to evolve. Consequently, you can add more details to your backlog. How detailed your product backlog should be is therefore tied to the lifecycle stage of your product: Young product should have a concise backlog with few details; older, stable products tend to benefit from a more detailed backlog, as the following picture shows. The product backlog on the left-hand size of the life cycle curve carries only a few detailed items; most of its contents are coarse-grained. But the backlog on the right-hand side is the opposite: It contains many more detailed items and fewer coarse-grained ones. As a consequence, it is larger and less concise. But watch out that your backlog does not grow in an uncontrolled fashion or morph into a wish list. Complement it with a product roadmap to capture the longer-term outlook of how your product is likely to grow. While the product life cycle is great to gauge the right level of detail, it is not enough. You should also consider where your product's position in the release cycle. The Release Cycle As you start working on a new product version or a major release – think of iOS 8. 4 or Windows 10 – you typically encounter more unknowns and risks than towards the end of the project. If you address the risks on early, then your product backlog is particularly volatile in the first few sprints. As you test assumptions and address the risks, you are likely to discover that some of your assumptions were wrong and generate new ideas. The new insights and ideas make it necessary to change the product backlog, and some of the change can be rather big, particularly if your product is young. You will therefore benefit from a concise and coarse-grained backlog at the start of a new release. But once you have addressed the key risks and critical assumptions, your focus shifts to completing and optimising the features, as I explain in my post "Get Your Focus Right: Learning and Execution in Scrum". At this point your product backlog should start to stabilise and experience fewer and smaller changes. As a consequence, you can add more details to it. As a rule of thumb, use few details at the start of a project or release and more once you have addressed the key risks and the product backlog has started to stabilise. Conclusion Use the product lifecycle and release cycle to determine how detailed the product backlog should be. This is true for traditional backlogs as well as Jeff Patton’s storymaps and my Product Canvas. To put it simple, the more uncertainty and change you experience the more coarse-grained and concise the backlog should be. As your product develops and grows adjust your product backlog and the way you manage it. There is no one right level of detail. - Published: 2015-06-23 - Modified: 2023-07-18 - URL: https://www.romanpichler.com/blog/big-product-owner-small-product-owner/ - Categories: Product Roles - Tags: product life cycle, product manager, product owner, scaling, scrum Product owners come in different shapes and sizes. That's only natural: The application of the role varies depending on the product and the company. Being a product owner of a brand-new product in a startup differs from looking after a mature offering in a large enterprise. But there are two common types: big and small product owners. Which one are you? And is your product ownership level right? Big vs. Small What's a big and a small product owner? “Big” and “small” define levels of ownership. A big product owner owns the entire product; a small one takes care of the product details or tactics, as the following picture shows. The picture above distinguishes three levels: vision, strategy, and tactics. The vision describes the ultimate reason for creating the product. The strategy covers the product strategy, the product roadmap, and the business model. The tactics refer to the product details such as epics and user stories, design sketches, scenarios, and interaction diagrams, which are typically captured in the product backlog.   The big product owner is how the Scrum product owner is defined in mind. A small product owner is how the SAFe, the Scaled Agile Framework, views the role. Good vs. Bad Being a certain height has its benefits and drawbacks, just like working as a big and a small product owner. The advantage of being a big product owner is that you control all aspects of the product. As there are no hand-offs, and you should be able to make consistent decisions in a timely manner. But you may find it challenging to take on all responsibilities, as it requires a diverse set of skills and it may be too much work for a larger product. Being a small product owner allows you to focus on the product backlog and the product details. This can help you do a great job and prevent you from getting overworked. But it requires that you effectively collaborate with the individual who owns the vision and the product strategy. Otherwise you may suffer from hand-offs, waiting and delays, loss of knowledge, inconsistent decision-making, and confusion about who decides what. Bear in mind that an effective collaboration requires that you have at least some knowledge of the strategic product aspects just like the individual looking after the vision and strategy should know what a product backlog is and how to manage it effectively. The following table summarises the benefits and the drawback of the two product owner variants: Product OwnerBenefitsDrawbacksBigFast and consistent decision-makingDiverse skills set; potentially unsustainable workloadSmallFocus, greater degree of specialisationHand-offs, delays, loss of knowledge; inconsistent decisions Right vs. Wrong If both variants have the benefits and drawbacks, when is it then better to be small product owner and when to be a big one? I find a big product owner particularly beneficial when a product is young and when it evolves fairly rapidly. Once it grows steadily or it has become mature, employing small product owners can be helpful to share the workload and facilitate scaling. In other words, you should make your choice based on the lifecycle stage of your product, as the following picture illustrates. As long as your product is young and you are trying to achieve growth, it is advantageous to have person in charge of the product and to work with a big, single product owner. The reason for this is simple: While the strategy directs the tactics, the latter influence the former. How customers and users respond to product increments and releases can have a profound impact on the strategy. It can even cause a pivot, a significant strategy change. Take, for instance, YouTube, Flickr, and Instagram, which all changed their strategy to become successful. If several people share the product management responsibilities then the individuals will have to agree on the appropriate actions. This can slow you down significantly. In the worst case, you end up with a decision-by-committee scenario and a weak product full of compromises. As powerful as a big product owner is, playing the role can become overwhelming once your product experiences growth, attracts more features, and becomes bigger. What’s more, as your product tends to be more stable now, and bigger changes are less likely to happen. Sharing the responsibilities across several people and employing small product owners is therefore a good option – unless you decide to unbundle your product and to promote some features to new products. Think of Facebook taking the messenger functionality of its main app and turning it into a new product , the Messenger app. Note I have borrowed the idea of distinguishing between a big and a small product owner from Rich Mirnov who suggested the term back in 2008. - Published: 2015-05-19 - Modified: 2026-01-29 - URL: https://www.romanpichler.com/blog/elements-definition-product-strategy/ - Categories: Product Vision and Strategy - Tags: product life cycle, product vision board Creating a successful product requires attention to the details, from getting the user interaction and the visual design right to providing the right functionality and using the right technologies. With so much focus on the nitty-gritty, it’s easy to no longer see the wood for the trees. This is where the product strategy comes in. It helps you manage your product proactively and it prevents you from getting lost in the details. This post discusses what an effective product strategy is and how it benefits you. The Three Elements of an Effective Strategy Product strategy is about imagining the future of your product: What offering will it become? Who will it benefit? How will it create value? It's a high-level plan that helps you realise your vision or overarching goal. More specifically, the product strategy should describe who the product is for and why people would want to use and buy it; what the product is and what makes it stand out; and what the business goals are and why it is worthwhile for your company to invest in it, as Figure 1 shows. Figure 1: The Elements of an Effective Product Strategy In Figure 1, the market describes the target customers and users of your product, the people who are likely to buy and to use it. The needs comprise the main problem your product solves or the primary benefit it provides. Think of a product like Google Search or Bing that solves the problem of finding information on the Internet. Compare it to a product like Facebook that allows you to stay in touch with family and friends. The key features and differentiators are those aspects of your product that are crucial to address the main problem or create the primary benefit, and that make it stand out from the crowd. Don’t make the mistake of creating a mini product backlog or a wish list. Instead, focus on the three to five key aspects that make people choose it over competing offers. Take, for example, the first iPhone with mobile Internet, iPod-like digital music player, and touch screen as its key features; or the Google Chrome browser with its focus on speed, safety, and simplicity. The business goals capture how your product is going to benefit your company. Is it going to generate revenue, help sell another product or service, reduce cost, or increase the brand equity? Being clear on the business goals helps you to select the right key performance indicators (KPIs) and measure your product’s performance. Take the iPhone and the Google Chrome browser mentioned earlier. While the iPhone currently generates the largest portion of Apple’s revenue at the time of writing, the Chrome browser does not earn any money for Google. But it allows the company to control the way people access the Internet and it has reduced Google’s dependency on third-party browsers such as Mozilla Firefox and Microsoft Edge. Both are important business benefits. A handy tool to capture your product strategy is my Product Vision Board, shown in Figure 2. You can download it together with a handy checklist from romanpichler. com/tools/vision-board or by clicking on the image. Figure 2: The Product Vision Board The Product Vision Board in Figure 2 captures the vision at the top. The four sections underneath it describe the product strategy. You can find more information on how to use the tool in the article The Product Vision Board and the video Introduction to the Product Vision Board. Strategy Focus and Inflection Points The product strategy is not a static, fixed statement or document that you create for a new product. It changes as your product grows and matures. Figure 3 shows the product life cycle with four key events: launch, product-market fit, life cycle extension, and end of life. Figure 3: The Product Life Cycle Model The strategy for a new product should first help you get to launch, then achieve product-market fit (PMF), and finally sustain the growth of your product. Think, for instance, of the changes Apple has made to the iPhone since its launch in 2007 to keep it attractive and preserve its growth, from adding apps to changing its size and offering different variants. Once the growth starts to stagnate you have reached another strategic inflection point: You can either extend your product's life cycle, for instance, by rejuvenating it or taking it to a new market, or you let it mature and eventually decline and die. As your product evolves and changes, you should review and adjust the product strategy on a regular basis, at least once a quarter, as a rule of thumb. This will help you proactively manage your product, align the stakeholders and guide the development teams, and maximise the chances of achieving product success. The Product Strategy in Context If the product strategy describes the key elements required to develop a successful product as I suggested above, then where are the vision and the product roadmap? My product strategy model in Figure 4 shows... - Published: 2015-04-27 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/eliminate-features/ - Categories: Product Vision and Strategy - Tags: focus, innovation, simplicity It is tempting to add more and more features to make your product stand out and differentiate it from the competition. While this can be an appropriate strategy at times, it carries the risk of creating an overly complex product with a vague value proposition and a poor user experience. It can therefore be useful to explore which ones you can reduce or even eliminate. This post shows you how to do it. A great tool for discovering opportunities to remove features is the Eliminate-Reduce-Raise-Create grid. The grid, which forms part of the Blue Ocean Strategy, encourages you to identify the key features that are used to compete in the marketplace, be it by your own product or the competitors. You then determine which of those features your product can eliminate and which it should provide to a lesser extend or in an inferior way. But that's not all. The grid also encourages you to identify new and improved features that set your product apart. This leads to a matrix with four quadrants that give the grid its name: Eliminate, Reduce, Raise, and Create. Let’s take a look at an example and apply the grid to the first iPhone, which was launched in 2007. As the picture above shows, the first iPhone eliminated a number of smartphone features that were considered a standard or must-have back in 2007. These included different models to choose from, a physical keyboard and a stylus to write on the screen. Additionally, it reduced a number of features such as the voice and the camera quality and the email integration (no POP and no Exchange support), which its competitors excelled in. But the iPhone also provided enhanced and genuinely new features as shown in the "Raise" and "Create" quadrants above. These include mobile Internet in form of the Safari browser, integrating the iPod with a mobile phone, a brand-new eye-catching design, and a revolutionary touch screen. Removing and weakening features helped Apple reduce time-to-market, resulted in an uncluttered, easy to use product, and made the product stand out. Before you decide which features you are going to remove or reduce, ensure that you have a solid understanding of your target group and the problem your product solves or the benefit it provides. You will also benefit from a good portion of courage. It’s always easier to create a me-too product than to do something different. But "innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features," as Steve Jobs once said. - Published: 2015-03-25 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/market-segmentation-tips-for-product-managers/ - Categories: Product Vision and Strategy Identifying the right customers and users for your product is key to its success: It determines the value proposition and the user experience, it influences the business model and the technologies used. This post helps you reflect on your market segmentation practice and pick up some new tips. What is Segmentation? Market segmentation is like eating cake: Instead of trying to eat the whole cake at once and possibly creating mess or choking on it, we cut out a neat slice. Segmenting the market and dividing it into distinct groups allows you to create focused products with a compelling value proposition and a great user experience. Your segments should be clear-cut so that they do not overlap. What’s more, each segment should be homogenous and the people within it should respond to your product in the same way. Let's say that I wanted to create an app that helps people eat more healthily. The product could benefit a diverse group including individuals who want to lose weight as well as people who live with a medical condition such as diabetes. Trying to please everyone at once is not only challenging. It carries the risk of not satisfying anyone. Instead, I should focus on a specific market subset or segment. How you segment the market is important: The segments define who the customers and the users are. While there are different ways to divide the market, you face two basic choices: You can primarily use customer properties such as age or gender or the benefit that your product provides. Segmentation by Customer Customer properties that are commonly used to divide the market include: Demographics such as age, gender, marital status, occupation, education, and income. Psychographics including lifestyle, social class, and personality. Behavioural attributes like usage patterns, attitudes, and brand loyalty. Regions such as Europe, Middle East and Africa (EMEA) and Asia-Pacific (APAC). Industries or verticals, for instance, automotive, education, finance, and healthcare for business markets (B2B). Company size such as small and medium-sized enterprises (SME) for B2B products. Let’s take my healthy eating app as an example. To segment the market, I could choose demo- and psychographic attributes and define my target segment as men, aged 20-30, who are single, work long hours, and eat out frequently. While the attributes listed above differ, they have something important in common: They all focus on the customer, be it a consumer or a business. Segmentation by Benefit An alternative approach is to segment the market using the benefit the product provides or the problem it addresses. This suggests that you first and foremost consider people’s needs and the job they need to get done. For instance, if the main benefit of my healthy eating app is to help people understand better how much they eat, then there are two groups that may benefit from it: people who would like to lose weight; and people who want a more precise way of determining their calories intake such as athletes and people with diabetes. The first group could contain single men aged 20-30 with poor eating habits. But it could equally include married women with small kids who want to lose weight but don’t have the time or energy to follow a strict diet or to exercise regularly. Which Approach should you Choose? With different market segmentation approaches available to you, how can you tell which ones is right? My answer is simple: Whenever you do something new – be it creating a new product or taking it to a new market, then segment by benefit first. Once you have created the initial benefit-based segments, refine them by using demographics and other customer properties. This approach reduces the risk of overlooking people who are likely to benefit from your product and of creating misaligned segments that don’t correspond to reality. Take my healthy eating app. If I had created segments primarily based on demo- and psychographics, I probably would have overlooked athletes and women with children as target customers. Avoid these Two Common Mistakes Whichever way you segment the market, avoid the following two mistakes: First, don’t blindly follow predefined segments. I have seen product managers clinging to existing customer-based segments while trying to create breakthrough products. Unsurprisingly, the outcomes were rather poor. Second, don’t discard an idea because it does not fit into predefined market segments. Otherwise you may miss out on opportunities to create new products and new markets. Take the first iPhone, which launched in 2007, as an example. Apple disregarded the traditional distinction between consumer and business smartphones. Instead the company created a product that offered “the Internet in your pocket” and appealed to consumers and business users alike. - Published: 2015-02-19 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/how-to-choose-the-right-product-roadmap-format/ - Categories: Product Roadmap - Tags: GO product roadmap, planning A product roadmap is a high-level plan that shows how a product is likely to develop over the next few releases. While that's true for any roadmap, there is no one right product roadmap format. Instead, you should choose the roadmapping approach that works best for your product. This post shows you how to do it. Feature-based vs. Goal-oriented Product Roadmaps Product roadmaps come in different shapes and sizes. But the two most popular formats are probably feature-based and goal-oriented roadmaps. The former are built on product features such as registration, search, or reporting, which are mapped onto a timeline. Goal-oriented roadmaps focus on goals or benefits instead. Sample goals are acquiring users, retaining them, increasing engagement, activating users, generating revenue, and removing technical debt. Features are viewed as second-class citizen. They are derived from the goals and usually used sparingly. The following picture illustrates the two different roadmap formats showing two major release, m and n. Not that independent of its format, your product roadmap should tell a realistic and coherent story about the likely growth of your product. It should execute the product strategy so that each release builds on the previous one moving you closer towards your vision. It should not contain a random sequence of goals or a loose collection of features! A Sample Goal-oriented Roadmap Format If you would like to try out a goal-oriented roadmap, then take a look at my GO product roadmap template below. You can download it from romanpichler. com/tools/product-roadmap or by clicking on the following picture. Please see my article The GO Product Roadmap for guidance on how to use the template above. Choose the Right Product Roadmap Format While I am biased towards goal-oriented roadmaps, they are not always the best fit. To select the right roadmap format for you product, consider the maturity of the product and the stability of its market. The younger your product is, the more uncertainty and change are likely to be present. A young product therefore benefits from a roadmap that focuses on product goals. Older, mature products lend themselves to feature-based roadmaps that provide more details. The reason for this is simple: As your product reaches maturity, it experiences fewer changes, and you are in a better position to correctly anticipate its growth. But your product’s age is not the only driver that influences your product roadmapping approach. If your product is mature but its market segment is volatile, for instance, as competitors keep adding new features or the technologies change, you will have to update your product to defend its market share. As a consequence, uncertainty and change creep back into your roadmap. This makes it difficult to plan ahead in detail and to correctly forecast when which feature will be released. Instead, you are better off creating a roadmap that is built on goals. Taking into account product maturity and market stability results in the following matrix. The matrix above captures the maturity of your product on the vertical axis and the stability of its market on the horizontal axis. By distinguishing a young and a mature product and a dynamic and a stable market, four quadrants emerge that help you choose the appropriate format for your roadmap. I recommend using a product roadmap that is based on goals when your product and / or your market are likely to change. Employ a feature-based roadmap only if your product has reached maturity and the market is stable. This is in contrast to what I see most organisations do: Create feature-based roadmaps even though the product and the market change.  Don't make the same mistake. Use feature-based product roadmaps only when little change and uncertainty are present. But bear in mind that mature products can change too. You may, for instance, rejuvenate a mature product like Apple has done with the iPod Nano. To keep it attractive, the company has considerably changed the product since its launch in 2005. It has shrunk its size and shape and it has given it a touch screen. You may therefore have to switch from a feature-based roadmap back to a goal-oriented one! - Published: 2015-01-20 - Modified: 2024-02-02 - URL: https://www.romanpichler.com/blog/ux-skills-for-product-owners-and-product-managers/ - Categories: Product Roles, User Experience (UX) - Tags: product manager, product owner, user experience Providing a great user experience is a must for many digital products, and user experience (UX) design has consequently become prominent in recent years. Does this mean that product owners and product managers should become UX experts? Who should design the UX and which UX skills should product owners and product managers have? Read on to find out my recommendations. Maximising Value I often get asked how much product owners and product manager should know about user experience (UX) design and who should do the UX work on an agile team. To answer this question, let's reflect on what product people re responsible: to ensure that your product creates the desired value for the users and for the business. Your job is not to design a great user experience. Does this mean that product owners and product managers should not care about the user experience? Of course not! Many digital products must provide a great user experience to achieve product success. Take for example Monument Valley, a beautifully designed computer game. If the user interaction, the graphics, the animations, and the music of the game were not right, then it would not be enjoyable to play it. As a consequence, not many people would make in-app purchases, and the product would not generate enough revenue for Ustwo, the company that develops the game. For some products, creating a great user experience is the main differentiator, the quality that sets it apart from the competition and that helps it become a success. Designing the User Experience If the user experience design is important but if it’s not a core responsibility of the person in charge of the product, whose job is it? I prefer having one or more qualified user experience designers on the team, the cross-functional team that designs, builds, and tests the product. In a Scrum context, that’s the development team in the picture below. As the picture above shows, I view it as the job of the development team to offer design and technology leadership and to own the user experience design. As the person in charge of the product, you should know enough about the users so that you can guide the development team and explain who the product is for, why people (would) buy and use it, what makes it stand out, and what the desired business benefits are. A great way to do this is to create personas including a primary persona. Collaboration While it's great to explain the users' characteristics and goals to the development team, it's even better to involve the development team members in carry out the product discovery and user research work out. I have therefore placed the user research work between the product owner and the development team in the picture above. This allows you to benefit from the individuals' experience--UX designers are great partners to determine the right user research techniques and carry out the research work--and it allows the team members to acquire firsthand knowledge about the users and empathise with them. This, in turn, makes it more likely that the dev team can create a product with a great user experience. - Published: 2014-12-17 - Modified: 2023-10-09 - URL: https://www.romanpichler.com/blog/the-product-owners-checklist-for-the-first-sprint-in-scrum/ - Categories: Product Management Process, Product Roles - Tags: product owner, scrum Scrum is a popular agile framework for developing a product with the right features and the right technologies. Unfortunately, it does not state the prerequisites for kicking off a Scrum project and for starting the first sprint. As a consequence, I find it not uncommon that product managers and product owners are unsure about the work they should do prior to the first sprint. This post offers a checklist to help you do the right upfront product management work. The Essential Upfront Product Management Work Scrum is agnostic about the work that has to be done before you can create an initial product backlog and run the first sprint, be it for a brand-new product or for an existing one that you have just taken on. In fact, it doesn't make any recommendations. But this does not mean, of course, that you don't have to or should not do any work before you move into Scrum and kickoff the first sprint. As the product owner, you should do just enough work to have the following artefacts in place and be able to answer the following questions: Artefacts Questions to Address Shared Vision What are the purpose and the motivation for developing, marketing, and selling the product? What is the positive change the product should create? Valid Product Strategy What market or market segment does the product serve? Who are the customers and the users? What problem does it solve, or which benefit does it provide? Why would people choose it over a competing offer? What makes it special or desirable? What are the business goals? Why should your company invest in the product? Valid Business Model How does the product generate the desired business benefits? How is it monetised? What are the cost factors for developing, marketing, and selling the product? What marketing and sales channels are used? Realistic Product Roadmap How is the product going to be delivered over the next 12 months? What are the release dates? What goals or benefits do the individual releases provide? What metrics are used to determine success? Personas What characteristics, attitudes, behaviours, and goals do the users and customers have? Who is the primary persona? The items in the table above form a checklist to help you assess if you are ready to apply Scrum. You may have to tailor the checklist to you specific needs. For an in-house product, a valid business model is typically less applicable than for a commercial one, for instance. Similarly, if you build a product for a client then the strategy should address the client's business goals rather than yours. You can use choose from a range of tools to capture the answers to the questions above. For instance, my Product Vision Board describes the vision and the strategy, Alexander Osterwalder’s Business Model Canvas defines the business model, my GO Roadmap captures the product roadmap, and my persona template helps you describe the personas. The point is not to use a specific tool but to ask the right questions and to answer them effectively. To put it differently, if you struggle with the questions then a tool alone is unlikely to help you. Vision and Strategy Take Priority Of the four artefacts listed above, the vision and the product strategy are particularly crucial. You should hence pay particular attention to them and create them first. Here is why: If you don’t have a shared vision, then you lack an overarching goal and a reason for creating the product. You will consequently struggle to motivate, guide, and align the stakeholders. If you don’t know who the customers and the users are and why they would buy and use your product, then you cannot make informed decisions about the user experience and the product features. Imagine writing a user story without knowing who the user is. You would have to speculate and dream up the story. What’s more, collecting meaningful feedback becomes virtually impossible, as you are likely to ask the wrong people and receive unhelpful feedback. This would cause you to draw the wrong conclusions and make the wrong changes to your product; or you would conclude that the users don’t have a clue, that you should ignore their input, and that you know what’s best for them anyway. Neither approach maximises the chances of creating a successful product. Finally, if you don’t know what the business goals are and why your company should invest in your product, you don’t understand the value that the product should create for your business. This will make it difficult to attract funding and to get the right people. Business Model, Product Roadmap, and Personas Come Second Having a vision and product strategy is great but not always enough to start the first sprint effectively. For commercial software products it is also important to understand how you can meet the business goals and how you can monetise your product. Otherwise you won’t be able to create a financial forecast, and... - Published: 2014-11-26 - Modified: 2026-02-23 - URL: https://www.romanpichler.com/blog/romans-product-management-framework/ - Categories: Product Leadership Product management is a multi-faceted, complex discipline that can be difficult to grasp and hard to master. This post shares my take on what product management is and what it takes to work as an effective product manager and product owner. It presents a framework that helps you define specific product roles and identify gaps in your product knowledge. A Product Management Framework I often get asked what it takes to be an effective product manager or product owner, which product skills the individuals should have, and how a company can strengthen these functions. Answering these questions requires an understanding of what effective product management looks like in the digital age. The following picture depicts my view of a framework that consists of six core knowledge areas and by six supporting ones. The core areas are orange and placed centrally. The supporting ones are purple and located at the edge of the circle. You can download the framework for free by simply clicking on it or from romanpichler. com/tools/product-management-framework. The core areas are particularly important for doing a great job as a product manager or product owner. You should hence strive to become knowledgeable in all of them. The supporting areas are also important for your work, especially when you manage commercial products, but generally not as crucial. If the framework with its knowledge areas feels overwhelming, then don’t worry: Product management is a complex and demanding discipline that is not easy to master. It takes time and effort to become a competent product professional. The good news is that you can use the framework to spot gaps in your skill set so you can address them. The Core Knowledge Areas Vision and Leadership: Working as an effective product managers or product owner requires the appropriate leadership skills. You should be able to establish a shared vision, set realistic goals, and describe the benefits your product should deliver. You should be able to actively listen to others and negotiate to reach agreement and get buy-in. At the same time, you should not shy away from making the right product decisions even if they are tough and do not please everyone. You should be able to manage the stakeholders, including customers and users, senior management, development, marketing, sales, support, and other business groups that have to contribute to the product success. You should be able to effectively communicate with and influence them. You be comfortable working with a broad range of people from diverse backgrounds including a cross-functional development team. (See my post Getting Stakeholder Engagement Right to find out how to effectively identify and involve the stakeholders. ) Product Life Cycle Management: Managing a product successfully involves more than getting it built and released. You should understand the product life cycle with its stages and the key events in the life of your product including launch, product-market fit, and end of sales; you should know how the lifecycle helps you maximise the benefits your product creates across its entire life; this includes the life cycle’s impact on the product performance (revenue and profits), the product goals, the pricing and the marketing strategy; the options to revive growth as your product matures and growth starts to stagnate; and the process best suited for each lifecycle stage. (An iterative, Lean Startup and Scrum-based process tends to beneficial while your product is young; Kanban is usually preferable when your product starts to mature. ) Product Strategy and Market Research: Your product exists to serve a market or market segment, a group of people whose need the product addresses. You therefore should be able to identify your target users and customers and segment the market; you should be able to clearly state the value proposition of your product, why people would want to use and buy it and why your product does a great job at creating value for them. You should be able to carry out a competitor analysis to understand their respective strengths and weaknesses; you should be able to position your product, and determine the values the brand needs to communicate. You should be able to perform the necessary market research work to test your ideas and assumptions about the market segment and the value proposition. This includes qualitative and quantitative methods including problem interviews, direct observations, and employing minimum viable products (MVPs); you should be able to leverage data to make the right decisions. This includes using an analytics tool, analysing the data effectively, and deciding if you should pivot and change your strategy or if you should persevere and refine it. Business Model and Financials: To provide an investment incentive for your company and to make developing and providing the product sustainable, you have to be able to determine the value the product creates for your firm. You should be able to formulate and prioritise business goals, for instance, enter a new market, meet a revenue or... - Published: 2014-10-08 - Modified: 2023-02-15 - URL: https://www.romanpichler.com/blog/tips-for-writing-compelling-product-vision/ - Categories: Product Leadership, Product Vision and Strategy Creating and managing a successful product requires a lot of time and energy. In order to be fully committed, you have to be convinced that what you are doing is right and have a clear vision of where to take your product. This post shares eight tips to help you create an effective product vision that inspires the development team and the stakeholders. Describe the Motivation behind the Product Having an idea for a new product is great. But it’s not enough. What you need is a vision that guides everyone involved in making the product a success: product management, development, marketing, sales, and support. The product vision is the overarching goal you are aiming for, the reason for creating the product. It provides a continued purpose in an ever-changing world, acts as the product’s true north, provides motivation when the going gets tough, and facilitates effective collaboration. To choose the right vision, ask yourself why you are excited to work on the product, why you care about it, what positive change the product should bring about, and how it will shape the future. One of my favourite vision statements comes from Toys R Us. The company's vision is to "put joy in kids' hearts and a smile on parents' faces".  The statement concisely captures the intention behind the company’s products and services and describes the change the users and customers should experience. If you choose the company vision for you product, then that’s fine. Otherwise make sure that the two visions aren’t in conflict other but aligned. Look beyond the Product Be clear on the difference between the product vision and the product and don’t confuse the two. The former is the motivation for developing the product; the latter is a means to achieve the overarching goal. Say that I want to create a computer game that allows children to choose and interact with characters, select different music tracks and worlds, choreograph their own dances, and play together with friends. This might be a nice idea, but it is not the actual vision. An effective product vision goes beyond the product and captures the change the product should instigate. A vision for the game would be “Help children enjoy music and dancing”. Distinguish between Vision and Product Strategy Your product vision should not be a plan that shows how to reach your goal. Instead, you should keep the product vision and the product strategy – the path towards the goal – separate. This enables to change your strategy while staying grounded in your vision. (This is called to pivot in Lean Startup. ) At the same time, a vision is the prerequisite for choosing the right strategy. If you don’t have an overarching goal then you cannot decide how you best get there. This is nicely illustrated by the famous conversation between the Cheshire Cat and Alice in Alice’s Adventures in Wonderland. Asked which way Alice should take, the cat replies: “That depends a good deal on where you want to get to. ” “I don’t much care where –,” says Alice. “Then it doesn’t matter which way you go,” responds the Cheshire Cat. A handy tool for describing both the product vision and the product strategy is the Product Vision Board. Its top section captures the vision, and the ones below state the strategy to realise the vision. You can download the tool for free from romanpichler. com/tools/vision-board. Create a Shared Vision You can come up with the most beautiful vision for your product. But it’s useless if the people involved in making the product a success don’t buy into it. To leverage the vision as the product’s true north, to create alignment, and to facilitate effective collaboration, the product vision must be shared – everyone must have the same vision. Without a shared vision, people follow their own goals making it much harder to achieve product success. A great way to create a shared product vision is to employ a collaborative visioning workshop. Rather than formulating a product vision and then selling it to the key people you create it together. Use the product idea as an input and ask the workshop attendees to capture their motivation for working on the product. Then compare the different visions, look for common ground, and combine the different goals into a new one everybody agrees with. You can employ a similar approach for an existing product: Invite the right people, ask them to write down their vision, and compare them. If the visions are the same or very similar, then that’s great. If not then you have some work to do. Choose an Inspiring Vision “If you are working on something exciting that you really care about, you don’t have to be pushed. The vision pulls you,” said Steve Jobs. Your vision should therefore motivate people, connect them to the product, and inspire them. I find... - Published: 2014-09-09 - Modified: 2024-03-27 - URL: https://www.romanpichler.com/blog/product-roadmap-product-backlog/ - Categories: Essential Articles, Product Backlog & User Stories, Product Roadmap - Tags: GO product roadmap, planning, stakeholders The product backlog is a great tool to capture ideas and requirements. But it is less suited to describe how the product is likely to develop in the longer term. This is where the product roadmap comes in. But how do the product backlog and the product roadmap relate? Is the backlog derived from the roadmap or is it the other way round? Should the product owner be responsible for both artefacts? Read on to find out my recommendations. Product Roadmap vs. Product Backlog The product roadmap and the product backlog are two important product management tools. Each tool has its own strengths and weaknesses: The product roadmap is a strategic product-planning tool that shows how the product is likely to grow across the next, say, 12 months. It creates a continuity of purpose, facilitates stakeholder collaboration, helps acquire funding, and makes it easier to coordinate the development and launch of different products. The product backlog contains the outstanding work necessary to create a product including epics and user stories, workflow diagrams, user-interface design sketches, and mock-ups. It is a tactical tool that directs the work of the development team and that provides the basis for tracking the development progress using, for example, a release burndown chart. The following diagram summarises the main differences of the product roadmap and the product backlog. Applied correctly, the two tools complement each other nicely. The product roadmap provides an umbrella for the product backlog; it tells a longer-term story about the likely growth of the product whereas the product backlog contains the details necessary to progress the product in the next few months. Derive the Product Backlog from the Product Roadmap I Find it helpful to derive the product backlog from the product roadmap. This assumes, however, that you have a realistic roadmap in place that provides the right input for the backlog, particularly product goals that capture the desired benefits or outcomes your product should provide. Sample goals might be acquire users, increase engagement, and remove technical debt to future-proof the product. You can take this approach further and focus your product backlog on the next product goal. This creates a concise backlog that is easy to update and change, which is particularly useful as long as your product changes and grows. To do so, use the next product goal on your roadmap to scope your product backlog and determine the right contents, as the following picture illustrates. Minimise any Overlap between the Roadmap and the Backlog Unfortunately, I find that product roadmaps can contain too many details, including epics and user stories, and that some product backlogs look too far into the future. This blurs the line between the two artifacts; it results in a product roadmap that is difficult to understand, prone to change, and overly long and hard to manage. Therefore keep the two tools separate and leverage their respective strengths. Employ the roadmap to describe your product’s overall journey and the backlog to capture the details. Don't add epics and stories to your product roadmap. Stick to high-level features and product capabilities instead. Keep the Product Roadmap and Product Backlog in Synch Be aware that the product backlog also influences the product roadmap: Bigger product backlog updates can trigger product roadmap adjustments. Similarly, if the development progress is not as anticipated, you may have to update the product roadmap and modify, for example, the goal or date. It is therefore important that you keep the product roadmap and the product backlog in sync. Use the product roadmap to determine the backlog contents, as mentioned above, and consider the product backlog changes when you review the product roadmap. Reviews should happen on a quarterly basis, as a rule of thumb, and involve dev team representatives and the key stakeholders. - Published: 2014-08-13 - Modified: 2024-02-02 - URL: https://www.romanpichler.com/blog/personas-epics-user-stories/ - Categories: Product Backlog & User Stories - Tags: product discovery, user model User stories are a powerful technique to capture the product functionality from the perspective of a user or customer. But how do we discover the right stories? When should they be written and how detailed should they be? Read this post to find out my answers to these questions. 1 Create Personas The first step towards writing the right user stories is to understand your target users and customers. After all, user stories want to tell a story about the users using the product. If you don’t know who the users are and what problem we want to solve then it’s impossible to write the right stories and you end up with a long wish list rather than a description of the relevant product functionality. Personas offer a great way to capture the users and the customers with their needs. They are fictional characters that have a name and picture; relevant characteristics such as a role, activities, behaviours, and attitudes; and a goal, which is the problem that has to be addressed or the benefit that should be provided. Let’s look at an example. Say we want to create a game for children, which is fun to play and which educates the kids about music and dancing. We could then create at two personas, one to represent the children, and one for the parents, as shown below. The two sample personas above use my simple yet effective persona template. It encourages you to keep your personas concise, to focus on what really matters and to leave out the rest. You can download the template from romanpichler. com/tools/persona-template where more information on writing personas and using the template is available. Once you have created a cast of characters, select a primary persona, the persona you are mainly designing and building the product for. This helps you make the right product decision and get the user experience (UX) right. In the example above, I have chosen Yasmin as the primary persona. 2 Derive Epics from the Persona Goals Once you have created your personas, use their goals personas to identify the product functionality. Ask yourself what the product should do to address the personas’ problems or to create the desired benefits for them, as the following picture shows. Start with your primary persona and capture the functionality as epics, as coarse-grained, high-level stories. Write all the epics necessary to meet the persona goals but keep them rough and sketchy at this stage. For the dance game, we could write the epics to allow the players to select different characters, to make them dance, to choose different dance floors and music tracks, to play the game with their friends, and to post a snapshot of their game on social media. While epics are great to sketch the product’s functionality, there is more to your product than epics and stories: You should also capture the user interaction and the sequences in which the epics are used, the visual design of your product, and the important nonfunctional qualities such as interoperability and performance. Use, for instance, workflow diagrams, story maps, storyboards, sketches, and constraint cards to describe them. You can find out more about describing the different product aspects in my post “User Stories are Not Enough to Create a Great User Experience”. 3 Progressively Refine the Epics into User Stories With a holistic but coarse-grained description of your product in place start progressively breaking your epics into smaller stories. Rather than detailing all epics and writing all user stories upfront, you derive your stories step by step as the following picture shows. As long as there are some significant risks present and you are figuring out what the product should look like and do, it’s best to derive just enough user stories just in time for the next sprint.  Use your sprint goal to determine which epics to decompose and which stories to write as the following diagram illustrates. This approach depicted above minimises the amount of detailed items in your product backlog. This makes it easier to integrate new insights derived from exposing product increments to users and customers. Once you have addressed the key risks, you can start pre-writing user stories and have a larger inventory of detailed items on your product backlog, as your backlog is unlikely to change significantly. 4 Get the Stories Ready Before the development team starts working on the stories, check that each user story is ready: clear, feasible, and testable. A story is clear if there is a shared understanding between the product owner and the team about its meaning. It is feasible if it can be delivered in the next sprint according to the Definition of Done. This implies that the story is small enough to fit into the sprint but also that the necessary user interface design, test, and... - Published: 2014-07-16 - Modified: 2023-02-06 - URL: https://www.romanpichler.com/blog/10-tips-creating-agile-product-strategy-vision-board/ - Categories: Product Vision and Strategy - Tags: validation This post does what its title says: It shares my recommendations for creating an agile product strategy using the Vision Board. It addresses readers who want to find out more about using a product strategy in an agile, dynamic environment and readers who want to get better at using the Vision Board. 1 Start with What You Know Now Traditionally, a product strategy is the result of months of market research and business analysis work. It is intended to be factual, reliable, and ready to be implemented. But in an agile, dynamic environment a product strategy is best created differently: Start with your idea, state the vision behind it, and capture your initial strategy. Then identify the biggest risk or the crucial leap-of-faith assumption, address it, and change and improve your strategy. Repeat this process until you are confident that your product strategy is valid. This iterative approach, pioneered by Lean Startup, provides several advantages: First, it helps you develop a strategy built on empirical evidence rather than on intuition, authority, or influence. Second, it enforces fast failure and minimises the risk of following the wrong strategy and launching a product that bombs. Third, it avoids carrying out too much and too little market research; it helps you do just enough research to acquire the knowledge you really need. 2 Focus on what Matters Most The term product strategy means different things to different people, and strategies come in different shapes and sizes. While that’s perfectly fine, an initial product strategy that forms the basis for subsequent correction and refinement cycles should focus on what matters most: the market, the value proposition, the product’s unique selling points, and the business goals. This is where my Vision Board comes in. I have designed it as the simplest thing that could possibly work to capture the vision and the product strategy. You can find more information about the board and download it for free from romanpichler. com/tools/vision-board. 3 Create the Product Strategy Collaboratively A great way to create your product strategy is to employ a collaborative workshop. Invite the key stakeholders--the people required to develop, market, sell and service your product and the senior management sponsor. Such a workshop generates early buy-in, creates shared ownership, and leverages the collective knowledge and creativity of the group. Selling an existing vision and product strategy can be challenging. Co-creation is often the better option. Your initial Vision Board has to be good enough to create a shared understanding of your vision and initial strategy and to identify the biggest risk so you can start re-working your board. But don’t spend too much time on it and don’t try to make it perfect. Your board will change as you test, correct, and refine it. 4 Let Your Vision Guide You The product vision is the very reason for creating your product: It describes your overarching, aspirational goal. The vision also forms the basis of your product strategy as the path to reach your overall goal. As the vision is so important, you should capture it before you describe your strategy. Here are four tips to help you capture your vision: Your vision should not restate your product idea. It should rather go beyond it. For instance, the idea for this post is to write about creating an agile product strategy, but my vision is to help you develop awesome and successful products. Choose a broad vision, a vision that engages people and that enables you to pivot – to change the strategy while staying true to your vision. Make your vision statement concise; capture it in one or two sentences; and ensure that it is clear and easy to understand. Try to come up with a motivating and inspiring vision that helps unite everyone working on the product. Choosing an altruistic vision, a vision that focuses on the benefits created for others, can help you with this. You can find more information on formulating a compelling product vision in my post 8 Tips for Creating A Powerful Product Vision. 5 Put the Users First Once you have captured your vision, work on your strategy by filling in the lower sections of the Vision Board from left to right. Start with the “Target Group”, the people who should use and buy your product rather than thinking about the cool, amazing product features or the smart business model that will monetise the product. While both aspects are important, capturing the users and customers and their needs forms the basis for making the right product and business model decisions. While it’s tempting to think of all the people who could possibly benefit from your product, it is more helpful to choose a clear-cut and narrow target group instead. Describe the users and customers as clearly as you can and state the... - Published: 2014-06-17 - Modified: 2024-11-21 - URL: https://www.romanpichler.com/blog/product-owner-sprint-retrospective/ - Categories: Product Management Process, Product Roles - Tags: product owner, scrum, Scrum Master, stakeholders, teamwork The sprint retrospective is a key mechanism in Scrum to improve the way people work. This article shares my tips on how you can use the meeting as the person in charge of the product to strengthen connections and improve the work. The Retrospective in a Nutshell The sprint retrospective is an opportunity to pause for a short while and reflect on what happened in the sprint. This allows the attendees to improve their collaboration and their work practices, to get even better at creating a great product. The meeting takes place right at the end of the sprint after the sprint review meeting. Its output should be actionable improvement measures. These can range from making a firm commitment to start and end future meetings on time to bigger process changes, including switching from, say, Scrum to Kanban. The retrospective is not a finger-pointing exercise. As Mahatma Gandhi famously said: "Be the change you want to see in the world. " Take Part As the Scrum product owner, you are a member of the Scrum team, which also includes the development team and the Scrum Master. While you are in charge of the product, you rely on the collaboration of the other Scrum team members to create a successful digital product. If you don’t attend the retrospective, you waste an opportunity to strengthen the relationship and to improve the collaboration with the development team. Additionally, taking part in the sprint retrospective allows you to understand why the team requires time in the next sprint to carry out improvements such as refactoring the build script, or investigating a new test tool; and maybe more importantly, it helps you improve your own work. Say that some of the user stories the team had worked on did not get finished in the sprint. At first sight this looks like the development team’s fault. But analysing the issue might reveal that the size of the stories and the quality of the acceptance criteria contributed to the problem. As you are responsible for ensuring that the product backlog is ready, this finding affects your work: It indicates that you should improve the development team’s involvement in refining the stories to ensure that that they are ready, that there is a shared understanding, that they are feasible, and that they can be tested. Be an Active Participant Don’t make the mistake of attending the retrospective as a guest who will speak when asked but otherwise remains silent. Be an active participant instead. Use the sprint retrospective to get feedback on your work, and raise any issues that you want to see improved. Be collaborative and actively listen to the other attendees, but don’t shy away from addressing tough problems. Here are some questions that you may want to explore in the retrospective: Is the communication between the team and you open, honest, and trustful? If not, how can you improve it? Are the development team members happy with the time you spend with them? Are you available to answer questions and provide feedback on work results as needed? Do the team members actively participate in analysing user feedback and data, refining the product backlog, and getting stories ready for the sprint? Do you get enough support from the team to refine the backlog? Do the team members understand the big picture – the overall vision, the product strategy, and the product roadmap? Do you actively involve the team members in the product strategy work? Hold a Retrospective with the Stakeholders As important as it is, improving your collaboration with the development team and the Scrum Master is not enough. You will also benefit from trustful connections with the stakeholders, such as representatives from marketing, sales, customer service, finance, and legal. A great way to improve stakeholder collaboration is to schedule a larger retrospective with the extended product team, for example once every two or three months. Here are some questions that you may want to explore in an extended retrospective: Do the stakeholders feel sufficiently involved in the product strategizing and product roadmapping activities? Do they think that their ideas and concerns are taken into account? Do they regularly participate in joint meetings like product strategy reviews and sprint reviews? Are the meetings beneficial for them? Do you get enough support and commitment from the stakeholders? Do the individuals stick to shared goals and joint decisions? You could discuss these questions one-on-one, of course. But jointly addressing issues and identifying improvement measures creates a sense of we-are-all-in-this-together; it helps create trust and it facilitates collaboration. Ask your Scrum Master to help you prepare and to facilitate the meeting. This allows you to contribute and share your perspective and needs. - Published: 2014-04-23 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/beyond-product-demo-validation-techniques-in-scrum/ - Categories: Product Backlog & User Stories, Product Management Process - Tags: risk, scrum, user feedback, validation Scrum employs the product demo as its default technique to understand if the right product with the right features is developed. While a product demo can be very effective, it can also be limiting. Like any research and validation technique, demoes have their strengths and weaknesses. This article provides an overview of alternative validation methods so you can choose the one that is best suited for your product. Feedback and Data in Scrum Collecting feedback and data is a vital aspect of Scrum. It enables you to learn if the right product with the right features is created.  Scrum employs a three-step process to achieve this: A product increment is created, which is then exposed to the users, the customers, and the other stakeholders. This generates feedback and data, which triggers product backlog changes, as the following picture shows. To leverage this process, the techniques used to gather the data and validate the product are crucial. If you use the wrong method, you are likely to collect wrong or insufficient data and draw the wrong conclusions.  While there is a range of techniques available, Scrum recognises only one: the product demo, which is performed in the sprint review meeting. But this does not mean that you should or cannot employ another technique!  The opposite is true: The sprint demo may or may nor be right for product. Additionally, using a single data collection method over an extended period of time is usually a mistake. Every technique has its strengths and limitations, and none is always appropriate. You should hence choose the one that is most helpful for your product and combine complementing techniques. Five Helpful Techniques To help you choose the right method, I have compiled five techniques in the table below. I discuss each technique in the following sections. Technique Description Strength Weakness Product demo Demo the latest product increment. Listen to the feedback, and ask open questions. Test limited functionality: Helps people imagine what using the product would be like. Feedback is available immediately. Feedback is based on what users hear and see; danger of influencing users. Usability test Understand how users perform a task in a controlled environment such as a lab. Understand if users employ the product as anticipated. Possibly collect data using analytics software. Data is available immediately. Artificial environment: users do not use the product “in the wild”; observer effect. Release Release the software to a group of target users and collect data using analytics. Find out how the product is used in its target environment. Reach a larger test group. Run A/B tests. Does not explain why users employ the product in a certain way. Can take time to collect enough data. Direct Observation Observe users employing the product preferably in its target environment. Understand how users interact with the product. Can be time consuming; danger of observer effect and bias. Spike  Create an executable prototype to address an architecture or technology risk. Understand if an architecture or technology choice is feasible. Can lead to an over-engineered solution. Product Demo As its name suggests, the product demo presents the latest product increment to the appropriate users, customers, and internal stakeholders. The presenter explains how the users would employ the product to get a job done. Product demos are particularly valuable in the early sprints, as they allow you to get immediate feedback on limited functionality and very small increments: By wrapping the increment in a story, people can imagine what it would be like to use the product. This strength is also a major weakness: The feedback is based on what people see and hear, not on their actual experience of using the product. What's more, the presenter can influence the users inappropriately by talking up the product or asking closed questions, and powerful individuals like a senior manager can influence the views of the group. My post “Tips for an Effective Product Demo” shares more tips and tricks on employing product demoes effectively. Usability Test A usability test allows you to understand how users interact with your product. Usability testing takes typically place in a controlled environment such as a meeting room or lab. Target users are asked to perform a task using the latest product increment, which may be a paper prototype or executable software. You then observe and record how people employ the product, and you can end the test with asking the participants about their experiences and impressions. It is often possible to conduct the test in the sprint review meeting. While a usability test quickly generate real user data, the artificial environment and the observation can cause the users to act differently compared to working with the product in “the wild”, that is, in the environment in which the product will be used, for instance, at home, at work, in the car, on the train. This is where the next technique comes in. Release Releasing software means giving a group of target users access... - Published: 2014-03-26 - Modified: 2023-11-14 - URL: https://www.romanpichler.com/blog/every-great-product-owner-needs-great-scrummaster/ - Categories: Product Roles - Tags: product owner, Scrum Master The Scrum product owner and the Scrum Master are two separate roles that complement each other. To do a great job, product owners need a strong Scrum Master at their side. Unfortunately, I find that there is often a lack of Scrum Masters who can support the product owner. Sometimes there is confusion between the roles, or there is no Scrum Master at all. This post explains the differences between the two roles, what product owners should expect from their Scrum Master, and what the Scrum Masters are likely to expect from them. Product Owner vs. Scrum Master The product owner and Scrum Master are two different roles that complement each other. If one is not played properly, the other suffers. As the Scrum product owner, you are responsible for product success—for creating a product that does a great job for the users and customers and that meets its business goals. You therefore interact with users and customers as well as the internal stakeholders, the development team, and the Scrum Master, as the following diagram shows. The grey circle in the picture above describes the Scrum Team consisting of the product owner, the Scrum Master and the cross-functional development team. The Scrum Master is responsible for process success—for helping the product owner and the team use the right process to create a successful product, and for facilitating organisational change and establishing an agile way of working. Consequently, the Scrum Master collaborates with the product owner and the development team as well as senior management, human resources (HR), and the business groups affected by Scrum, as the following picture illustrates: Succeeding as a Scrum product owner requires the right skill set, time, effort, and focus. So does playing the Scrum Master role. Combining both roles—even partially—is not only very challenging. It also makes your job as the product owner even more demanding. This risks neglecting some of your core responsibilities or sacrificing sustainable pace and with it, your wellbeing. Therefore, do not take on Scrum Master duties, at least not on a continued basis. What the Product Owner should Expect from the Scrum Master As a Scrum product owner, you should benefit from the Scrum Master’s work in several ways. The Scrum Master should coach the dev team so that the team members can build a great product, facilitate organisational change so that the organisation leverages Scrum, and help you do a great job. The following table details the support you should expect from the Scrum Master: Team Coaching Help the development team collaborate effectively and manage their work successfully so that they can make realistic commitments and create product increments reliably. Encourage the team to participate in product backlog refinement. Ensure that the team has a productive work environment. Organisational Change Work with senior management, HR, and other business groups to implement the necessary organisational changes required by Scrum. Educate the stakeholders about Scrum and explain their role in progressing the product. Resolve role conflicts such as product owner vs. product manager and product owner vs. project manager. Product Owner Coaching Help the product owner choose the right product management techniques and tools. Support the product owner and tackle empowerment issues. Facilitate decisions and help the product owner, stakeholders, and dev team members reach an agreement. The Scrum Master supports you as the product owner so that you can focus on your job–making sure that the right product with the right user experience (UX) and the right features is created. If your Scrum Master does not or cannot provide this support, then talk to the individual, and find out what’s wrong. Don’t jump in and take over the Scrum Master’s job. If you don’t have a Scrum Master, explain to your management sponsor and to your boss why you need a qualified Scrum Master at your side. Taking on the Scrum Master role would cause you to be overworked or neglect some of your core responsibilities, neither of which is desirable. What the Scrum Master should Expect from the Product Owner It takes two to Tango, as the saying goes. The table below describes the service the a Scrum product owner should provide in more detail: Strategic Direction Provide a vision, product strategy, and product roadmap to the development team that describes where the product is heading. Involve (some of) the team members and the key stakeholders in the product strategy work. Formulate a product goal for the near to mid-term. Product Discovery Guidance Proactively work on the product backlog. Update it with new insights and ensure that there are enough ready items. Involve the team members in the work. Provide direction and make prioritisation calls. Invite the right people to sprint reviews and choose the right techniques to validate product decisions, for instance, invite selected users the review meeting and carry out a usability test. Collaboration Be available for questions and support the development team. Buy into the process and attend the sprint planning, sprint review, and sprint retrospective. Engage the stakeholders but don't shy away from making tough decisions; say no to... - Published: 2014-03-11 - Modified: 2024-04-29 - URL: https://www.romanpichler.com/blog/sprint-goal-template/ - Categories: Product Management Process - Tags: risk, scrum, sprint goal, validation Sprint goals can guide the work of the development team and describe the desired outcome of a sprint. As useful as they are, sprint goals are not always correctly applied: They often reiterate the user stories to be implemented rather than the reason for running the sprint. This article introduces my sprint goal template and it explains how you can apply it to take full advantage of sprint goals . Overview of the Sprint Goal Template I find it helpful to consider three questions when choosing a sprint goal: Why do we carry out the sprint? How do we reach the desired goal? And how do we know that the goal has been met? My sprint goal template therefore consists of three main parts: the actual goal, the method employed to reach the goal, and the metrics to determine if the goal has been met. It additionally provides a header section that allows you to state to which product and sprint the goal belongs, as the picture below shows. You can download the template as a PDF from romanpichler. com/tools/sprint-goal-template/ or by clicking on the image below. The template above has grown out of my experience of working with Scrum, and it is inspired by the scientific method. Let’s have a look at the template sections in more detail. The Goal Section The goal section states why it is worthwhile to undertake the sprint. You can think of the goal as the outcome you want to achieve with the sprint and the benefit you'd like to create. Examples are: Test an assumption about the user interaction and learn what works best for the user, for instance: “Will users be willing to register before using the product features? ” Address a technical risk such as: “Does the architecture enable the desired performance? ” Release a feature, for instance: “Get the reporting feature ready so users can start creating reports. ” The sprint goal hence differs from the user stories that should be implemented. It communicates the reason for carrying out the work, and it provides purpose and motivation for running the sprint. The sprint goal should be shared: The Scrum product owner and the development team should agree on the goal and believe that working towards the goal is the right thing to do. To choose the right sprint goal I find it helpful to consider the amount of uncertainty present. In the early sprints, addressing risks and testing assumptions allows me to learn about what the product should look like and do and how it is built. Once the key risks and critical assumptions have been dealt with, I like to focus on completing and optimising features, as the following picture shows: The Method Section This section addresses the question of how the goal is met. The default Scrum answer is simple: Create a (potentially shippable) product increment using the high-priority product backlog items, and demo it to the stakeholders in the sprint review meeting. But writing software and employing a product demo are not always the best methods to achieve the goal. A paper prototype can be good enough to test a visual design idea or an assumption about the user interaction, for instance. What’s more, other methods such as carrying out a usability test or releasing software to run an A/B test may well be more effective than a product demo. You should therefore carefully choose the right method and state it in this section. But don’t stop there. Determine the test group, the people who should provide feedback and data. Who these individuals are depends on the sprint goal: If you are validating an assumption about the visual design, the user interaction or the product functionality, then you probably want to collect feedback and data from the users. But if you are addressing a technical risk, then users may not be able to help you. Consider inviting a senior developer or architect from another team instead. Stating the test group clarifies who “the stakeholders” are, who is required to provide feedback so that the right product is developed. The Metrics Section The metrics section communicates how you determine if the goal has been met. Which metrics you use depends on the method chosen. For a product demo, you may state that at least two thirds of the stakeholders present should respond positively to the new feature, for instance; for a usability test, at least three of the five testers are complete the task successfully in less than a minute; and for the release of a new feature, you might say that at least 80% of the users use the new functionality at least once within five days after launching the feature. Whichever metrics you choose, make sure that they allow you to understand if and to which extent you have met the goal. The Header Section The header section consists of the two subsections “Product” and “Sprint”. They... - Published: 2014-02-04 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/data-analysis-tips-product-managers-product-owners/ - Categories: Product Management Process, Product Vision and Strategy - Tags: product owner, teamwork Data analysis might sound a bit nerdy, but it should be part of every product manager's and product owner's tool box. The idea is simple: Investigate the data gathered, learn form it, and use the new knowledge to create a successful product. In theory, that's easy. But in practice, it can be challenging. The following tips help you get the most of your data analysis efforts. Have a Clear Research Goal Collecting the right data and analysing it effectively requires a clear research goal – understanding the reason why you carry out the work, and what you want to achieve. At the early stages of creating a product, your goal is likely to validate a critical assumption. This could be the product's value proposition, the main revenue source, or an aspect of the user interaction design. Lean Startup captures the research goal as a hypothesis, and Scrum as a sprint goal. Without a research goal you are in danger of collecting the wrong data, drawing the wrong conclusions, and moving your product in the wrong direction. In a sense, you are just trashing around hoping that the data will magically tell you what to do. Separate Data Analysis from Data Collection Once you have gathered the relevant data – for instance, by observing users, demoing a prototype, or tracking user behaviour using an analytics tool – step back, and carefully reflect on it before you make any decisions. If you come from a Scrum background, then separating analysis from data collection may be new to you. In Scrum, data is traditionally collected and analysed in the sprint review meeting without always clearly separating the two activities. This carries the danger of rushing or skipping the analysis work, and making suboptimal or wrong decisions. I hence recommend that you first collect the relevant data and then analyse it. Use the new insights to change the appropriate artefacts, for instance, your Vision Board, Product Canvas, or product backlog, select a new research goal, and start the next cycle. Keep an Open Mind Keeping open mind may sound trivial, but clinging to an idea – not the lack of a fancy analysis technique or tool – is the biggest barrier to drawing the right conclusions in my experience. I know what I am talking about: When working on a new product, I feel strongly about my own ideas, and I sometimes have a hard time changing my mind. But being too attached to an idea, or being too eager to succeed carries the danger of rejecting any data that challenges it, which may well result in a poor product. Before you carry out any analysis, take a deep breath and relax. Whenever you get tense or worked up about the data, tell yourself that it is not you, who is being challenged, but ideas, assumptions, and concepts. And ideas, assumptions, and concepts don’t have any pride; they don’t want to be right or wrong. They are just thoughts. Mitigate Cognitive Biases My fourth tip is to be aware of the cognitive biases we all have. A cognitive bias is a fault in our thinking causing us to draw the wrong conclusions. Confirmation biases, for instance, is the tendency to search for or interpret information in a way that confirms our preconceptions, and self-serving bias is the tendency to claim more responsibility for our successes than our failures. Maybe the worst thing you can do when employing a framework such as Lean Startup or Scrum is to run iteration after iteration only to look for data that confirms your ideas – and to reject the rest. This is likely to result in late failure, which is just as painful as in a traditional, sequential approach. A great way to mitigate cognitive biases is to analyse the data collaboratively. This tends to balance out individual preferences, believes, and preconceptions. Consider therefore involving the development team in the data analysis, particularly when you validate critical assumptions. Clean the Data Don’t forget to clean the data. Remove data whose quality is too poor to interpret it correctly, and discard irrelevant data. This should be easy enough – unless it’s an idea from an important customer or a powerful stakeholder. But saying yes to every idea is not going to result in a great product but in a cluttered piece of software with a poor user experience. As Steve Jobs once said: Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features. Stay true to your vision, and leverage your primary persona to determine the right features. Pivot or Persevere When analysing the data, ask yourself if it invalidates your strategy, for instance, the customer segment chosen, the product’s value proposition, the anticipated user experience, or the revenue source. If it does, pivot and change your strategy. This typically requires big amendments of your planning artefacts... - Published: 2014-01-14 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/working-go-product-roadmap/ - Categories: Product Roadmap - Tags: GO product roadmap, planning, product discovery, product life cycle The GO product roadmap is a goal-oriented product planning tool designed to work with Lean Startup and Scrum. By focusing on goals, the roadmap shifts the conversation from debating features to establishing shared outcomes. This post explains how you can apply the GO product roadmap--from deriving it from the product strategy to keeping it updated. Step 1: Do the Prep Work Before you create your GO product roadmap, you should carry out the necessary problem validation work. Investigate the target group, the problem to be solved, the business goals, the standout features, and the technical feasibility of your product. The product vision board, business model Canvas, and lean canvas are great tools to capture and validate your ideas. To see how this can work in practice, take a look at the product vision board below. The board captures the idea of creating a digital dance game together with the intended audience, the benefits, the key features, and some aspects of the business model: Step 2: Build the Product Roadmap The product vision board helps describe the market, the value proposition, and the business goals. But it does not tell us how the strategy will be executed and the specific outcomes the product is likely to achieve. Will the first product version deliver the entire value proposition and generate the desired business benefits, for instance, or will this take longer? Say we focus the first version of the dance game on user acquisition. While this is a necessary step towards the vision, it does not answer the question when revenue will be generated. This is where the product roadmap comes in. I used the sample product vision board above to create the GO product roadmap shown below. You can download the roadmap template by clicking on the picture. The roadmap shows how the strategy captured in the vision board will be executed over the next 12 months. It states the product goals, the key features, and the metrics together with a target timeframe and release/version name, indicating that achieving the goals will result in a new product version. Version 1, for instance, is focussed on user acquisition, version 2 on activation and revenue generation. Version 3 is about retaining existing users, and version 4 targets a new segment and tries to acquire new users. (I discuss in more detail in my post “The GO Product Roadmap”. ) Your roadmap should tell a coherent story about how the product is likely grow: Choose the goals carefully and consider their relationships. Which timeframe your roadmap should cover and how often you want to create a major release / new product version depends on your product. You should be reasonably confident about your roadmap and avoid speculation. If you cannot look further than the next product goal, then do not employ a roadmap! Step 3: Derive the Product Backlog With your GO roadmap in place, you can now take the next step and use the product roadmap to stock your product backlog. Use the next product goal and the key features associated with it to discover the product details including the user journeys, epics, the visual design, and the nonfunctional requirements. By following this approach, the GO roadmap connects the product strategy to the product backlog. This allows you to focus your backlog on the next product goal, which results in a smaller and more manageable product backlog that is easier to change and update. Step 4: Regularly Review and Update the Roadmap A product roadmap is not a fixed plan that is created once and then simply executed. Instead, it needs to be reviewed and adjusted on a regular basis, particularly when your product is young or the market dynamic. The picture below summarises my recommendations or reviewing and updating the roadmap. Make sure that you involve the key stakeholders in the roadmap reviews to benefit from their expertise and create strong buy-in. - Published: 2013-12-19 - Modified: 2023-02-06 - URL: https://www.romanpichler.com/blog/10-tips-agile-personas/ - Categories: User Experience (UX) - Tags: product discovery, user model Personas are a powerful technique to describe the users and customers of a product in order to make the right product decisions. This post shares my tips to create helpful personas for digital products. 1. Get to Know the Users Any persona description should be based on knowledge gained from direct interaction with the target customers and users. This is necessary to build a connection with the beneficiaries of your product, develop empathy, and understand their current wants, needs, and circumstances. Before you create your personas, you should therefore get to know your audience, for example, by observing how they currently get a job done and by interviewing them. Otherwise, your characters may not accurately represent your target group. In the worst case, they are based on ideas and speculation, not real people. Involve (some of) the team members in the user research work, including UX people and developers. This allows you to leverage their knowledge, and it establishes a shared understanding of the users and their goals. Put aside any ideas about the desired user experience and the product features when you develop your personas. Describe the characters according to your market insights. Do not make them fit your ideas and assumptions! 2. Keep your Personas Concise While every persona description should help the team members understand who the beneficiaries of the product are and what the goals they pursue, I recommend that you make and keep your personas concise so they fit on an A4 sheet of paper. Be careful not to bloat them and don't add irrelevant details, for instance, another spare time activity or a cute pet. While your personas have to contain enough information to be usable, too much detail makes them difficult to work with. Only include information that helps you make informed decisions about the user interactions, the visual design, and the product functionality. Leave out the rest. My simple, minimalist persona template wants to help you write concise personas. You can download the template by clicking on the picture below. 3. Distinguish User and Buyer Personas Create separate user and customer personas whenever the users and the customers are not the same people. This allows you to capture the user and the customer-specific needs, and it makes divergent or conflicting goals easier to see. Say we want to develop a new, advanced X-Wing Fighter, admittedly a highly implausible but fun scenario. The Rebel Alliance pilots would want a plane that’s easy to fly and well protected. But the purchase department of the Alliance is likely to be concerned with its price and maintenance cost. Employing two different personas allows you to model the user and the buyer, and to state their different goals. 4. Choose a Primary Persona Whenever you create several personas for a product, choose one primary persona. The primary persona is the character you mainly design and build the product for. Say we choose Luke, a pilot, as the primary persona in the X-Wing Fighter example above. Then meeting Luke’s goal—creating a plane that’s easy to fly and well protected—becomes our top priority. But if we choose John, a purchase team member, as the primary persona, then the resulting product would be very different. If you find it difficult to choose one primary persona, this may indicate that your target market is too large and heterogeneous, or that your product has become too big and complex. If that’s the case, then consider re-segmenting the market, unbundling the product, or introducing product variants. 5. Make your Personas Believable Your personas should help the development team empathise with the users and view the product from their perspective. To achieve this, your personas must be believable. The following three tips help you with this: Base your personas on first-hand user research (as discussed above). Choose a representative name and picture. Create and update personas together with the development team. 6. Focus on the Main Benefit or Problem I frequently see personas that contain a lengthy list of goals. While is it is perfectly OK that a persona description states more than one problem that should be addressed or benefit that should be offered, I recommend selecting one main problem or benefit—the true reason why the persona would want to use or purchase the product. This creates focus and facilitates effective decision-making. If you feel that the other persona goals are too important to omit them, prioritise the goals and put the primary one at the top. 7. Connect Personas and User Stories Make the most of your personas, and use them in the scenarios, the storyboards, the workflows, and the user stories you discover: your primary persona should be the protagonist in your stories. The template... - Published: 2013-11-25 - Modified: 2026-01-12 - URL: https://www.romanpichler.com/blog/goal-oriented-agile-product-roadmap/ - Categories: Essential Articles, Product Roadmap - Tags: GO product roadmap The product roadmap is an important product management tool. But effectively applying it can be challenging. Roadmaps are too often focused on features. This can make it hard to achieve agreement and alignment, and it can result in a plan that is too detailed and prone to change. This article introduces a new product roadmap template: the GO product roadmap, a goal-oriented roadmap that combines goals and features in a novel way, making it ideally suited for agile, dynamic environments. Introduction A product roadmap is a strategic product plan that describes how the product is likely to evolve over the coming months. Using such a plan creates a continuity of purpose; it sets expectations and aligns the stakeholders and development teams; it facilitates prioritisation and unburdens the product backlog; it can help you acquire a budget; and in the case of a public product roadmap, it can also provide reassurance to the customers. Unfortunately, I find that many product people struggle to fully leverage product roadmaps. All too often, the plans are dominated by features: There are too many features, and the features are sometimes too fine-grained. Such a roadmap makes it hard to secure agreement and create alignment; it overlaps and competes with the product backlog; and its features are sometimes regarded as a commitment rather than as a part of a high-level plan that is likely to change. Faced with this situation, I have developed a new goal-oriented, agile roadmap—the GO product roadmap. As its name suggests, goals or outcomes are at the heart of this plan, not features or other pieces of functionality. It is based on my experience of teaching and coaching product managers and product owners, as well as using product roadmaps in my own business. I did not, however, invent this specific roadmap format. It has been around for several years, and I honestly do not know who first suggested it. The GO Product Roadmap Explained The following pictures shows what the GO product roadmap looks like. You can download a PDF template by simply clicking on the picture. Let me start explaining the structure above by discussing its central and most important element, the product goal, or goal for short, which is located right in the centre of the third row. I like to start creating a GO product roadmap by identifying the desired outcomes or benefits the product should create over the coming months. These goals should describe the specific value the product will create and answer the question of why it is worthwhile to (continue to) invest time, money, and energy in developing the product. Sample goals are acquire new users, retain users by enhancing the user experience, or accelerate development by removing technical debt. Additionally, the product goals should be in line with the needs and the business goals described in the product strategy. In fact, a good way to discover the right product goals is to start with the product strategy and ask yourself how the user, customer, and business goals it contains can be broken into smaller, specific, and measurable objectives. Then order the newly created goals to tell a meaningful story of how the product is likely to evolve. I recommend using one product goal at a time. This creates clarity and alignment, and it makes it easier to track progress and understand if the desired outcome has been achieved or not. While I find it very beneficial to work with goals, in practice, these have to be balanced with time frames or dates—at least when you create an internal roadmap whose purpose is to align and guide the stakeholders and development teams. Say you work on an entertainment product like a new game that has to be available in time for the Christmas sales, then meeting this deadline will be important to create the desired value. I have therefore included a row in the template above that encourages you to state when you intend to meet the goal and realise the desired outcome or benefit. If you use the GO product roadmap to capture an external, customer-facing roadmap, then you might want to either work with coarse-grained time frames or simply remove the row. For more advice on dates, please see my article Should Product Roadmaps Have Dates? The second row states the name or version if meeting the goal results in a major release or new product version. Examples include iOS 14 and Windows 10, as well as the more creative release names Jelly Bean and Marshmallow of Android 4. 1 and 6. 0. The fourth row provides the features or product capabilities necessary to reach the goal. The features are therefore a means to an end, but not an end in themselves: They serve to create value and to reach the goal, and they should be closely aligned it. You can think of the features as the output required to create the desired outcome. Try to limit the number of features for each goal... - Published: 2013-11-05 - Modified: 2024-02-02 - URL: https://www.romanpichler.com/blog/user-stories-enough-for-a-great-user-experience/ - Categories: Product Backlog & User Stories - Tags: product definition, risk, user experience, user interface design Creating a product with a great user experience requires more than just user stories. While capturing the product functionality is important, the user journeys, the visual design, and the nonfunctional properties have to be described too. Stories should be complemented with other techniques including scenarios, storyboards, and design sketches. Creating a Great User Experience I like to think of a product description as a matrix: One quadrant describes the functionality, another one the user journeys and interactions. There is a third quadrant that captures the visual design, and a final one for the nonfunctional properties such as performance, robustness, and interoperability. All four have to be present and fit together to create a product with a great user experience, as the following picture illustrates. The four areas above are best covered by different techniques. User stories work well for the product functionality. Scenarios, workflows, and storyboards are great to describe the journeys. Sketches and mock-ups capture the design, and constraint stories describe the nonfunctional properties, as shown in the picture below. No single technique can handle all four aspects equally well. You can employ further techniques, of course, including screenshots and photos, context and activity diagrams, value stream maps, story maps, and so fourth. You can also combine different techniques, for instance, providing a design sketch for each step in a scenario. Use the techniques that work best for your product, and that enable you to describe your ideas so that they are easy to understand and to validate. (Note that I have placed storyboards between “User Journeys” and “Visual Design” in the picture above as the technique can cover both aspects. ) Identifying Assumptions and Risks There is another reason why a holistic product description is beneficial especially for new products and new features: It helps you identify all relevant assumptions and risks. If you only write user stories, chances are that you are unaware of the interaction and design risks. This may result in late failure or a poor user experience. For instance, every now and then when I shop online, I come across a website that asks me to select the payment type before allowing me to enter the payment details on the next page. Unfortunately, I typically forget to make the right choice in the first step. As a consequence, I have to go back to the initial page to correct my selection and then move on to the details page. As my payments details are lost, I have to re-enter them. While this experience may be good to test my patience, it certainly does not make me want to use the website again. Considering and validating the user interaction could have easily resulted in a better design and in a more pleasant user experience. Visualising and Managing the Four Aspects A handy tool to capture and manage the four aspects is the Product Canvas. The canvas provides three major sections: The first section is called “Target Group” and describes the users and customers with their needs in form of personas. The second section named “Big Picture” outlines the desired user experience and describes the important user journeys, product capabilities, design ideas, and nonfunctional properties. The third section called “Product Details” captures the goal or hypothesis of the next cycle together with actionable items, which may be written as ready stories. The Big Picture section plays a key role in capturing the four pieces, as the following sample canvas shows: The picture above is an extract of the Product Canvas I used to create the current version of my website, romanpichler. com. The Big Picture section in the middle contains epics to describe the product functionality, storyboards to capture the user interactions, design sketches to illustrate important design ideas, and a performance constraint. It provides a coarse-grained but holistic description of the product. For more information on the canvas, please visit the Product Canvas tool page, which also provides a downloadable template. Wrap-up When you create a new product or when you make bigger changes to an existing one, take a holistically holistic approach. Describe the relevant user journeys, the product functionality, the visual design, and the nonfunctional properties. Neglecting one of them is likely to result in a suboptimal user experience, which may well have a negative impact on the success of your product. - Published: 2013-10-09 - Modified: 2025-06-27 - URL: https://www.romanpichler.com/blog/minimum-viable-product-and-minimal-marketable-product/ - Categories: Product Vision and Strategy - Tags: product discovery, product life cycle, risk, user feedback The minimum viable product (MVP) and the minimal marketable product (MMP) are two powerful concepts: The MVP helps you test your ideas. The MMP enables you to launch your product faster. This post discusses both concepts together with their relationship. The Minimum Viable Product The minimum viable product (MVP), as originally defined by Eric Ries, is a learning vehicle. It allows you to test an idea by exposing an early version of your product to the target users and customers, to collect the relevant data, and to learn from it. For instance, to test the viability of using ads as the major revenue source, you could release an early product increment with fake ads, and measure if and how often people click on them. As lack of knowledge, uncertainty, and risk are closely related, you can view the MVP as a risk reduction tool. In the example above, the MVP addresses the risk of developing a product that is not economically viable. Since the MVP is about learning, it’s no surprise that it plays a key part in Lean Startup’s build-measure-learn cycle, as Figure 1 shows. Figure 1: Build, Measure, Learn The MVP is called minimum, as you should spend as little time and effort to create it as possible. But this does not mean that it has to be quick and dirty. But try to keep it as small as possible to accelerate learning and avoid the possibility of wasting time and money, as your idea may turn out to be wrong! While the MVP should facilitate validated learning, I find it perfectly OK to work with MVPs such as paper prototypes and clickable mockups that do not generate quantitative but qualitative data, as long as they help to test the idea and to acquire the relevant knowledge. The Minimal Marketable Product Another concept that encourages you to create a minimal offering is the minimal marketable product (MMP). It is based on the idea that less is more: The MMP describes the product with the smallest possible feature set that addresses the needs of the initial users (innovators and early adopters), and can hence be marketed and/or sold. The MMP is a tool to reduce time-to-market: It can be launched more quickly than a fat, feature-rich one. Figure 2: The Minimum Marketable Product and the Product Life Cycle Creating a product with just the right amount of features sounds like common sense. Why would we offer more features than necessary? Sadly, I have seen many organisations develop over-engineered products with lots of shiny features that provided little value to the users, but cluttered the product and increased its maintenance cost. And it’s not just the others: I am constantly tempted to add just another cool feature to a product, or to write a few extra lines in a blog post. Using the concept of an MMP helps me focus on what really matters and remove unnecessary features (and lines). A great example of an MMP is Apple’s original iPhone, which launched in 2007. The first iPhone was a complex product, and many people worked incredibly hard on it. But I find it amazing how many features the phone did not provide compared to its competitors: no copy-and-paste, no video, and no POP email integration, to name just a few. Nevertheless, the phone was still a staggering success. How come? The key to creating a successful MMP is to "develop the product for the few, not the many," as Steve Blank puts it in his book Four Steps to the Epiphany, and to focus on those features that make a real difference to the users. To discover the right features, the aforementioned MVP is a fantastic tool. Combining the Two Concepts To combine the two concepts, develop one or more MVPs to test your ideas and to acquire the relevant knowledge. This is typically done as part of your strategy discovery activities. Then use your new insights to create and launch the MMP – a simple product with the right user experience and feature set. Figure 3: Minimum Viable and Marketable Product Note that a minimal marketable product differs from a viable one: It is complete enough to be ready for general release, as indicated by the gift wrapping in the picture above. What's more, launch preparation activities have to take place for an MMP, for instance, creating advertising campaigns or gaining certification. Some of your MVPs are likely to be throwaway prototypes that only serve to acquire the necessary knowledge; others are reusable product increments that morph into a marketable product. Post Scriptum 2 November 2017 Since I wrote this post, the meaning of the term minimum viable product has started to change. People like Ash Maurya view it as the smallest offering that... - Published: 2013-09-23 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/picasso-product-owner/ - Categories: Product Roles - Tags: product owner, stakeholders, teamwork, user feedback Working as a product owner is fun and challenging at times. One challenge is to balance two separate concerns: the market with the users and their needs, and the company – the team developing the product as well as the internal stakeholders. If one aspect is neglected, the product success is in danger. As the product owner you should look outward to the market, and inward to the team and the stakeholders – similar to a cubistic Picasso portrait where the person’s eyes look in two different directions, as the following picture shows: The picture above is based on Pablo Picasso’s portrait of Nusch Éluard. Picasso created the painting in 1938 using charcoal and pencil on canvas. The Outward View: Users, Customers, and Competitors As the product owner, you should be first and foremost concerned with understanding the needs of the users and customers, and figuring out how well your product is meeting them. Helpful techniques to test your ideas and acquire the necessary knowledge include observing users, conducting user interviews, carrying out product demos and users tests, and employing MVPs. You should hence “get out of the building,” as Steve Blanks puts it, and engage with users and customers. Don’t blindly trust the opinions of senior management or the sales group. Use data to validate your assumptions. Don't forget to pay some attention to the competition, and the overall market developments. Even a company like Apple cannot afford to ignore their competitors, as the latest iOS release shows: Some of its new features, such as killing an app by swiping upwards, had been available on other devices. The Inward View: Team and Stakeholders While the users and customers should be your number one priority, creating a great product requires the product owner to closely collaborate with the development team. This collaboration is essential: It provides direction to team, and it leverages the team’s creativity and knowledge. Helpful techniques include jointly carrying out the research/validation work such as product demos and users tests, and updating the Product Canvas or backlog together. As important as it is, collaborating with the team is not enough – particularly in larger organisations. Take into account the interests and needs of the internal stakeholders including senior management, marketing, sales, service, operations, and other business groups. Involve their representatives early and regularly, for instance, by inviting them to review meetings. This allows you to align the stakeholders, and to benefit from their ideas and knowledge. (I explain how to identify and involve the stakeholders in my post Getting Stakeholder Engagement Right. ) Make sure, though, that you own the product and have the final say about what gets done. Avoid the trap of becoming a feature broker – someone who negotiates compromises between the stakeholders. Great products are not created by determining the smallest common denominator, and a product that tries to please everyone is likely to please no one. Follow your vision instead, and test your ideas with actual users. Summary You certainly don’t have to become a world-renown painter to be a good product owner. But to create a successful product, you should keep a firm eye on the market while collaborating with the development team and the internal stakeholders. Balance the two aspects, and avoid neglecting any for a longer period of time. In doubt, focus on understanding the user and customer needs and how to best address them. Leverage the ideas of the team and the stakeholders. But follow your vision, and validate your ideas early and frequently. - Published: 2013-08-06 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/innovation-and-maintenance/ - Categories: Product Management Process - Tags: scrum Keeping a product successful can be tricky: New features have to be developed to ensure that the product stays beneficial and attractive. At the same time, smaller improvements and bug fixes are required to maintain the product. How can this be done? This post shares my answer how to balance innovation and maintenance work. Two Separate Concerns Creating new features and maintaining the existing code base are different types of work: The former requires dealing with uncertainty, acquiring new knowledge, and carrying out experiments. Making small, incremental changes entails few unknowns, and the work should be done with minimum effort and no failures or mistakes. I therefore prefer to apply different approaches for the two pieces of work, as the following picture illustrates: The picture above shows two workflows: In the top one, a feature team turns new features into a new product version using a cyclic process like Scrum. In the bottom workflow, a maintenance team carries out small enhancements and bug fixes using a linear, Kanban-based process. Separate Teams To deal with innovation and maintenance work for the same product, I have a preference to work with a feature and a maintenance team, as this creates focus and it reduces task switching. It allows the team members working on new features to carry out focussed experiments, and it makes it easier for those doing the maintenance work to fix the bugs quickly.  If you work with one small team, then consider forming two sub teams - particularly once the maintenance effort consumes more than 25% of the team’s capacity. A danger of employing separate teams is the creation of a two-class society with the cool feature developer doing the innovation work, and the poor old maintenance guys slaving away at mind-numbingly boring bug fixes. To mitigate this risk, people should regularly rotate between the feature and maintenance teams. This also encourages knowledge sharing and collective code ownership. How often and how many people rotate is best determined on a case-by-case basis. For instance, two to three people could swap places at the end of each week or at the end of each fortnight, depending on which solution best balances team cohesiveness and knowledge sharing. If in doubt, discusses it with the development team in the next sprint retrospective. Separate Processes Innovation and new feature development requires the ability to develop and test assumptions, to gather and analyse data, and to leverage the new insights. In other words, the feature team requires an iterative, feedback-driven process like Scrum. Making small enhancements and bug fixes, however, does usually not require a cyclic, feedback-driven process, as there is little uncertainty present. Instead, the changes should be implemented and deployed in a fast and efficient manner. A linear, Kanban-based process is ideal for this job. Joint Ownership While using separate teams and processes for feature development and maintenance work can well be beneficial, separating product ownership is something you should avoid. I have intentionally positioned the product owner between the two workflows in the picture above, as the individual should own the existing product and the new product version. As the product owner, you should hence balance the two concerns and decide how much effort is spent on new feature development vs. maintenance in a given timeframe. This may also mean that you dedicate an entire sprint or even an entire release to carry out the necessary maintenance work and remove technical debt thereby future-proofing your product. Apple did something similar with Mac OS X. The company published a new version called Snow Leopard in 2009, which was largely a maintenance release that took If you want to make the goal of a major release to future-proof your product, then I recommend using your product roadmap to show when the planned work is likely to tae place and get stakeholder buy-in. - Published: 2013-06-27 - Modified: 2023-10-09 - URL: https://www.romanpichler.com/blog/combining-lean-startup-and-scrum/ - Categories: Product Management Process, Product Vision and Strategy - Tags: product discovery, product owner, risk, scrum, validation Can Lean Startup and Scrum be combined? And if so, how do they fit together? This post shares my answers for blending the two models, and it maps out a high-level process for product discovery and product development. The Big Picture How can Lean Startup and Scrum fit together? I find it helpful to use the former to discover if there is a problem that's worthwhile addressing and to employ Scrum to develop the actual solution. Discovery, in this sense, includes determining the product's value proposition, choosing the right market segment, and selecting its business goals and underlying business model. Product development entails identifying the right user experience (UX) and features, selecting the technologies and architecture patterns, and incrementally building a first product that is good enough to be launched. The following picture shows this approach. The process above combines the strengths of the two models: Lean Startup is great for testing out different ideas and discovering if there is a need for a new product; Scrum offers an effective framework for developing digital products including roles and responsibilities, artefacts, and coordination and planning practices—think of the product owner role, the product backlog, and the sprint review meeting. Note that there is an overlap between discovery and development in the picture above, as I find it helpful to start some of the development activities, such as addressing key UX and technology risks, once the value proposition and market have been determined. Let's now look at the two parts in more detail. Problem Discovery with Lean Startup Discovering if there is a real need for a new product requires creating a valid product strategy—figuring out the market or target group, the problem the product should solve or the benefit it should provide, the product's key features that create the desired value and make it stand out from the crowd, and the business goals—the desired business benefits it should offer. A great way to do this is by creating an initial product strategy using my Product Vision Board. Then select the biggest risk: the uncertainty that must be addressed now so that you don’t take the product in the wrong direction and experience late failure. Next, determine how you can best address the risk—for instance, by observing target users and interviewing customers. Carry out the necessary work and collect the relevant feedback or data. Then analyse the results and use the newly gained insights to decide if you should pivot, persevere, or stop—if you should stick with your strategy, change it, or no longer pursue your vision. Follow this process until no crucial risks are left—or until you have run out of time and money. The following picture summarises the process, which is based on Eric Ries' build-measure-learn model. Collaborative Discovery Any form of discovery is best done collaboratively. By involving development team members and key stakeholders—representatives from other business groups, such as marketing, sales, support, legal, and finance—you benefit from their knowledge and creativity, and it makes it more likely that you create a shared strategy that everyone supports. Additionally, you may want to involve a ScrumMaster or coach who facilitates the meetings and helps with the process, as shown in the picture below. To determine the right people for your product, identify who the key stakeholders or players are. Product Development with Scrum Once you are confident that there is a problem that’s worthwhile addressing, the focus changes to developing the actual solution. This includes understanding what the desired user experience should be, what functionality the product should provide, and how it should be built. Use the insights from the discovery work to create an initial product backlog thereby bootstrapping the Scrum process. The new focus requires adapting the team composition: The dev team members should stay and form the core of the Scrum development team. The stakeholders should also continue to participate in the development effort and regularly attend product strategy and roadmap review meetings as well sprint review meetings. New developers, testers, and other people required to create a great product are added to the development team. Together, you test out UX and feature ideas, and you incrementally develop the product. The following picture shows this approach. Bringing It All Together The following table summarises my recommendations for transforming an idea into a shippable product: FocusDiscovery/StrategizingProduct DevelopmentKey questions to answerWhat problem does the product solve? Who are the customers and users? What are the desired business benefits? What is the right user experience? What functionality should the product provide? How is the product built? Sample artefactsProduct Vision Board, Business Model Canvas, or Lean Canvas, throw-away prototypes (pre-launch MVPs), spikesProduct backlog, product increments, release burndown chartSample activitiesObservation, problem interviews, competitor analysis, and other problem validation activitiesDesigning, programming, testing,... - Published: 2013-06-12 - Modified: 2024-02-02 - URL: https://www.romanpichler.com/blog/5-common-user-story-mistakes/ - Categories: Product Backlog & User Stories - Tags: user interface design User stories are a simple, yet effective way to communicate how a user or customer employs a product. But writing user stories that help a team build great software can be challenging. The post shares five common user story mistakes and how to overcome them. Story Mania Some product owners and teams are so fond of user stories that everything is expressed as a story. This either results in some rather odd stories – stories that capture the user interface design, complex user interactions, and technical requirements; or these aspects are simply overlooked. Like any technique, user story writing has its strengths and limitations. I find stories particularly well suited to capture product functionality, and when applied properly, nonfunctional requirements. But user interface design and complex user interactions are better described by other techniques including design sketches, mock-ups, scenarios, and storyboards. Complement your user stories therefore with other techniques, and don’t feel obliged to only use stories. User Incognito A user story tells a story about a user interacting with the product. Some stories, however, omit the beneficiary altogether, or they talk about a mysterious user as in “As the user, I want to ... ” But if it’s not clear who the user is, why should the story be developed? How can we be confident that the story will benefit someone? Make sure that all your stories have a clear user or customer. As I like to work with personas, I use personas in my stories (instead of user roles). This connects each story to the right persona, and it allows me to understand if and to which extend the story addresses the persona’s need or goal. To achieve this, I use the following template: As , I want so that . Disastrous Details The devil is in the details: Some stories are too big and vague for the team to understand and implement. Others contain too much detail, or even prescribe a solution. To get the level of detail right, start with big, coarse-grained stories called epics. Epics are like bullet points: They allow you to capture an idea without committing to the details. Then break an epic into more detailed user stories by involving the development team and leveraging user feedback on early product increments. Eventually, the new user stories replace the epic. Pay particular attention to the stories that are pulled into a sprint. These stories be ready: clear, feasible, and testable. Make sure, though, that you do not prescribe a solution in your stories. Rather focus on the “what”, nor the “how”. The latter should be decided by the development team. Story Handoff Some product owners diligently write user stories, and give them to the development team in the sprint planning meeting. This handoff is usually suboptimal, as it wastes the team’s ideas and knowledge. Stories can hence be inappropriate, difficult to understand, unfeasible and not testable. User stories, however, are not meant to be standalone documents. They should be complemented by a conversation between the product owner and the team, or even better: written collaboratively. A story wants to capture the essentials, and not specify every detail. The latter would be difficult for new features and too slow and too expensive in an agile / lean context. User story writing should be a team effort, where product owner and development team create the stories together. Allocate time for a collaborative Product Canvas workshop or backlog grooming meeting, particularly when you develop a new product or new features. Trust me: Better stories and a better product will be your reward. Criteria Crisis Acceptance criteria are maybe the most misunderstood part of users stories. I have seen detailed stories with no acceptance criteria, criteria that restate the narrative, and criteria that hide new stories, or even contain entire workflows. The last two mistakes are exemplified by the following story (the narrative is on the card on the left, the "acceptance criteria" on the right): The idea behind acceptance criteria is simple: They allow you to describe the conditions that have to be fulfilled so that the story is done, that it can be exposed to the users and the other stakeholders. This ensures that you gather feedback and/or release features, and it helps the team plan and track their work: The criteria enrich the story and make it more precise and testable. (The criteria all stories have to fulfil such as "online help is available" are not stated in the acceptance criteria but in the Definition of Done. ) As a rule of thumb, I like to work with three to five criteria per story, and I am not worried if my epics don’t have acceptance criteria to start with. Ready stories, however, must provide meaningful criteria. You can find sample... - Published: 2013-06-05 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/learning-and-execution-in-scrum/ - Categories: Product Management Process - Tags: scrum, software quality, stakeholders Learning what a product should look like and do, and building solid, shippable software are different concerns. Separating the two aspects and distinguishing between learning and execution helps you manage the stakeholder expectations, select the right research and validation techniques, and choose the right sprint goals. Learning vs. Execution Learning what a product should look like and do, and building solid, shippable software are different concerns. Separating the two aspects and distinguishing between learning and execution helps you manage the stakeholder expectations, select the right research and validation techniques, and choose the right sprint goals. When we start developing a new product or new features, there are usually more unkowns than knowns, more things we don’t know than we know: We may not be clear on the user interaction, the user interface design, the product’s functionality, or the architecture and technology required to build the product. Our greatest challenge is therefore to deal with the uncertainty present, and the associated risks. As a consequence, the early sprints should focus on creating the relevant knowledge, and addressing the key risks. Selecting a testable idea (hypothesis), and running an experiment are great ways to achieve the necessary learning. As testing ideas results not only in success but also in failure, you should expect to fail in the early sprints. Your Product Canvas or backlog, and your architecture are likely to see bigger changes driven by the newly gained insights. As you acquire more knowledge, your focus should gradually shift from resolving uncertainty towards execution: building a product that is ready for general release. Rather than primarily testing ideas, you should now start completing features and incrementally adding new ones. Failure can still happen at this stage, but it is usually a sign that something has gone fundamentally wrong. Similarly, your Product Canvas or backlog should have started to stabilise and exhibit less volatility. The change of focus may also impact your Definition of Done: Throwaway prototypes used to test ideas quickly don’t have to have the same quality as software that will be shipped. You can now start ramping up the project, add new teams, and consider employing distributed teams. The following picture visualises the relationship between learning and execution for the development of a new product or a new product version: To understand how much learning and experimentation is required, consider the amount of innovation present and the technologies used: A brand-new product usually requires more experimentation than a product update; and a web app developed with standard technologies is faster and easier to create than an embedded system or a mainframe application (assuming that some market research or problem validation has already taken place). Benefits Understanding the relationship between learning and execution has three main benefits: First, it allows you to set and manage stakeholder expectations. It helpful for the stakeholders to understand that the early product increments are likely to be throwaway prototypes, and that failure is to be expected in the first few sprints. Second, it helps you choose the right sprint goals, and focus the work of the development team: Your early sprints should acquire the relevant knowledge by carrying out experiments. You later sprints should build features and get the software ready for general release. Third, it makes it easier to select the right research and validation techniques. You may want to work with user tests and product demos in your early sprints, and with releasing software to selected users in the later ones. Innovation – creating a new product or new features – involves uncertainty and risk. To build the right product with the right features quickly, you should make a concentrated effort in your first few sprints to quickly address the key risks and acquire the relevant knowledge. Then shift your focus to completing features and adding new ones by creating software that can be released. - Published: 2013-05-23 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/the-product-canvas-creation-workshop/ - Categories: User Experience (UX) - Tags: product definition, requirements, teamwork, user interface design The Product Canvas is a simple, yet powerful tool that helps you create a product with a great user experience and the right features. This post explains how you can create your initial canvas using a collaborative workshop. Overview The Product Canvas creation workshop wants to kick-start your product definition activities. It helps you change the focus from discovery and problem validation–exploring if there is a need that the new product addresses–to building a product with the right features and the right user experience. You can also apply the technique to a traditional product backlog. The following picture summarises the workshop, and the rest of this post explains the details. Attendees Everyone tasked with creating the product should attend the canvas creation workshop: the product owner, the team developing and testing the product, and the ScrumMaster or coach. This creates shared ownership, and it is likely to result in better decisions, as the entire team’s creativity and knowledge are leveraged. I generally recommend that the stakeholders – the users, and customers as well as the internal stakeholders – do not attend the workshop, but share their ideas and feedback based on prototypes and product increments, for instance, in the sprint review meetings. This allows the product owner and the team to be creative before the stakeholders provide input. Input Before you start the workshop, you should be able to confidently answer the following questions: Who are the product's users and who are the customers? What problem does the product solve? What benefits does it generate for its users? What is the product’s value proposition? What business benefits does the product creates? Why should the company invest in it? What kind of product is it? What are the three to five features that make it stand out? I like to capture the insights above using my Product Vision Board, as the following picture shows: Being able to answer the questions above means that some problem validation has taken place prior to the workshop, for instance, by carrying out user observations and problem interviews. Note that the strength of the Product Canvas is solution validation – building the right product – and not discovering if the product should be built in the first place! To ensure a smooth workshop, use a facilitator, for instance, the ScrumMaster. Organise an appropriate room with lots of wall space. Have the necessary materials available including paper sheets, paper cards, adhesive notes, masking tape, markers, and pencils. Starting out with paper and pencil is effective and fun in my experience, even if you intend to use a digital canvas. Steps to Create the Canvas To create your initial Product Canvas take the following three steps: Create personas; outline the user experience and the features; determine what to do in the first sprint, as the picture below shows: The first step creates personas based on the insights gained in your problem validation work. The personas allow you to connect with the target users and customers. Their needs enable you to discover the right product features. I also recommend using a primary persona, as it creates focus and facilitates decision-making. You can read more about personas in the post “A Template for Writing Great Personas”. The second step describes the product comprehensively but at a rough, coarse-grained level. Helpful techniques to capture the user experience and the product functionality include scenarios, storyboards, epics, constraint stories, and design sketches / mock-ups. Make sure that the product features you identify address the need of a persona, or support the business model. The third step determines what should be done in the first sprint. As you are about to start building the first product increment, you should address the greatest risk or the biggest uncertainty. This could be a lack of knowledge surrounding the user interaction, the user interface design, a product feature, or the architecture and technology. See my post “Effective Sprint Goals” for more information on choosing the right goal or hypothesis.  Finally, determine what needs to be done to reach the goal, or to test the hypothesis, for instance, creating a scenario and a paper prototype to learn more about the user interaction. The three steps above form a breadth-first approach: The product is sketched holistically, but the details are determined on a sprint-by-sprint basis. This keeps your canvas concise, and allows you to make changes quickly and effectively. Outcome At the end of the workshop you should have a Product Canvas that is good enough to start sprinting: to start building product increments/MVPs, gathering feedback, and integrating the insights gained, as the following picture shows: Make sure you create a good-enough canvas, but not a perfect one. Your Product Canvas will change and evolve anyway based on... - Published: 2013-04-29 - Modified: 2025-02-18 - URL: https://www.romanpichler.com/blog/agile-scenarios-and-storyboards/ - Categories: User Experience (UX) - Tags: risk, scenario, storyboard User stories are great at capturing product functionality. But they are less suited to describe complex user interactions. This is where scenarios and storyboards come into play: Both are great tools to describe the interaction steps. In this post, I explain what scenarios and storyboards are, how they can be used effectively in an agile context, and how they relate to user stories. Scenarios Scenarios and storyboards are great to explore and describe how a user interacts with a product. When we started to work on the re-launch of our website, for instance, I wrote the following scenario: It’s Tuesday morning, and Mary is working on her computer. She wants to book Roger Smith on a public Certified Scrum Product Owner course taught by Roman. Mary visits romanpichler. com and chooses a public CSPO class. She enters the participant information including first name, last name, email address, special dietary requirements. She then chooses a payment option and enters the payment details. Mary accepts the terms and conditions, and confirms the booking. Mary sees that her booking has been successful. After a short while, Roger receives an email confirmation with the booking details. The scenario above describes the steps Mary has to take to book a seat on one of our public training courses. Mary is a persona who represents a user of our website: an HR employee of a large company, and who’s main goal is to book one or more employees on a training course. Note that I have tried to make the scenario descriptive and engaging while focussing on the key aspects of the interaction. Storyboards Storyboards are similar to scenarios: They illustrate the interaction required to achieve a goal. But instead of using a list of steps, a storyboard visualises the interaction similar to a comic strip. Here is a sample board I created to explore another interaction for our new website: The storyboard above describes how the persona Mary books several employees on the same training course. The board consists of a series of frames. Each frame shows sample data. Underneath it, I added a brief description of what Mary does at each step. Note that I have done my best to describe the functional aspects of the interaction, and not to design the user interface: When I was working on the board, we did not have any design sketches and mock-ups available. I generally find it good practice to capture the product functionality necessary to meet the main user needs before designing the user interface. What about User Stories? User stories are another technique to describe the user interaction. A large story or epic allows us to summarise the interaction acting as placeholders for more detailed stories. I like to think of an epic is as a scenario rolled up into a brief narrative: it hides all the specifics of the user interaction. Detailed stories correspond to individual steps in a scenario, and describe a specific piece of product functionality. The first thing I usually do when working on a new product is to write epics. To discover the right ones, I use the needs of the personas. Starting out with epics helps me quickly sketch the new product functionality, and it keeps the Product Canvas or product backlog concise and manageable. But working exclusively with epics can be problematic, particularly when the epic carries risk: If we only have a coarse-grained description available, then it’s difficult to test our assumptions about how the users interact with the product. I therefore prefer to create a scenario or storyboard for risky epics, as the picture below shows: Creating scenarios or storyboards for selected epics allows me to explore the user interaction in more detail, to describe the necessary steps and their relationship. This helps me test my assumptions, for instance, by creating a paper prototype that implements the scenario in order to carry out an early user test. This is, of course, not the only way to combine scenarios and user stories. You can also derive stories from a scenario, and you can use a scenario to illustrate the relationship between different stories. The following diagram illustrates the three options: Choose the options that are most helpful in your context, and combine them, as it makes sense. You can, for instance, start with the first option (as I did above), then derive new stories from your scenario or storyboard, and finally capture the relationship between the new stories in a new scenario. - Published: 2013-04-15 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/agile-product-planning-vision-strategy-tactics/ - Categories: Product Vision and Strategy Product planning is just as important in an agile context as in a traditional setting. Unfortunately, some product owners focus so much on the product details that the strategic planning aspects are neglected. But discovering the right user stories and UX design is difficult, if we haven’t thought about the product strategy; and choosing the right strategy is hard if we haven't got a vision of what we want to achieve. This post discusses a systematic product planning approach that balances vision, strategy, and tactics. The Three Planning Levels Agile product planning comprises three levels: vision, product strategy, and tactics. The vision is the overarching goal, the product strategy the path to the vision, and the tactics are the steps along the way, as the following diagram illustrates: The level of detail increases, as we move down from the vision to the tactics: Whereas the vision is typically captured by a brief statement, the strategy communicates different aspects including the market or market segment targeted, the product price and the channels, and the product’s unique selling points (USP’s). The tactics go further by describing the product details employing, for instance, user stories, design sketches, scenarios, and storyboards. The Vision Product planning starts with creating a vision: an overarching, shared goal that guides people. A sample vision from my own company is: “Grow Pichler Consulting without increasing headcount. ” This vision may not sound mega exciting but it is very helpful for my team and me: It guides our work and focuses our efforts. Note that the sample vision doesn’t mention a specific product or service. It rather states a business goal. How the goal is realised is captured in the product strategy. The Product Strategy The product strategy is the path chosen to realise the vision. Without a strategy, making the right decisions about the product details is difficult: the functionality, the design, and the non-functional properties the product should exhibit. Having a strategy in place also prevents me from getting lost in the details. I find it helpful to capture the target group, the needs addressed, the key features of the product, and the desired business benefits in the product strategy. But you may want to add the product price, the channels, the main competitors, and other important business model elements to characterise your strategy more comprehensively.  As the strategy is a path to the vision, it may turn out to be wrong. This is particularly likely when a new product is created. Changing the strategy is also called a pivot. The Product Tactics The product tactics describe the product details: the product functionality, the user interaction, and the user interface design. Great techniques to capture these aspects are epics and ready stories, scenarios, design sketches and mock-ups, constraint stories, and sprint goals. New product features are best delivered incrementally so we can learn from the feedback we collect. I use blog posts, for instance, to create the material for my e-learning course. This allows me to learn from the feedback I receive, and to validate my strategy and the product details. Product Planning Tools I like to use the product planning tools listed in the table below: Level Sample Tools Vision Vision statement on the Product Vision Board Strategy Product Vision Board, Strategy Canvas and ERRC Grid, Business Model Canvas, and GO Product Roadmap Tactics Product backlog, product canvas, scenarios, and storyboards To capture the vision and the core product strategy I like to employ the Product Vision Board and the GO product roadmap. The Strategy Canvas and ERRC Grid help ensure that the product is adequately differentiated and stands out from the crow. The Business Model Canvas or the extended version of the Vision Board are great to describe the business model, including revenue sources and channels. To capture the details, I use the Product Canvas. The canvas allows me to work with personas, epics, scenarios and storyboards, design sketches and mock-ups, constraint stories, sprint goals, and ready stories. For an incremental product update, a product backlog may be sufficient to capture the product details. - Published: 2013-03-13 - Modified: 2025-09-02 - URL: https://www.romanpichler.com/blog/agile-nonfunctional-requirements/ - Categories: Product Backlog & User Stories - Tags: requirements, risk, user feedback This post explains how you can discover and describe non-functional requirements like performance, robustness, and interoperability. I don’t know about you, but every time I read the word “non-functional”, I feel a yawn coming on, and I start to look for something else to do. While non-functional requirements or quality attributes, as they are also called, may not be exciting, they are still important: They impact the user experience, and they influence architecture and design decisions. Say you are looking for a new car, and you’ve found one that looks great. The car also has a powerful motor, lots of safety features, and a sat nav. But during a test drive, you discover that it's noisy inside the cabin, the seats aren’t comfy, and its real-world consumption is surprisingly high. While the car has all the right features, the driving experience is not great–and that’s due to its poor nonfunctional properties. Another example is the training part of my website. If the response time is sluggish, and it takes too long to receive a confirmation once a seat has been booked, then users are unlikely to have an enjoyable experience. Other common nonfunctional requirements include robustness, interoperability, usability, and compliance with a regulation or a standard. Discovering Non-functionals As important as they are, non-functional properties are sometimes overlooked, particularly in an agile context where we spend less time with upfront research and analysis. This can be particularly painful for those attributes that apply to the entire product. If, for instance, you forget to capture that your mobile app should be available on iOS and on Android, then this may require correcting fundamental architecture and technology choices, which is likely to delay the project or make it more expensive. If you are unsure which non-functional requirements are important for your product, then I suggest you engage with the users and the development team. Try observing users, conducting problem interviews, and carrying out user tests using early product increments / prototypes. The tests allow you to discover new attributes and to understand, for instance, if the current performance is acceptable. The development team is a great partner for finding relevant non-functional requirements, particularly if the team members have worked on a similar product before or deal with support and production issues. If that's not the case, then you should consider inviting members of the operations and customer services group to listen to their views on qualities such as robustness and availability. Describing Non-functionals I like to capture non-functional requirements as constraint stories. Here is an example: I call the story above a constraint, as it constrains other user stories. Just like a regular story, the constraint has two parts: a narrative and a list of acceptance criteria. The narrative describes the non-functional requirement from the perspective of the persona, Mary. The criteria clarify the interaction and describe the environment. Both are required to validate the constraint. (Tom Gilb’s Planguage, which is an alternative approach to describing nonfunctional requirements, would call the first condition “scale” by the way. The narrative contains the “target” and the “gist”. ) Whatever format you choose to capture your non-functionals, ensure that the description is precise and testable. If I say, for instance, that booking a training course on our website should be quick, then that’s a first step towards describing the attribute. But it would be too vague to characterise the desired user experience, to help the development team make the right architecture choices, and to validate the constraint. I will hence have to iterate over it, which is best done together with the development team. Explore non-functional requirements that apply to the entire product or to important features early on. This helps you create a great user experience and make the right architecture and technology decisions. To ensure that they are always applied, you may refer to them in the product's Definition of Done. This definition states the criteria every product increment has to fulfil to be considered done in Scrum. - Published: 2013-03-06 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/the-product-backlogs-strengths-and-limitations/ - Categories: Product Backlog & User Stories - Tags: requirements, simplicity, user interface design The product backlog is an important tool: It lists the ideas and requirements necessary to create a product. But is it always the right tool to use? This post discusses the strengths of a traditional product backlog together with its limitations. It provides advice on when to use the backlog, and when other tools may be better suited. The Good The product backlog lists the outstanding work necessary to create a product. This includes ideas and requirements, architectural refactoring work, and defects. The good thing about a list is that it requires prioritisation decisions: The product owner has to decide when an item should be implemented. Prioritisation provides direction to the team, and it supports sprint planning: The backlog items are not only ordered from top to bottom, but they are detailed according to their priority. The items at the top should be small and ready for the next sprint. Having the backlog prioritised makes it also possible to carry out release planning: It helps anticipate when an item is likely to be delivered (using a tool like the release burndown chart). The Bad Working with a list is helpful when the focus is on adding functionality, on writing and prioritising user stories. But creating a great product requires more than just user stories. The user journeys, the visual design, and the nonfunctional properties have to be considered too. Unfortunately, they don’t fit into a list. As a consequence, agile teams either forget about capturing the user experience, or they keep the UX artefacts separately, for instance, on a wiki page, or in a project management tool. While the former can result in a product with a poor user experience, the latter isn’t great either: information that belongs together is stored separately. This makes it more difficult to keep the various artefacts in sync, and it can cause inconsistencies and errors. The Ugly I have seen quite a few ugly product backlogs: disguised requirements specifications copied into an Excel spreadsheet, JIRA backlogs that made it impossible to find the right user story, and backlogs with five loosely related epics scribbled on paper cards and carelessly stuck on the office wall. While the product backlog is hardly to blame for this, its list-based nature does not always provide teams with the support they need, particularly for creating a new product. Conclusion A traditional, linear product backlog works best when the personas, the user interaction, the user interface design, and the operational qualities are known, and don't not have to be stated. This is usually the case for incremental product updates. For new products and major updates, however, I find that a traditional product backlog can be limiting, and I prefer to use my Product Canvas. No single tool fits all needs and excels in all scenarios. Choose your tool to capture ideas and requirements wisely, and use the degree of innovation present in you product to select the right one. This post was last updated on 28 January 2014. - Published: 2013-02-28 - Modified: 2023-02-08 - URL: https://www.romanpichler.com/blog/product-demo-tips/ - Categories: Product Management Process - Tags: scrum, stakeholders, user feedback, validation The sprint demo is a standard technique in Scrum to collect feedback from users, customers, and stakeholders in order to maximise the chances of developing a successful product. Sadly, not all product demosI have attended were effective. This article provides ten practical tips to fully leverage product demo, collect helpful user feedback, and make the right product decisions. Understand the Purpose of the Product Demo In Scrum, the latest product increment is demoed to users, customers, and stakeholders in the sprint review meeting. While the product demo allows you to understand which stories have been completed and how much progress has been made, using it as a qualitative market research technique unleashes its real potential. Its main purpose is then to collect feedback from the meeting attendees to validate the product decisions taken and improve the product. Focus on the Sprint Goal Understand what questions you would like to get answers to, and what ideas you would like to validate before conducting the demo. Your sprint goal should help you with this: If, for instance, your sprint goal is to test your user interface design ideas, then you should plan the demo accordingly. You may want to present different versions as mock-ups to the users to understand which one they prefer and why that's the case. Having one sprint and research goal helps you focus the presentation. It increases the likelihood to collect relevant feedback, and it makes it easier to analyse the feedback. Invite the Right People Use your sprint goal to decide who can help you validate your ideas and improve the product and who should therefore attend the demo. If the goal of the sprint is to establish the right software architecture decisions, then end users are probably not the right attendees. In the worst case, the demo could be a frustrating experience and prevent them from attending another review meeting. But if the goal is to better understand how users are likely to interact with the product, then end users should be present. Otherwise, you are in danger of collecting lots of interesting but irrelevant or misleading data. Explain what the Product does for the Users To receive helpful feedback, describe what the product does for its users. A great way to do this is to use a scenario. If you develop a mobile banking application, for instance, you may want to say: “Imagine you are on the train on your way to work, and you remember you still need to pay your water bill. You open the banking app, log on, and then you would see the screen I am showing you now. ” Engage in a Dialogue and Ask Open Questions The product demo should not be a one-way communication or a sales event. Instead, its objective is to generate valuable feedback that allows you to gain new insights. Unfortunately, users and other stakeholders don’t always provide helpful feedback straight away. You sometimes have to ask the right questions and create a dialogue. For instance, if the feedback you receive is “Great demo, I really like the product”, then that’s nice. But what does it actually mean? How does it help you, and what can you learn from it? Dig deeper, ask why the individual likes the product, which aspects are particularly valuable, and which could be improved. Using open questions is a great way to do this. You might say, for example: "Thank you for the feedback. Can you please tell why you like the product? Is there a specific aspect that makes it particularly valuable? " Appreciate Difficult Feedback It can be tempting to seek positive feedback that confirms the decisions you have taken and appreciates the hard work you put in. But if you don't hear critical feedback, you'll find it hard to improve your product. Therefore appreciate negative feedback and try to understand the underlying causes, for example, why somebody dislikes a feature or disagrees with the way a user journey is realised. Watch out for confirmation bias, the tendency to look for data that confirms preconceived ideas. I find that the longer we work on a product, the more we tend to become attached to it, and more likely it is to suffer from confirmation bias. Capture the Feedback To be able to evaluate the feedback afterwards, I recommend you record the feedback you receive, be it by videoing the demo together with the attendees reactions or by taking notes. Separate Research from Analysis I prefer to separate collecting the feedback from analysing it. This allows me to listen to the users, and to decide afterwards what I can learn from the information gathered. It also makes it possible to compare notes with the team members thereby leveraging the collective wisdom of the group and mitigating cognitive biases, think of confirmation bias, which I mentioned above. But... - Published: 2013-01-10 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/product-ownership-empowerment/ - Categories: Product Roles - Tags: product owner, stakeholders, user feedback Playing the product owner role can be challenging: It requires the authority to say no to ideas, request, and feedback in order to achieve product success, as I explain in this article. An individual truly owns a product if the person has the right to say no. Don’t get me wrong. I don’t want to promote a negative mind-set or can’t-do attitude. But as Steve Jobs said: “Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features. ” If we take on every idea or feature request, we are likely to end up with a feature soup, bloated product that is expensive to develop and that provides a poor user experience. In Scrum, feedback from users and stakeholders is regularly used to develop the right product, as the following picture shows: In the picture above, the team creates a product increment. Feedback is then obtained by exposing the increment to the right people. These include users and customers as well as internal stakeholders such as representatives from marketing and sales.  Demoing or releasing the increment results in new ideas or requirements. Sometimes powerful stakeholders such as a management sponsor or customer request new features based on what they have seen. Any constructive feedback is good feedback and should be welcome, but not all feedback is helpful and relevant. It's the job of the people creating the product to carefully analyse the feedback and make that decision.  Feedback is irrelevant when the data quality is poor, for instance, if a piece of information is unclear or ambiguous, or if the feedback is not helpful to reach the vision or release goal. If that's the case, the feedback or request should be disregarded, symbolised by putting it in the trashcan in the picture above. Disregarding feedback implies the right to say no. It may mean telling a customer that a feature request will not be fulfilled, at least not in the near future, or letting a powerfulstakeholder know that her idea cannot be taken on board. Being empowered to push back, to filter and select, puts the product owner in control. It allows the Scrum team to move fast, try out new ideas, and make quick decisions. But it also implies being responsible for making the product a success: developing a product that does a great job for its users and the company. If you feel that you are not in a position to say no and reject ideas, feedback, and requests, then reflect on the causes. It is due to the organisation's lack of understanding of how product management works, and what the authority and responsibilities are? Do you miss trust and support from the stakeholders due to a lack of expertise or people skills? Or have you possibly been too accommodating in the past trying to please everyone? In the first case, your ScrumMaster may be able to help you educate the stakeholders and establish an effective product management organisation. In the second case, consider increasing your product management and people skills. In the third case, be courageous and bring to mind the fact that as the product owner, you must make tough decisions and you cannot please everyone without running the risk of making weak compromises. At the same time, take a real interest in the people who provide feedback and empathise with them. Explain to the indivduals why you cannot fulfill a request or implement an idea. This will make it easier for them to accept your decision. - Published: 2012-12-11 - Modified: 2022-12-12 - URL: https://www.romanpichler.com/blog/effective-sprint-goals/ - Categories: Product Management Process - Tags: risk, scrum, sprint goal, stakeholders, teamwork, user feedback, validation Working with a sprint goal is a powerful agile practice. This post helps you understand what sprint goals are, why they matter, hand you can write and track them. The Sprint Goal Explained A sprint goal describes the purpose of a sprint. It provides a shared objective, and states why it’s worthwhile undertaking the sprint. Sample sprint goals are “Learn about the right user interaction for the registration feature” and “Make the reporting feature available to the users”. If you use a product goal, then each sprint goal should be a step towards this overarching objective. As a rule of thumb, teams should work with one shared goal. This ensures that everyone moves in the same direction. Once the goal has been selected, the team implements it. Check at the end of the sprint if the goal has been met. Say you want to learn if users are willing to register as the first step in the user journey. Then use the product demo or a usability test at the end of the sprint to validate if you have met the goal and understand if it's OK to ask people to register first or if this creates a barrier to adoption. Sprint Goal Benefits I have found that working with a sprint goal has five main benefits, particularly for new products and new features: It facilitates prioritisation and effective teamwork; it makes it easier to obtain and analyse feedback; and it helps with stakeholder communication. Supports Prioritisation A shared sprint goal facilitates prioritisation: It makes it easier to determine which stories should be worked on in the next cycle. Here is how I do it: I first select the goal. Then I explore which epics have to contribute to it, and I break out small detailed stories from the epics. Finally, I order the new ready stories based on their contribution to the goal. Creates Focus, Facilitates Teamwork, and Guides the Development Team Sprint goals create focus, facilitate teamwork, and provide the basis an effective sprint planning session. A shared objective guides the development work, encourages creativity, and enables commitment. Teams don't commit to individual stories in Scrum; they commit to the sprint goal. Helps Obtain Relevant Feedback Employing a sprint goal makes it easier to collect the right feedback. If the goal is to evaluate the user experience, for instance, then it is desirable to collect feedback from actual target users. User representatives should therefore attend the sprint review meeting. But if the goal is to reduce technical risk by evaluating different object-relational mapping tools, then it is probably more appropriate to invite an experienced developer or architect from another team to discuss the solution. Makes it Easier to Analyse the Feedback Working with a sprint goal helps analyse the feedback obtained. If the team works on several unrelated stories in the same sprint then it can be tricky to relate the feedback to the right user story. This makes it harder to understand if the right product with the right features is being built. Supports Stakeholder Communication Finally, imagine meeting the big boss in the elevator and being asked what you are working on. Chances are that without a sprint goal, the boss will be bored to death, jump onto a specific story, or he will have left the elevator before you are finished listing all the things you do. Using a sprint goal helps you communicate the objective of the sprint to the stakeholders. This allows them to understand what the sprint is about and to decide if they should attend the next sprint review meeting. Writing Effective Sprint Goals Like any operational goal, a sprint goal should be SMART: specific, measurable, agreed upon, realtistic, and time-bound. As sprints are time-boxed iterations, every sprint goal is naturally time-bound: It has to be reached by the end of the sprint. A sample goal of an early sprint is to learn more about the desired user experience (a desirability aspect), the software architecture (feasibility), or the pricing model (viability). To pick the right goal, choose the risk that is likely to hurt you most if it is not addressed immediately. When selecting your sprint goal, remember that trying out new things requires failure. Failure creates the empirical data required to make informed assumptions about what should and can be done next. Failing early helps you succeed in the long term. After you have run a few sprints, the emphasis usually starts to shift from resolving uncertainty to completing features so that they can be released – at least to selected users. This allows you to gather quantitative data and to understand how users employ your product in its target environment. The shift should be reflected... - Published: 2012-11-07 - Modified: 2024-02-02 - URL: https://www.romanpichler.com/blog/epics-and-ready-stories/ - Categories: Product Backlog & User Stories - Tags: epic, scenario, stakeholders, teamwork, user feedback, user interface design, user story This post explains how to write user stories at the right level of detail, and how to derive small, ready stories from big, coarse-grained epics. One of the things I love about user stories is their flexibility. A user story can be big, medium-sized, or small. This allows us to sketch a product with big stories, and then progressively add more detail and refine them into smaller user stories, as we learn more about how to meet the user needs. But this flexibility comes at a price: I often see user stories that are too small or too big, that contain too much or not enough information. Deriving the right stories, and getting the level of detail right can be challenging. This post suggests a simple, yet effective solution: distinguishing between two types of user stories, epics and ready stories, and deriving the ready stories with the help of a shared sprint goal or hypothesis. Epics Epics are big, coarse-grained user stories. An epic sketches a feature or bigger piece of functionality. It acts as a placeholder for more detailed stories. Think of the epos Odyssey. It's a collection of stories about the adventures of Ulysses including meeting the Sirens, and defeating a Cyclops. Epics allow you to sketch the product functionality without committing to the details. This is particularly helpful for new products or major product updates, as it buys you time to learn more about the users and how to best meet their needs. It also reduces the time and effort required to integrate new insights: If you have lots of detailed stories, then it’s often tricky to relate the feedback you receive to the right stories, and it can be a big effort to change them without introducing inconsistencies.  Let’s have a look at a sample epic: The epic above tells us that the persona John wants to register for an event. The details of the event and the registration are left open for now. Similarly, the acceptance criteria – captured on the right card – are sketchy too. The details will emerge, as we learn more about the event registration by developing software and exposing it to the right people. Ready Stories Ready stories are small, detailed stories that can be implemented. These stories have to be clear, feasible, and testable: Everyone should have a shared understanding of the story’s meaning; the story should not too big or complex; and there has to be an effective way to determine if the functionality works as expected. A ready story should also take into account additional aspects: the user interface design and the operational qualities that are specific to the story. Examples of the latter are performance or interoperability. I prefer to work with a paper-based design sketch to capture the user interface, and constraint story cards to describe the qualities, as the following picture shows. The ready story above is much more specific and detailed than the sample epic discussed earlier: The details enable the development team to implement and test the story successfully. From Epics to Ready Stories So far we’ve simplified things by distinguishing between epics and ready stories. But we haven’t discussed yet how ready stories are derived from epics. My solution is to identify a sprint goal or hypothesis for the next iteration before the ready stories are written, as the following picture illustrates: Step 1: Write the Epics Let me show you how this process can be applied using my Product Canvas tool. The canvas is essentially a multi-dimensional backlog that allows you to describe your product holistically. The Product Canvas supports working with epics and ready stories by providing dictated sections. It also offers the context for finding the right epics: The user journeys – scenarios, workflows, or storyboards – are a great hunting ground for epics. The epics are placed on the “Epics” section, as the following picture illustrates. Step 2: Select the Goal of the Next Sprint Once the epics sketching the product’s main functionality have been written, I populate the design and constraints sections on the canvas. Then I select the goal of the next sprint – either to address the most critical risk and/or to deliver functionality to the stakeholders including the users. Examples of a sprint goal are: “Validate our central user interface design ideas”, or “Be able to release epic B”. The sprint goal is placed at the top of the Ready Stories section, as the following picture shows. I find it very beneficial to involve the entire team, the product owner and the development team, in selecting and formulating the sprint goal. This leverages the team’s collective knowledge, and... - Published: 2012-10-11 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/working-with-the-agile-product-vision-board/ - Categories: Product Vision and Strategy - Tags: product discovery, product manager, product owner, risk, startup "This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland, and I show you how deep the rabbit-hole goes," says Morpheus to Neo in the movie “The Matrix”. This quote reminds me of the choice we face when dealing with a new product idea: Should we walk away from it, or should we implement it? To help you decide if and how to progress an idea, I have developed the Product Vision Board. In this post, I show how the board can be applied to kick-start the product discovery process and to create a new digital product. A New Product Idea I’ve recently had the idea of developing an electronic tool, a digital version of the Product Canvas. The canvas is a multi-dimensional product backlog that allows teams to properly capture the user experience including the user interaction and the user interface design. Since I published the template in July 2012, I have received lots of encouraging feedback. Some people suggested an electronic version, and Johan Steenkamp started to work on a free, web-based product canvas as part of his Business Model Fiddle. After loosely collaborating with Johan for a couple of months, I was wondering if I should offer an enhanced digital canvas myself. To help me make the right choice, I created a vision board for a new electronic product canvas. But before I introduce the board to you, let me briefly remind you what the vision board is all about. The Product Vision Board The product vision board captures the initial ideas and assumptions for a new product, as the following picture illustrates. The board above describes the overarching vision that guides the product. It states who should use and purchase the product (Target Group), why people would want to use and buy it (Needs), what the key product features are (Product), and why the organisation should invest money in the product (Value). It’s important to understand that the vision board is intended to initiate the innovation and product discovery process. It does not want to describe the users, the product, and the business model comprehensively or in great detail. It rather captures the critical assumptions, those assumptions that will make or break the product. If you want to capture how the product is monetised together with its business model, then I recommend that you either use the extended version of the vision board or complement the simple version shown above with the Business Model Canvas. Creating the Initial Product Vision Board To clarify my thoughts, I sat down and created a new product vision board. While I am a great fan of simple, physical tools, I decided to create an electronic vision board, as I wanted to share the board with Johan who lives in New Zealand, whereas I am based in the UK. Here is the initial product vision board I came up with: To create the board, I started with the vision statement keeping it intentionally broad. This allows me to follow the vision even if my electronic tool idea turns out to be ill conceived. At the same time, the vision reminds me that the new product is only means to an end: to help organisations create great products. Next, I recorded my ideas about the users. In addition to product managers and product owners, individuals setting up their own business might find the tool helpful. As I am particularly unsure about this group, I have marked it in italic. I use this convention on the other sections of the board, too. I then focussed on the user needs formulating them as goals, for instance. Note that I selected one need--being able to work with one shared canvas, rather than listing different ones. This makes it easier to test the need. If you want to state more than one need on your own board, then prioritise them and focus on the most important one. In the next step, I listed those product features, which I consider believe will help the product stand out. I was careful not state a specific solution such as an iPad app, or a web app. This would be premature at this point in time and narrow down the options too quickly. Before I decide on the product specifics, I want to validate the needs of the target group first. As a consequence, the vision board is likely to change based on the new insights. Finally, I stated the motivation for my business to invest in a digital canvas. Similarly to the other sections, I have tried to focus on what I believe are the key assumptions and not be tempted to design the business model before I haven’t learned more about the users and their needs. After all, the business model will only work if the needs are met well! Validating the Product Vision Board The next step for me is to refine and then validate the board using an iterative process, as the picture below shows. As the biggest risk is the question if a strong-enough need for an electronic canvas exists, I am planning to conduct a series of... - Published: 2012-09-21 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/the-scrum-cycle/ - Categories: Product Management Process - Tags: product owner, scrum, stakeholders, user feedback Scrum is a simple framework based on the idea of inspect and adapt: Create a product increment, show it to the stakeholders, and use the feedback to see if the right product is developed. This post describes what I regard as the essence of Scrum: a cyclic three-step process. It shows how the three steps help create a product with the right features and the right user experience (UX). Linear Scrum A linear Scrum implementation transforms the highest-priority product backlog items into a product increment but it does not collect any user feedback to update the product backlog and consequently change the product, as the following picture illustrates: Such a linear application of Scrum assumes that team already knows what the product should look like and do. This may be appropriate for smaller incremental product updates and maintenance releases. But this assumption does not hold true for new products and new features where discovering how the user needs can be best met is a major challenge. Cyclic Scrum To find out which user experience (UX) and which features the product should provide, a cyclic process that facilitates experimentation and learning is required: We only discover and learn new things by trying out an idea. Luckily, Scrum's cyclic nature enables product owners and agile teams to learn about what to build and how to build it: The product evolves based on the feedback of users, customers, and other stakeholders.  Applied correctly, this results in a desirable product — a product that does a great job for its users, and it reduces the risk of building something that nobody really wants.  The following picture describes three key steps that help you iterate towards a great product. The diagram above is inspired by Eric Ries' Lean Startup circle. You can find out more about how Lean Startup and Scrum can fit together in my post "New Product Development with Lean Startup and Scrum". Step 1: Select the Sprint Goal and Create the Increment In the first step of the cycle, product owner and team select a sprint goal that describes why the sprint should be run and what the desired outcome is. At the early stages of a development effort, the sprint goal should focus on testing critial assumptions and acquiring the relevant knowledge.  These include assumptions about the user interaction, the product functionality, the visual design, and the technologies and the architecture. You can download a handy sprint goal template that facilities experimentation from the tools section of my website. Once the sprint goal has been selected, the team develops the appropriate product increment. This could be a throw-away prototype (such as a paper prototype or a spike) or working software that can be released —depending on what's best to meet the sprint goal. A paper prototype might be best, for instance, to test assumptions about the user interactions ("Are users willing to register first before they use the main features? "); a throwaway mock-up may be appropriate to test user interface ideas ("Will corporate colours resonate with the target group? "), and a software increment will help to run a more in-depth usability test or to release the product to selected users to run an A/B test, for instance. Step 2: Gather Feedback and Data In the second step, the product increment is exposed to the stakeholders and feedback or data is collected. Scrum's default technique is a product demo which is performed as part of the sprint review meeting. But you can of course also run a usability test or release the software to collect the relevant data. As a rule of thumb, use different methods across the development cycle and combine qualitative and quantitative techniques. Step 3: Analyse and Change In the third step, the Scrum team analyses the feedback and the data obtained. This includes reviewing the quality of the data, and assessing its relevance. Examining the data should help the team understand if a desirable product is being developed. But it does not mean saying yes to every idea or stakeholder request! Having said that, you should welcome negative feedback. If all you get is positive responses, then you are likely to ask the wrong questions or the wrong people. (For more information please see my post "Data Analysis Tips for Product Managers and Product Owners". ) Finally, the Scrum team uses the newly gained insights to adapt the product backlog. This may result in bigger or smaller changes. If, for instance, the feedback invalidates the user interaction design, bigger changes are likely to be required. The earlier you are in the process of creating a new product or new features, the more likely it is that your product backlog changes significantly. Once you have addressed the key risks and critical assumptions in your backlog, smaller changes or refinements are usually sufficient. (I have written more about this in my post "Learning and Execution in Scrum". ) Wrap-up Scrum defines a cyclic process that encourages learning... - Published: 2012-08-23 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/the-three-innovation-drivers/ - Categories: Product Vision and Strategy - Tags: product manager, product owner Employing experiments is a powerful technique to facilitate the creation of new products and new features. But to experiment effectively, we need to be clear where innovation takes place and uncertainty resides. Is it the user experience, the business model, or the technologies? Without the right understanding, it’s difficult to ask leap-of-faith questions, formulate meaningful hypotheses, and carry out helpful experiments. This blog posts introduces a simple model that helps you effectively innovate. Desirability, Viability, and Feasibility I find that product innovation usually occurs in the following three areas: the user experience (UX) and the product features, the business model, or the product’s architecture and technologies. Apple’s first iPhone is an example of a product whose innovation was focused on the user experience and new features such as mobile Internet; the new generation of LED televisions exemplifies technology-driven innovation; and Amazon’s cloud service is an example of business model innovation. When creating a product with a great user experience, the biggest challenge is to ensure that it is desirable, that the product does a great job for its users and that the user will want to employ it. For business model focussed innovations, it’s developing a sustainable business model, and for technology-driven innovations, it’s dealing with feasibility – applying the new technologies successfully. Desirability, viability, and feasibility hence form three important innovation drivers, as the following diagram shows. The diagram is inspired by the design constraints discussed in Tim Brown’s book Change by Design. For instance, if your product’s competitive advantage is intended to be the user experience then you should aim to understand what makes the product desirable, develop appropriate hypotheses, and employ focussed experiments, for instance, A/B tests to see which feature variant is more attractive to the users. The same holds true for viability and desirability. Applying the Innovation Drivers When I start to work on a new product, I use the three drivers to understand where innovation occurs and how much uncertainty is present in the development effort. I usually apply the drivers by creating a Product Vision Board sketching the product’s target users and customers, the needs to be addressed, the key features, and the value the product should create together with the product owner and the development team. We then explore and mark the areas of uncertainty. Here is how this can work in practice: I recently met with the team members of a new product development project of a major UK retailer. The team’s vision was to create new software in order to increase the revenue generated from creating custom solutions for the company’s customers. Together, we created the following product vision board using a piece of flip chart paper and adhesive notes (the details on the notes have been blurred to hide the details): The two pink stripes indicate the areas of uncertainty and the product’s innovation drivers: UX/features and the business model, and desirability and viability. The former is related to creating a product that does a great job for the company’s sales staff and its customers. The latter refers to the ability to achieve the desired business goals including the revenue increase targeted. The exercise created a shared understanding about the challenges the team was facing, focussed the team’s work, and improved the communication with senior management. The three innovation drivers help you understand where innovation occurs and where uncertainty is present. This enables you to ask the right questions, formulate appropriate hypotheses, and carry out helpful, focussed experiments. - Published: 2012-07-16 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/the-product-canvas/ - Categories: Product Backlog & User Stories, User Experience (UX) - Tags: product owner, user feedback, user interface design This post introduces my Product Canvas, a simple but powerful tool that helps you create a product with a great user experience and the right features. It combines agile development and user-experience design by complementing user stories with personas, storyboards, scenarios, design sketches and other UX artefacts. Read on to find out more. A Sample Canvas The best way to understand the Product Canvas is to look at an example. Imagine that we want to develop a game that helps children learn about music and dancing. A canvas for such a game could look like the one below. The sample Product Canvas above contains the product name, the product (or release) goal and the metrics to measure if the goal has been met. The first bigger section states two personas characterising the target users and customers with their needs. The next section sketches important aspects of the product using epics to describe the product’s functionality, a mock-up to capture the user interface design, a storyboard to illustrate the user interaction, and a constraint card to express the platform for which the game is developed. The section on the right provides a goal for the next sprint and the details necessary to reach the goal. The Sections Explained As you have probably noticed, the Product Canvas combines form and function, a structure together with suggested techniques.  The following diagram and the text below the sections of the canvas.  You can download the canvas template for free from romanpichler. com/tools/product-canvas or by simply clicking on the picture below. Name simply states the name or version of the product. The Goal is the product or release goal, the objective that should be met, for instance, to acquire, activate or retain users. If you use the GO product roadmap than you can simply copy the relevant goal stated on the roadmap. The Metrics provides the measure to determine if the goal has been met, for instance, number of downloads or daily active sessions.  If you use the GO product roadmap than just copy the relevant roadmap metrics. The Target Group describes the target customers and users as personas. The section explains who we believe is likely to use buy and use the product and why. I discuss personas in more detail in my post A Template for Writing Great Personas. Choose one primary persona – the persona you mainly create the product for. Employing a primary persona helps you make the right prioritisation decisions and create a product with a great user experience. Your primary persona should be at the top of the building block to signal its importance. The Big Picture describes what is takes to meet the persona goals. It captures the user journeys, and the visual design required to create the desired user experience. As its name suggests, it wants to describe your product holistically at a high-level.  The section is similar to the outline of a book: It captures the contents without discussing the details. Scenarios, storyboards, workflow diagrams, and story maps are great techniques to describe the user journeys on the Big Picture. Each journey shows how a persona interacts with the product and the steps the individual has to take to meet a goal. The product functionality on the Big Picture is best captured as epics, which are big and coarse-grained user stories. Epics allow you to describe your ideas without having to commit to the details. This saves time, and it makes it easier to update the canvas with new insights. Constraint stories help you capture the nonfunctional requirements that impact the user experience and the software architecture.  You can capture your visual design ideas on the Product Canvas as design sketches, mock-ups, screen-shots, and photos. The Big Picture design artefacts should focus on the critical design aspects of your product—for instance, the design of selected screens or pages. None of these techniques are mandatory, of course. They rather provide you with a starting point.  Choose those techniques that are appropriate for your product. Use additional ones as it suites your needs. The Product Details provide a goal for the next iteration and just enough implementable items to reach the goal, for instance, to address a risk and to acquire relevant knowledge, or to complete a feature. Depending on the goal, I use different techniques to capture the implementable items. For goals that require coding, ready stories are very helpful. These are small, detailed stories that feed the next cycle and that help create a product increment or minimal viable product (MVP). They are derived from the epics, and are necessary to reach the sprint goal. Make sure you write acceptance criteria for your ready stories.  Order the implementable items from one to n, for instance, first, second, third, and so on, to maximise the chances that you reach your goal. Putting the Users First The canvas is designed so that the information flows from left to right starting with the personas. This puts the user at... - Published: 2012-06-14 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/intuition-data-agile-product-management/ - Categories: Product Management Process, Product Roles - Tags: user feedback Making the right product decisions is tough. Some product owners trust their intuition, others rely on data. Find out which approach is more helpful to create a successful product. Data-driven “But with the blast shield down, I can't even see! How am I supposed to fight,” asks Luke Skywalker in the Star Wars movie Episode IV while training with his lightsaber on board of the Millennium Falcon. “Your eyes can deceive you. Don't trust them. Stretch out with your feelings,” answers Ben Kenobi. This little story illustrates a fundamental question: Should we trust our intuition or our analytical abilities to make decisions? Empirical approaches to product development such as Scrum and Lean Startup encourage us to leverage data to make decisions: We use product increments or MVPs to gather the relevant information from users, customers, and other stakeholders. Analysing the data should then allow us to draw the right conclusions and to adapt the product–to pivot or persevere. The following picture illustrates this approach: If this blog post, for instance, does not attract as many comments and doesn’t generate as much Twitter traffic as I had hoped, does it mean that I must rewrite or remove it? The data alone is not going to tell me the right answer. Intuition-lead “If I had asked people what they wanted, they would have said faster horses. ” This Henry Ford quote shows how difficult it can be for customers to tell us what they really need. As product owners, we have to be creative and envision the future product, a product that we believe will benefit its users and the company providing it. Vision, however, is based on intuition or instinctive knowledge. It’s based on what we feel is right, aesthetically pleasing, and helpful. It's the opposite of a data-driven, empirical approach: While using our vision to guide our decisions may seem attractive, there is a dark side: I could, for instance, follow my vision of creating what I believe would be a brilliant, amazing book only to find out after its publication that nobody really wants to read it. Time and money would be wasted, revenue lost. Reality Check Let’s recap: Data alone is unlikely to tell us what to do, and trusting our intuition is risky. Human beings are prone to make errors, and our intuition can be distorted by cognitive biases. Luckily, the two approaches complement each other: As product owners, we need a vision of where we want to take our product, and we should believe that the product can benefit its users and the company providing it. At the same time, we should be critical of our ideas, and constantly ask ourselves: “Why would anybody want to use our product? Why should the company invest in it? ” We should carefully analyse the data obtained form users, customers, and other stakeholders to repeatedly test our ideas and assumptions, to check that we are on the right rack, and that it’s worthwhile to continue. This is illustrated by the following picture: So what should I do if the data suggests that this post is not as exciting to my readers as I would have hoped? It would certainly allow me to investigate the likely causes: Is the topic not particularly relevant? Did I present it in the wrong way? But ultimately, it’s up to me to decide what I do about the post, and if I continue writing about the subject. As the product owner, I am responsible for the success of the product. No clever algorithm or analytics tool will be able to make the right decision for me. Summary Innovation relies on our intuition as much as on testing our ideas by gathering and analysing the relevant data. As product owners, we should neither blindly trust our intuition, nor should we expect that the data answers all our questions. Instead, we should use both, intuition and data, to guide our decisions. You may be wondering what happened to Luke Skywalker trying to block the laser shots with his lightsaber without being able to see. He succeeded, of course, and Ben Kenobi told him: “You see? You can do it. ” Interestingly, Luke employed his intuition and the data available to him, that is, the rather unpleasant experience of being hit by the laser remote. In fact, the experience helped him to improve its intuition, to anticipate and intercept the shots. Now, would it be data-driven or intuition-lead to claim that this enabled him to become a great Jedi? - Published: 2012-05-29 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/choosing-the-right-lean-and-agile-innovation-practices/ - Categories: Product Vision and Strategy - Tags: product life cycle, teamwork Innovation can be a tricky thing: Not only does it means different things to different people, but creating a brand-new product requires different practices compared to updating a mature one. This post helps you choose the right lean and agile practices to innovate successfully. It introduces three innovation stages and explains how product ownership, process, and project setup are influenced by the amount of uncertainty present. Three Stages of Innovation Innovation forms a continuum ranging from maintaining an existing product to creating a brand-new one. To select the right practices, I find it helpful to divide the continuum into three stages: a maintenance stage, a new feature stage, and a new product stage, as the table below shows. The table is inspired by Nagji and Tuff’s HBR article “Managing Your Innovation Portfolio”. Stage 1 Stage 2 Stage 3 Maintaining a product Creating new features Creating a new product Innovation is low Innovation is medium Innovation is high In the table above, the degree of uncertainty and innovation rises from left to right. Whereas stage three focuses on protecting existing assets, stage one and two are about investing in the future. The three innovation stages correspond to the product’s lifecycle: Every product starts in stage one. After its launch, the product moves into stage two, and eventually, it arrives in stage three. Understanding the Innovation Stages Stage 3: Maintaining a product means making small incremental updates to ensure that the product stays competitive and profit goals are met. The product management focus is typically on maximising the desired business benefits, for instance, minimise cost and maintain revenue. The innovation is low, and there is little uncertainty about what the product should look like and do, and how it is built. Experimentation and failure are hence not desirable. Planning the work and executing the plan works well. Most products in an established company fall into this category, and companies often optimise their processes and structures for this stage. Stage 2: One or more new features are created. This enhances an existing product, for instance, to increase the market share, or to enter a new market. Creating new features may require dealing with a new target group or addressing new needs, changing the user experience, or employing new technologies. Consequently, there is a significant amount of uncertainty present. Experimentation and failure are helpful to acquire the necessary knowledge and to develop the right features in the right way. Stage 1: A brand-new product aimed at a new or an existing market is created. Developing the product may involve addressing a new target group or new user needs, creating a new user experience, employing new technologies or a new business model. There are many more unknowns than knowns. The innovation present is high to very high. Rapid experimentation is a must, as it helps the team fail fast to succeed sooner: to create the right product for the right people. The stage-one products usually form the smallest group in a mature enterprise. Employing the Right Practices Distinguishing between the three innovation stages enables us to choose the right practices. These include the process and the project organisation employed, and the way product ownership is implemented. The table below summarises my observations. Innovation Stage Process Setup Stage 3: Maintenance Linear (Kanban-based) Distributed or collocated Stage 2: New Features Iterative, experimental (Scrum) Collocated Stage 1: New Product Iterative, experimental (Scrum or Lean Startup plus Kanban) Incubator As stage three aims to maximise the business benefits, for example, profit for a revenue-generating product, a linear process tends to work well – it facilitates efficiency. Employing a Kanban-based approach that leverages pull, collaboration, and visualisation is usually beneficial. Collocating team members may a plus but is often not mandatory. In stage two the focus shifts from efficiency to effectiveness: quickly resolving uncertainty by acquiring the relevant knowledge. This requires an iterative process that supports experimentation such as Scrum. A single product owner is beneficial to enable effective decision-making. The team members should be collocated, and product owner and team should collaborate on an ongoing basis. In stage one, effective experimentation becomes even more important. Scrum with short sprints, or Lean Startup combined with Kanban work well. The latter allows running experiments in varying lengths in parallel, but it tends to be more difficult to master. Product owner and team should form an incubator, a new, temporary organisation that is loosely coupled to the rest of the company. This provides the team with the freedom to try out new things and to literally think outside the box. Conclusion Choose your innovation practices to suit your needs: Your mature products are likely to benefit from practices that facilitate efficiency such as a linear process. To develop new features or a new product, you should select different practices, practices that help resolve uncertainty and acquire new knowledge. Applying an iterative, experimental process, and enabling collaboration will be... - Published: 2012-05-14 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/agile-product-roadmap/ - Categories: Product Roadmap - Tags: product life cycle, product owner This blog post discusses what an agile product roadmap is. It covers the information such a roadmap should contain, the benefits it provides, when it makes sense to employ a roadmap, how the product roadmap and the product backlog relate, and who should own the product roadmap. What is an Agile Product Roadmap? A product roadmap is a high-level plan that describes how the product is likely to grow. It allows you to express where you want to take your product, and why it's worthwhile investing in it.  An agile product roadmap also facilitates learning and change. A great way to achieve these objectives is to employ a goal-oriented roadmap - a roadmap based on goals rather than dominated by many features. Here is a sample agile product roadmap that shows the anticipated development of a dance game app for kids: The roadmap above states the date, the name, the goal, the key feature, and the metrics for each product version. It is a goal-oriented product roadmap, and it applies the GO roadmap template, which is explained in more detail in my post "The GO Product Roadmap". The benefit of a goal-oriented roadmap is that it shifts the conversation from arguing over features to agreeing on shared goals. This mitigates the conflict between viewing roadmap features as commitments and agile teams who only commit for next few weeks. What Benefits does a Product Roadmap Provide? A product roadmap can provide the following benefits: Provides a continuity of purpose and communicates how you see the product develop over the coming months. Facilitates stakeholder collaboration and helps the individuals understand how they can contribute to make the product a success. Helps with prioritisation; allows you to state if and when a benefit will be provided or a feature implemented. Unburdens the product backlog; you can focus the backlog on the next major release / product version, as I explain in more detail below. Helps acquire a budget by stating the benefits the product is likely to create. Supports portfolio management and makes it easier to coordinate related products. When should You Use a Product Roadmap? I usually create a product roadmap once I can confidently look beyond the next major release. If you cannot look further, then do not employ a roadmap! What's more, I want to ensure that the assumptions about the target group, the needs to be addressed, and key aspects of the business model have been validated, as the picture below illustrates: In the picture above, the market and business model assumptions are captured on a Product Vision Board. But you can also use the Business Model Canvas or Lean Canvas to state and validate your ideas.  While they are helpful tools, they not tell us how the strategy will be executed. This is where the product roadmap comes in. How do the Product Roadmap and the Product Backlog Relate? Using a product roadmap can benefit your product backlog . Here is why: As the roadmap takes care of the strategic product planning aspects, it frees the canvas/backlog to focus on the tactical work, as the picture below illustrates. Say you release a new product version every three months. I would then suggest that your product roadmap should capture the next four major releases, while your Product Canvas or product backlog focuses on creating the next product version. The following table summaries the differences between the product roadmap and the product backlog: Artefact Purpose Contents Horizon Updates Product Roadmap Strategic product planning Major releases with goals or benefits About 12 months At least once per quarter Product Backlog Product development Epics, user stories, and other artefacts About three months At least once per sprint Who Owns the Product Roadmap? As the product roadmap captures decisions about the product’s futures, the individual responsible for the product success should own the roadmap. In an agile context, the product owner should hence manage the product roadmap. The team members and stakeholders contribute, as the following picture suggests. Having one person in charge of the product roadmap and the product backlog unites the strategic and the tactical product planning aspects, and establishes clear authority and responsibility. This post was last updated on 13 February 2017. - Published: 2012-05-03 - Modified: 2022-08-16 - URL: https://www.romanpichler.com/blog/persona-template-for-agile-product-management/ - Categories: User Experience (UX) - Tags: product discovery, user model Personas are a great way to capture our knowledge about the users and customers and their needs. But writing effective personas and providing enough but not too much information can be challenging. This blog post introduce a simple yet powerful template that helps you write great personas. Personas in a Nutshell A persona is a fictional character that represents a subset of the market we want to address. A persona typically has a name, a picture, relevant characteristics such as age or income group, behavioural traits, common tasks, and a goal that describes the problem the persona wants to see solved or the benefit the character wants to achieve. This information is traditionally based on direct observation, interviews, and other qualitative market research. Personas should help you develop empathy for your users and customers. They encourage you to embrace a user-centred approach: Putting the users first, and building a product that that truly benefits them. This avoids the fallacy of a solution-centric approach: worrying more about the product and its features and technologies than the reason people would want to buy and use it in the first place. Alan Cooper pioneered personas in product development in the 1990ies. Today every product manager and product owner should be able to create and work with personas. A Minimalist Persona Template While personas are a powerful technique to capture knowledge about the users and customers of a product, it can be tricky to write effective personas: Some persona descriptions I have seen were too detailed and bloated; others lacked important information. That's particularly true when agile and lean practices are applied, and good enough persona descriptions are appropriate, which are updated and refined as more knowledge about the users and customers becomes available. Using personas for my own products, I have found that there are three pieces of information that are particularly valuable to creating effective personas: the persona’s picture and name, the persona's details, and the persona's goal. I therefore use the template below to write personas. Simply click in the picture to download the template as a PDF. The first two sections in the template above describe who the persona is. The last one is particularly important, as it makes us ask why the persona would want to purchase or use our product. An Example Here is an example of how the template can be applied. It features one of the personas of a new book I recently started to work on: Notice that I have tried to make the persona description as relevant as possible. I have left out information that is not essential to understand who the character is and why the person would want to read the book. For instance, I decided not to include Peter’s marital status. At the same time, I have tried to be as specific as I can right now about the persona, so I can validate my assumptions. As I find out more about the target readers of the book, I will undoubtedly iterate over Peter’s description, and update it. While refining your persona, ensure that the character is believable and that its description helps people empathise with the users. You can do this, for instance, by adding pictures, likes and dislikes to the characteristics. Visualising the Personas I prefer to capture personas on paper, so I can easily visualise them, for instance, by putting them on the Product Canvas, as the picture below illustrates. An A4 paper sheet usually works well. Another advantage of using paper-based personas is the limited space available. This helps us focus on the relevant information rather than writing everything down we believe to know about the user. - Published: 2012-04-02 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/the-product-backlog-refinement-steps/ - Categories: Product Backlog & User Stories - Tags: product owner, refinement, scrum, user feedback, waste Refining the product backlog helps you make the right product decisions and get the product backlog ready for the next sprint. In this post, I show how you successfully refine your product backlog in five steps. Step 1: Analyse the Data Refining the product backlog starts with analysing the feedback and data collected from exposing a product increment to target users and customers. The increment may be working software, or in the case of a brand-new product, a paper prototype. The data obtained may be quantitative, qualitative, or both depending on the validation technique used. I prefer to work with both, qualitative and quantitative data whenever possible and combine, for example, direct observation with A/B tests. When evaluating the feedback, focus on the data that is relevant to help you understand if you are building the right product with the right UX, features, and technologies, or how you can further enhance and optimise the product. Have the courage to say no to new ideas and requests if these are not helpful to meet the current product goal. Otherwise, your product is in danger of becoming a feature soup, a loose collection of features with little or no connection. Be aware of the cognitive biases we all have, your hidden assumptions and wishes, as these can lead to ignoring or misinterpreting data. Example biases are confirmation bias, the tendency to prefer data that confirms our preconceived ideas and views, and anchoring bias, the tendency to rely too much on the first piece of information obtained. To mitigate the risk, analyse the feedback together with the development team members. Finally, remember that negative feedback is good feedback: If all you ever hear is positive, you don't learning anything new and you miss opportunities for making your product even better. Step 2: Integrate the Learning Once you have analysed the feedback, draw the right conclusions and incorporate them into the product backlog. This usually results in removing, adjusting, and adding items, including epics, non-functional requirements, design and workflow sketches. But you might also find that the product goal you are pursuing is no longer valid or feasible within the time and budget constraints. If that's the case, you may have to adjust not only the product backlog but also the product roadmap, assuming that you use such a plan. Step 3: Decide what to do Next After incorporating the new insights into your backlog, decide what to do next and choose the right sprint goal. Ask yourself what needs to be done next and what the purpose of the next sprint is. Which ideas and assumptions do you want to validate, which risks do you need to address? Or which functionality do you want to provide or enhance?  You may want to try my sprint goal template to capture goal. Step 4: Refine the Backlog Items Next, break the larger items that help you to reach the sprint goal into smaller. For example, break epics into user stories. Then make them high-priority, and order the items according to their importance for reaching the sprint goal. You may also want to ask the development team to estimate any epics that have been added or adjusted as well as the newly formed stories. This allows you to understand how much effort is roughly contained in the backlog, to prioritise by cost-benefit, and track the development progress, for example, by using a release burndown chart. Step 5: Get the High-Priority Items Ready With small, ordered user stories in place, you are close to starting the next cycle. But before you do so, ensure that the stories are ready: clear, feasible, and testable. This may entail creating a user interface design sketch and one or more operational quality constraints for the stories, as the picture below illustrates. Getting the stories ready may also require resolving dependencies between teams if several teams work on the same product.  The stories should now be ready to be pulled onto the sprint backlog or the Kanban board. Product Backlog Refinement is Teamwork When I talk to Scrum product owners about refining their product backlogs, it's not uncommon for me to discover that the individuals carry out the work on their own. This wastes a massive opportunity: to mitigate the product owner’s cognitive biases, create shared ownership of the product backlog, and leverage the team’s collective creativity and knowledge. As the product owner, involve the team members in the refinement work. This reduces your workload, and it is likely to result in better requirements and a better product. Don’t be afraid, however, to facilitate the discussions and to make a decision if no consensus can be reached. You don’t want to get stuck in analysis-paralysis but move on, and test new ideas or deliver... - Published: 2012-03-20 - Modified: 2023-02-06 - URL: https://www.romanpichler.com/blog/agile-user-interface-design/ - Categories: User Experience (UX) - Tags: teamwork, user feedback, user interface design The role of design still puzzles many agile teams I work with. When should the design activities take place? Who should carry them out? How are design decisions best captured? This blog tries to answer the questions by discussing a user-centric, iterative, and collaborative design process for Scruma and Kanban teams. The Big Picture The image below depicts the design process I like to employ. It's user-centric, iterative, and collaborative. The process starts with capturing the design concept in form of a rough mock-up. Then the detailed design for one or more user stories is created and implemented as a throwaway prototype or as shippable software. The result is exposed to the users to understand if the design contributes to a great user experience. If it does, the design is refined, and the design for the next stories is created; if it does not, the design concept is reworked. High-level Design To get started, develop your design concept. The concept should sketch your key design ideas and communicate the essence of what you believe the product should look like. This includes the shapes and the colours you intend to use. Keep the overall product vision in mind together with the desired user experience: the kind of product being developed and the reason why people might want to use it. Focus on the critical aspects and don’t worry about the details right now. For instance, the high-level design below shows how the structure, shapes and colours of our new homepage together with a photo of a bald guy with a beard and sticky notes. Capture your design concept as a mock-up. Consider using a paper sketch similar to the one shown above. Paper sketches require less effort than wire-frames or other mock-ups; they are usually good enough to communicate the design idea. Make your sketch visible and put it on the product backlog board as shown below. You may also want to explore the anticipated interaction of a user with the product, and to capture it as an interaction diagram or workflow. Put the resulting artefact on the board’s model area. (You can find out more about the backlog board in my blog post "The Product Backlog Board". ) Detailed Design With your design concept in place, create the design for each user stories you want to implement. This is best done as part of the product backlog grooming work. Developing the detailed design should hence be a collaborative exercise that involves the developers and testers. This allows you to leverage the team’s collective creativity and to quickly discover which design options are difficult and expensive to implement. Sketch the user story-specific design on a paper card and attach it to the story card, as the image below illustrates. The design depicts the details of one of the boxes on the homepage: Then implement the design either as a throwaway prototype or as shippable software, and expose the result to the users. Note that paper prototypes are often sufficient to test your initial design ideas. Resist the temptation to create a perfect design straight away: An unpolished implementation tends to generate more valuable user feedback than a super slick design. Learning Leveraging the user feedback to validate your design ideas does not mean that you don’t require a vision of what the product should look like. The opposite is true. You have to innovate for your users and cannot expect to be told what the product should look like. Take the redesign of our website for example: Our customers, the organisations that pay for our training or consulting services, are important users of our website. Most of our customers are mid-sized to large enterprises. Having worked for large companies myself, I know that bigger organisations often prefer a more conservative look. But we wanted to create a website that that looks cool and that we like, not a boring corporate design. The challenge is hence to synthesise the wants and needs of the users and your own vision and ideas into a great design. Use the feedback to experiment and discover which design ideas don’t work and which do. Don't be a slave to the feedback, but don't cling to your ideas either. Analyse the feedback with an open mind and decide what to do: take it on board or discard it. Then either rework your design concept or adjust it, and create the detailed design for the next story. - Published: 2012-03-07 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/focus-on-the-user-not-the-product/ - Categories: Product Vision and Strategy, User Experience (UX) - Tags: product manager, product owner Getting lost in the product details and struggling to decide if a feature should be implemented is a common challenge for product owners. This post helps you focus on what really counts: creating value for the people using the product and the organisation developing it. Means to an End Some product owners I work with worry too much about how to write a certain user story or what the detailed design of a screen should look like. Whenever this happens, I find it helpful to step back and ask the following questions: Why would anybody want to use the functionality? Why would a certain design be helpful? Exploring how a story or design idea benefits the users means viewing the product as a means to an end: to serve the users as well as the organisation creating it. As marketing guru Theodore Levitt famously put it, “People don’t want a quarter-inch drill, they want a quarter-inch hole. ” What really matters are the benefits the product provides. While serving the user should be the primary purpose of your product, you shouldn't forget about the value the product has to create for your organisation. To do so, reflect on its business goals. A product typically generates revenue directly like Microsoft Office, indirectly by helping sell other products and services, think of the Amazon website and mobile app, or by saving cost, for example by automating business processes--many in-house built digital products fall in this category. Additionally, Consider the business model required in order to meet the business goals. This includes identifying the revenue streams, the sales channels, and the cost structure. Be aware that your business model can have an impact on the product functionality: For instance, if you plan to generate revenue through online ads, then this requires the capability to place ads. As a consequence, an ad epic will appear in your product backlog. The Extended Product Vision Board To capture your ideas about user needs, the product, and the value created for the company, you may want to try my Product Vision Board.  The extended version of the board shown below captures assumptions about the target group, the user needs, the top three features, and the key business model elements. If you find it difficult to balance meeting the user needs and creating value for your organisation, then focus on the user. If your product is desirable, you are likely to find a way to make money. Users should come first, money second. Next time when you get stuck in the product details, zoom out. Ask yourself how a feature adds value for the users and your organisation. Then implement it, gather the relevant data, and check if the benefit has been realised. - Published: 2012-02-08 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/the-single-product-owner/ - Categories: Product Roles - Tags: product owner, teamwork, user feedback If you grew up as a teenager in the 1980s like me, you are probably familiar with the quote “There can only be one” from the first Highlander movie. Interestingly, this statement is also true for product owners: There should only be one product owner per product. But don’t worry: You don’t have to become an immortal warrior to understand the Highlander principle. Reading this blog post will do the trick. Can there be many? Traditionally, product ownership tends to be distributed across several individuals: A product marketer, for instance, writes a product concept or market requirements specification, and a product manager turns it into a product requirements specification. A project manger is then tasked with executing the project, and works with a business analyst, requirements engineer, or architect to analyse and refine the requirements. While distributing product management responsibilities supports a linear, phase-and-gate-based process, it is not well suited for an agile environment characterised by rapid delivery and fast learning. Additionally, the handoffs between the different individuals can cause defects, delays, loss of information, and other waste; decision-making can be slow and may result in weak compromises; and if the product fails, a blaming game is likely to start. “There can only be one” The alternative is to put one person in charge of the product; the individual leads the product development and owns the product on behalf of the company. This integrates strategic and tactical product management aspects. It unites authority and responsibility, and speeds up decision-making. Meeting the user needs, creating a desirable user experience, and designing a sustainable business model receives the attention and leadership it requires. It increases the likelihood of realising the vision by delivering an attractive, well-rounded product. But just like Connor, the main character in the Highlander movies, needs friends and allies, so does the product owner. To mitigate the risk of a single product owner being overworked or making suboptimal decisions, the Highlander principle must be complemented by collaboration: Leveraging the ideas of users and customers by gathering feedback on working software; and using the knowledge and creativity of the development team by jointly grooming the product backlog. Immortals only? Working with a single product owner role can be particularly challenging on complex products or large projects. But you certainly don’t have to be an immortal to apply the role effectively.  On complex products or large projects, you have two options: You can either employ a product owner hierarchy with an overall product owner in charge of the entire product and feature and component owners responsible for features and components. The alternative I prefer is to break up complex, feature-rich products into several sub products, each owned by a single product owner. A benefit of working with a product suite is that the sub products can be developed and released largely independently. Additionally, scaling issues can be avoided or at least reduced. - Published: 2012-01-12 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/product-backlog-learning-tool/ - Categories: Product Backlog & User Stories - Tags: product discovery, risk, user feedback Leverage the power of customer feedback, and use your product backlog as a learning tool. Discover the right product features and take advantage of emerging requirements by integrating customer a feedback into the backlog early and frequently. Ideas and Requirements When I teach product owners, one of the questions I ask is: "What qualities should the product backlog fulfil? " More often than not, a key property is missed: emergence. This corresponds to my experience of how backlogs are often used: as a requirements list that doesn't change much.  Instead of being rigid and fixed, the product backlog should be flexible and dynamic. It should evolve based on customer and user feedback thereby facilitating the discovery of the right product feature. At the beginning of a product development project, there are usually many unknowns, and we often do not understand what a brand-new product or a new version should look like and do in detail. Our initial thoughts about the product resemble more ideas than hard-and-fast requirements.  We should therefore treat the items of an initial product backlog as assumptions that have to be validated and refined using the feedback from customers and users. This allows us to understand how we can best solve the customers’ problem, and what the product should really look like and do. Learning from Customer Feedback To turn your backlog into a learning tool, expose product increments early and regularly to customers and users, for instance by demoing the increment or by releasing it. Then evaluate the feedback you receive, and decide which changes are required, as the following diagram illustrates: When evaluating feedback, avoid two common mistakes: clinging on to your ideas and ignoring what your customers and users tell you, and saying yes to every piece of feedback, any new idea, or feature request. Analyse the feedback carefully with your vision and product strategy in mind. Ask yourself if the feedback is helpful turn the vision into a great product–assuming that your product strategy is valid. If the answer is yes, incorporate the insights gained. Remove or change existing product backlog items, and add new ones. Your product will consequently evolve through on-going dialogue with users and customers. Enabling Change Adjusting a large, detailed product backlog usually takes too much time and is error-prone. Focussing your backlog and keeping the majority of its items coarse-grained helps you achieve the necessary conciseness. If you are developing a brand new product, you may want to restrict the backlog scope to creating a first product increment that allows you to gather customer feedback (aka minimal viable product or MVP). Then use the feedback to decide if and how to proceed. Use the product roadmap to paint a bigger picture of how the product is likely to evolve. Keep the majority of your backlog items sketchy and coarse-grained, particularly as long as your product is changing. A great way to do this is to employ my Product Canvas and to capture ideas as epics and user journeys. Identify the biggest risks, and select the epics and journeys you want to test with the next product increment. Then derive small stories and make them high priority. Viewing the product backlog as a learning tool facilitates the development of successful products. But it requires overcoming the misconception that the requirements can be correctly determined upfront when we develop a new product or make bigger changes to an existing one. We stand a better chance of success by using early and frequent feedback from users and customers to validate our ideas and make the right product decisions. As Ken Blanchard says: “Feedback is the breakfast of champions. ” - Published: 2011-12-15 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/scrum-startup/ - Categories: Product Management Process - Tags: product owner, scrum, startup, teamwork, user feedback The blog posts explains how to setting up a Scrum team as an incubator in an established enterprise helps create a new product, and to pilot an agile way of working. With the term startup we usually associate starting a new company and pursuing a new idea with a small, creative team. While Scrum has been used for many years in startup companies – companies with a limited operating history – I have found that setting up a Scrum team as a “startup” or incubator within an established enterprise is a powerful approach to create a new product, and to pilot a new way of working. A Scrum Startup consists of the product owner, the ScrumMaster and the development team. Together, they form is a self-contained unit that is loosely coupled to the rest of the organisation and in charge of developing and releasing the product. The product owner acts as an intrapreneur, an entrepreneur within the larger organisation. An Enterprise Scrum Startup The first Scrum project I helped run in 2004 had ambitious plans: It was tasked with creating a new enterprise telecommunications software product. The company had high hopes for the product: It was considered vital to the business group’s future. To create an environment that encouraged innovation and creativity, we opened up a new development site, and assembled a new team. We also made sure that the product owner was able to act as an intrapreneur and received the backing from senior management. The individual had a vision for the new product and a budget to turn the vision into reality. The Scrum Startup controlled the product under development including the development and test environment, and it experienced few changes to the team composition. The individuals had a personal stake in the outcome: Everybody desperately wanted the new product to succeed knowing that it would shape future of the group. We didn’t quite realise it, but we had created a startup within a well-established, large enterprise: Siemens, a company which has more than 420 000 employees and which is over one hundred years old. The resulting product became part of OpenScape Unified Communications. It has won a number of awards, and is still selling well. Autonomy Setting up a Scrum team as an incubator is so powerful as it disentangles the team tasked with innovating from the rest of the organisation. Think of a Scrum Startup as a new house in the enterprise village, or a new tree in the corporate garden. The members of the Siemens telecommunications project were free to literally think outside the box, to try out new things, and to be creative. Most importantly, it created a safe environment for experimentation: for testing new ideas and for failing. Our first minimal viable product (MVP), the product increment of the second sprint, turned out to be a failure: We had chosen the wrong component technology, and the product did not live up to the users’ performance expectations. Our first process experiment ended in failure too: We had started using a heavily tailored, lightweight version of the Rational Unified Process (RUP) that included development practices from Extreme Programming. After a few iterations, we decided to switch to Scrum. The RUP iteration management and collaboration practices simply did not work for us. Without those early failures and the learning that they enabled, we probably would have not been able to deliver a successful product. Collaboration As important as autonomy is, it needs to be balanced with collaboration: working together within the Scrum Startup and with the stakeholders. A healthy, trustful relationship between the product owner and the team, the product owner and the ScrumMaster, and the ScrumMaster and the team is a prerequisite for applying Scrum successfully and for creating a great product. But it’s no less important to invite internal stakeholders to participate in the development process, and to use the feedback from target customers and users to create a product with the right features for the right people. When we created the telco product, we invited representatives from marketing, sales and service to the sprint review meetings, and we demoed MVPs to other development groups destined to build on the product. Releasing early product increments to employees in other parts of the enterprise is another great way to benefit from the ideas of the rest of the organisation, and to keep people informed about the progress. Exposing product increments early and frequently to target customers and users in form of demos or releases helps to achieve a great product market fit. Scrum Startup Qualities To help your enterprise Scrum Startup succeed, make sure it fulfils the following four properties: It should be loosely-coupled to the enterprise... - Published: 2011-11-07 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/the-vision-the-product-backlog-and-the-minimal-viable-product/ - Categories: Product Management Process, Product Vision and Strategy - Tags: scrum, startup Learn how the product vision, the product backlog, and the concept of a minimal viable product (MVP) can be combined to facilitate successful innovation. I find the Lean Startup concept of a minimum viable product (MVP) rather exciting: It entails creating a first product version to test our ideas as quickly and cheaply as possible. This could be a throwaway prototype such as a mock-up or a product increment, working software that is tested and documented. The MVP works together with a build-measure-learn cycle: developing software, gathering customer feedback, and learning from it. With roots in the Scrum tradition, this sounds rather familiar to me: Validating assumptions by gathering customer feedback using product increments is called empirical management or inspect-and-adapt in Scrum. But Scrum advocates the use of a product backlog containing the outstanding work necessary to create a successful product. How does the backlog fit into the picture? And can the product backlog be helpful to create a minimal viable product? This blog posts answers this question and investigates how Lean Startup and Scrum concepts can be combined successfully. The Product Vision “If I had asked people what they wanted, they would have said faster horses,” said Henry Ford famously. A vision, an idea of the future product, is the start of any successful innovation. Without a vision, we lack a shared goal, a common direction. To reach our goal, we have to decide on an approach or strategy. This includes making assumptions about the target group, the needs the product should address, the key product features, and the value it should create for the organisation developing. I use my Vision Board to capture and visualise the product strategy. The strategy's assumptions must be validated. A great way to do this is to create the minimal viable product and to release it to the target customers and users. The Product Backlog Unfortunately, the product strategy is often too coarse-grained and partial to be used as a direct input for writing software. It can therefore be helpful to take an intermediate step, and to identify the work that is required to validate the strategy. The corresponding items are placed in a sketchy, lightweight product backlog. To put it differently, the backlog is derived from the product strategy; it makes the strategy implementable. From Backlog to Minimum Viable Product Once we have a strategy and initial product backlog available, we create the minimum amount of functionality necessary to test our assumptions. This may take a day or two, or one or more sprints with a preference for the shorter timescales. Our goal is to find out quickly if the product generates a positive response amongst the target users and customers, and if the target group members use the product in the intended way. Once we've created the MVP, we release it and gather the relevant data. Note that releasing the MVP can be limited to a small group of users if the respondents are representative for the target group. Google, for instance, released early versions of its Chrome browser internally and asked its employees to test the software and to provide feedback before a first public beta was released in October 2008. A counter example is Google Buzz: The software was apparently loved by Google engineers, but unfortunately not by the rest of the world. Pivot or Persevere? Once we’ve gathered and evaluated the feedback, we need to decide if and how to act upon it.  If the feedback invalidates any assumptions in the product strategy - which is likely to be the case when a new product is developed - we should adjust it together with the product backlog. Making changes to the strategy is also called pivot. We may decide to change the target group or the needs selected, for instance; maybe the features or the look and feel envisioned is not right; or the business model does not work as expected, for instance, users never click on the ads displayed. Changing the product strategy can require restocking the backlog. With the backlog updated, we continue with the next cycle, develop a new MVP, and gather new feedback. If the data confirms our strategy, we preserve and adapt the product backlog by incorporating the insights gained. Depending on the quality of the MVP, we may have to throw away any mock-ups and prototypes created so far, and start afresh developing tested and documented software using agile development practices. If the MVP is a product increment, we can progressively transform it into a shippable product using a series of sprints. Summary Using a minimum viable product is a powerful concept to validate the product backlog that be... - Published: 2011-10-25 - Modified: 2023-02-20 - URL: https://www.romanpichler.com/blog/two-common-ways-to-apply-the-product-owner-role/ - Categories: Product Roles - Tags: product manager, product owner Applying the product owner role can be challenging, as no two products are the same. While products and projects vary, I have found two common ways to employ the role: Asking the customer or a customer proxy such as a product manager to take on the product owner role. This post discusses when which option is more appropriate. Option One: The Customer Plays the Product Owner Role One way to apply the product owner role is to ask the customer to play the role. This option is particularly useful for the development of bespoke (custom) software. For instance, if a web application is developed for a company’s marketing group – either by an in-house team or by an external software provider–a member of the marketing group should take on the product owner role. For example, I play the product owner role for my company's website, which is developed by an agency based in the south of the UK. This approach is illustrated by the following picture1: Advantages: The customer steers and controls the development of the software directly. This allows the customer to own the product, speeds up decision-making, and increases the likelihood of creating a product that serves the customer needs. I personally love being the product owner of romanpichler. com. Challenges: The customer must be available, qualified, and empowered to create a successful product. The customer and the team must value transparency and develop a healthy, trustful relationship. The latter tends to be particularly challenging when the customer and the team have different interests, for instance, getting the essential features shipped as soon as possible vs. maximising revenue, or if they have had difficulties to collaborate in the past ("IT never delivers"). Option Two: A Product Professional Fills the Product Owner Role Alternatively, we can decide to separate the customer and the product owner role. This option is applicable when software is developed for several customers, for instance, when a commercial software product is created or when different departments of the same company use software developed in-house. In both scenarios, the product owner acts as a customer proxy who discovers the needs of the customers and users, and who listens to their ideas and requirements.  But the product owner decides if and when a feature is released. The following picture illustrates this option: For commercial software, a product managers typically takes on the product owner role. For software developed in-house, a project manager or business analyst may play the role.  Note that picture above illustrates the main communication paths. Team members talk to customers and users directly of course, for instance, in the sprint review meeting when discussing improvements to the product. (But ultimately the product owner decides which improvements are implemented. ) Advantages: Separating the customer and the product owner role helps create a product that addresses the needs of the entire target group. It also provides the opportunity to employ professional full-time product owners with the right skills: Product managers, project managers, and business analysts can focus on playing the role effectively. Challenges: Empowerment of the product owner can be difficult to achieve. Product owners often require the trust and support of senior management to be able to make the necessary decisions, to have the clout to say no, and to create stakeholder alignment. Companies that regard IT largely as a commodity can find it difficult to value product ownership and to invest in developing product owners. (See my article Five Tips for "Introducing Product Management to Your Company" for more information. ) - Published: 2011-08-31 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/the-minimal-marketable-product/ - Categories: Product Vision and Strategy - Tags: product discovery, risk, simplicity, startup, user feedback Innovate successfully by creating a minimal marketable product, a product with just the right features. This allows you to launch quicker, reduce time-to-market, and start earning money sooner. To create a new product, we have to peek into the future and anticipate what the product will roughly look like and do. For anyone not blessed with perfect foresight, predicting the future correctly is notoriously difficult. After all, the only thing certain about the future is that it is uncertain! Investing in a new product hence always involves risk. We may have targeted the wrong market segment, envisioned the wrong product or the wrong features, or the market may have changed by the time the product is launched. Envisioning a Lean, Minimal Product A great strategy to minimise the investment risk is to envision a lean, minimal product with the smallest possible feature set. I refer to such a product as the minimal marketable product. It contains just enough functionality to be viable – to launch, market and sell the product successfully. Developing a minimal product is quicker and cheaper than a more ambitious, feature-rich one. If the product bombs less time and money is lost. If it is a success, the product starts earning money sooner. Additionally, a minimal product allows us to receive feedback earlier so we adapt the product quicker to the market response. Rather than trying to create the perfect product, we follow the motto “get it out, then get it right. ” Note that the product’s quality must be right from the start. Otherwise it will be difficult to adapt the product; bugs may hinder its adoption, or even damage the brand. The iPhone An example of a minimal marketable product is the original iPhone, which launched in 2007. One of the secrets behind its success is the narrow set of customer needs Apple selected. The company avoided the trap of trying to please too many people at once, of trying to copy all the features competitors offered. Instead, Apple took a fresh look at what smartphones should look like and do, and deliberately left out some functionality. The original iPhone shipped without many features standard on existing phones: copy and paste, the ability to send text messages to multiple recipients, and a software development kit, for instance. These limitations, though, did not hinder its success. Paring down the functionality allowed Apple to develop and ship the product within a competitive timeframe and gave the company a significant lead over its competitors. Building on the success of the first iPhone version, Apple started to extend the capabilities of the phone both in terms of hardware and software with the launch of the 3G model in 2008. This version also allowed the company to enter a new market segment by targeting business users. The Apple Newton Developing a minimal marketable product may sound like a no-brainer. But my experience suggests that many start-ups and established companies alike find it hard to restrict the features of a new product. It’s often too tempting to opt for a big-bang release trying to satisfy as many users and customers at once in order to maximise revenue. Contrast the iPhone with another Apple product: the Apple Newton, first launched in 1993 after five long years of development. Remember those Apple ads that promised a PDA that could do all sorts of wonderful things, including recognising your handwriting? When it was finally shipped, the Newton proved to be too bulky and heavy. Worse, its most important feature, the handwriting recognition, did not work properly. The product underperformed and was finally withdrawn from the market in 1998. In hindsight, Apple was overly ambitious with its Newton plans. The company launched a product that tried to do too much at once, and failed. The Steps towards a Minimal Marketable Product To create a lean, minimal product, limit the target group and “build a product for the few, not the many,” as Steve Blank recommends in his book The Four Steps to the Epiphany. For instance, if you use personas to describe members of your target group, consider the impact of removing a persona. Would the product still sell? If yes, reduce the target group by dropping the persona. Once you have done a great job for your early customers, you’re in a position to build on the initial success with a new, incremental release that attracts new customers. Second, understand your product’s value proposition and only select the features that are essential to address the needs of the target group. Have the courage and discipline to discard all others for now. Selecting the minimal set of features does not mean creating a... - Published: 2011-07-08 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/release-planning-workshop/ - Categories: Product Roadmap - Tags: product owner Determining the release date and budget before development starts can be tricky particularly for new or young products where the product backlog contents are not known upfront. This blog post discusses the use of a measurable release goal and collaborative workshop to determine the launch date and the budget before the first sprint starts. Bring the Right People Together Employing a traditional planning approach and trying to capture all requirements in detail upfront in the product backlog is not only error-prone when dealing with innovative products. It is also undesirable in an agile context where the product’s detailed functionality is discovered during the development through early and frequent user feedback. Does this mean that we cannot make an informed investment decision at an early point in time on an agile project? Luckily, the answer is no. A collaborative workshop involving the right people is a great way to carry out the initial release planning: The product owner, the ScrumMaster, the development team, and key stakeholders should attend the workshop. An initial product backlog must be available before the workshop starts. Agree on the Release Goal Choose the a release goal, the reason why it is worthwhile to work on the product for the next two to six months and create a new product version or major release. Sample release goals are acquire more or new customers, increase revenue, reduce cost, increase engagement, reduce technical debt. If you work with a goal-oriented product roadmap, then the plan should provide you with the goal. Make sure that the release goal is specific and measurable so that you will be able to determine if it met or not. Additionally, everyone present should understand and agree with the goal. Identify the Window of Opportunity Next determine the window of opportunity, the timeframe in which the new or updated product must be released to meet the release goal and create the desired benefits. If the date is missed, the opportunity may be gone, and releasing the product no longer makes sense. If the release goal cannot be met in the desired timeframe, try making the goal less ambitious or explore if adding more people to the release would be feasible and beneficial. This may require you to adjust your product backlog and remove or change some of its items. Determine the Budget With the release goal and date in place, determine the budget. To do so, ask which skills are needed and how many people may be required. Then consider additional items such as licensees for tools and third-party software. This provides you with an initial budget. If the budget is too high, consider acquiring more money or weakening the release goal. Make a Go/No-go Decision Having a release goal, date, and budget available should allow you to make or recommend a go/no-go decision. Making the decision in the workshop does not only create transparency and leverage the input of the attendees; it also avoids waiting and delays and helps reduce time-to-market. Track the Development Progress Once development is underway, capture the progress using a release burndown chart, as shown in the picture below. The chart tracks the remaining effort in the product backlog at the end of each sprint. This is the burndown line. By seeing a trend emerge across the sprint, you are able to forecast the likely development for the rest of the release. Working with a release burndown chart validates the original plan, and it allows you as the product owner to steer the release and trade off time, budget and functionality. Note that quality is frozen in an agile context and should not be compromised: Quality compromises result in defective product increments, making it impossible to clearly see the progress and to release software early and frequently. - Published: 2011-06-22 - Modified: 2024-09-30 - URL: https://www.romanpichler.com/blog/user-story-modelling/ - Categories: Product Backlog & User Stories - Tags: epic, product definition, product owner, requirements, simplicity, teamwork, user story User stories are great at capturing product functionality in isolation. But they are not well suited to describe the relationship between different features and capture user journeys and workflows. This blog posts shows how context and activity diagrams can be successfully used to model interactions in user story context. Context Diagram with Epics A context diagram that depicts user roles and epics, large and coarse-grained stories, is great to provide an overview of the product’s functionality. Let’s have a look at an example, a diagram that sketches an online application store called “Application Centre”: The diagram above depicts three user roles: provider, user and administrator. It shows how the roles interact with epics that describe Application Centre functionality. It tells us, for instance, that the user and the administrator both review applications – to enable end user and staff ratings. Note that the diagram does not list all epics contained in the product backlog, and it does not state all user roles. It rather focuses on the product backlog items relevant for a conversation between the product owner and the team, or the Scrum team and the stakeholders. This results in a diagram that is simple and easy to understand rather than complex and overwhelming. Activity Diagram with Stories To get a job done, users often carry out several steps and interact with different pieces of functionality. Activity diagrams are great at capturing sequences and workflows by connecting individual user stories. They also support the creation of complex test scenarios that go beyond a single story. Let’s have a look at an example, a diagram that elaborates the epic “Register” on the context diagram above. It shows the key steps required for a user to register with the Application Centre: The diagram above visualises the steps of the registration workflow by connecting three individual stories. It starts with stating the details of the provider company, continues with entering a user name and password, and if successful, accepting the usage terms and conditions. User Story Modelling Tips User stories modelling is a handy tool in the product owner’s toolbox. But like any tool, it wants to be applied properly. The following tips help you create great diagrams: Model collaboratively: User story modelling serves to create a shared understanding of the desired product functionality. Use context and activity diagrams to capture the essence of a conversation, not to replace it! Create and update your diagrams collaboratively involving the team and as appropriate, the stakeholders. Focus: Apply modelling selectively and only describe relevant aspects. Focus on the relevant product backlog items and leave out the rest. Don’t include too much information or unnecessary details. Keep it simple: Keep your diagrams simple and easy to understand. Rather use additional diagrams to illustrate further aspects than cluttering a model with too much information. Complex diagrams are usually not helpful. Use whiteboards and flip charts rather than electronic tools. Simple, physical tools encourage participation and collaboration. They avoid the impression of perfection and completion. Summary Collaborative user story modelling can help you create a shared understanding of the desired product functionality. Context and activity diagrams complement user stories, put them in a context and connect individual epics and stories. Any model related to user stories should be the outcome of a conversation–and never replace it. - Published: 2011-05-10 - Modified: 2025-10-13 - URL: https://www.romanpichler.com/blog/the-product-vision-board/ - Categories: Product Vision and Strategy - Tags: product discovery, product owner, startup, user interface design The vision plays an important role in bringing a new product to life: It acts as the overarching goal guiding everyone involved in the development effort. Equally important is the product strategy, the path chosen to attain the vision. Without a shared vision and an effective strategy, people are likely to pull in different directions, and the chances of creating a successful product are slim. While vision and strategy are key, describing them can be challenging. This post introduces the Product Vision Board, a tool that helps you capture the vision and product strategy. A Sample Vision Board Towards the end of 2012, I was exploring the idea of creating a software-based version of my product canvas tool that integrates seamlessly with other tools like JIRA and GreenHopper. To get started, I created an initial product vision board, which is shown below. The Product Vision Board above captures my assumptions about the users and the customers of the new tool, the needs the product should address, the key product features, and the value the product should create for my business. (I explain the sections of the board in more detail below. ) As you may have noticed, I have kept the information on the board concise. I did not, for instance, write personas and user stories, or create a design sketch. There are two reasons for this: First, I did not know enough about the users and customers at the outset to write personas and to describe the product in more detail. Second, I find that the product details are best captured in the product backlog. The board was very valuable: It helped me think through my idea, and it allowed me to share my thoughts with my team and with our development partner. Additionally, the product vision board helped me investigate the greatest risks by testing my assumptions, as I explain below. I now use the board for any new idea, be it writing a new book, creating a new brochure, or updating a training course, and I help my clients apply the board. The Vision Board Explained The product vision board is the simplest thing that could possibly work to capture the vision and strategy of a product. It uses five sections as shown in the following diagram and explained below. You can download the template together with a handy checklist from the tools section of my website. Vision states your overarching goal, the ultimate reason for creating the product, and the positive change you want to bring about. Make your vision big and inspiring; use a brief statement or slogan; and ensure that the stakeholders and development team(s) support it, that it is shared. For more vision tips, please see my article 8 Tips for Creating A Compelling Product Vision. Target Group describes the market or market segment you want to address. You should state who the product is likely to benefit, who its users and its customers are. Choose a homogenous, clear-cut target group, especially when creating a new product. Needs describe the product's value proposition: the main problem the product addresses or the primary benefit it offers. The section should make it clear why people will want to use the product or pay for it. Capture what success looks like for the users and customers. If you identify several needs, prioritise them. Product summarises the three to five features that make your product stand out and that are critical for its success. These are likely to correlate to its unique selling proposition, and they should address the needs identified. Don’t make the mistake of listing lots of features. Stick to a maximum of five. Capture the product details at a later stage in your product backlog. Business Goals, finally, explain why it’s worthwhile for your company to invest in the product. It states the desired business benefits, for instance, increase revenue, enter a new market, reduce cost, develop the brand, or acquire valuable knowledge. The latter can be just as valuable as the former: When Toyota shipped the Prius in 1997, for instance, the car was not earning any money. But it immediately developed its brand (“green car company”), and had gained an advantage in hybrid technology. Prioritise the business goals to create focus and state targets. Otherwise, it's hard to measure the product performance and apply the right key performance indicators (KPIs). There are, of course, other helpful tools available that help you capture your ideas, including Ash Maurya's Lean Canvas and Alexander Osterwalder's business model canvas. I may be biased, but I like the simplicity of the Product Vision Board: I find it beneficial to consider the target group, needs, key features and business goals when exploring an idea before thinking about monetisation and the business model. You can learn more about the Product Vision Board by watching the video below. https://youtu. be/rtbWVxYEgNA Research and Validation with the Product Vision Board The Product Vision Board is not only a thinking and communications tool, but it also allows you to test your assumptions and capture newly gained insights.... - Published: 2011-04-01 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/choosing-the-right-agile-pilot-project/ - Categories: Product Management Process - Tags: risk, scaling, scrum “Which project is best suited to pilot Agile?” is a question I get regularly asked. This blog post discusses the following six criteria that help you select the right agile pilot project: small, important, independent, collocated, software only, and new product development. While I'd like to encourage you to carefully consider the specific situation and the the organisational context you are in, I find the following six criteria helpful to select a suitable agile pilot project: Small: Your pilot project should be small and consist of no more than two to three teams. Large-scale agile development introduces additional challenges and requires further practices. If you must scale, start with one or two teams and slowly add more teams by splitting the existing teams and adding new members. Important: Make sure that your pilot is relevant to the organisation. Otherwise skeptics might dismiss it as a “pet project” and undermine the buy-in for the new approach. But avoid mission-critical projects – development efforts whose success severely impacts the organisation. Agile software development is a disruptive process innovation for most organisations. It requires the ability to experiment, to make mistakes, and to learn from them. Independent: Choose a project that has few dependencies on other teams. Having to coordinate with other projects or different groups adds a level of complexity and makes the disciplined application of agile practices difficult – particularly if the other projects follow a different process. If all you have to choose from is a large, complex project then look for a subproject with few dependencies to pilot your agile approach. Collocated: Start with a collocated agile project and avoid distributed development efforts, if possible, as these make effective collaboration more difficult and require additional practices and tools. Jointly writing user stories, pair programming, and having effective sprint review meetings become much more challenging, for instance. Software only: Limit your agile pilot to software development. This reduces the added complexity that arises when other disciplines such as hardware and mechanics are involved. Agile software development practices are also well understood. That’s true to a much lesser extent for hardware and mechanical engineering. New product development: Select a new product development project rather than updating an existing product if you want to try out Scrum. This allows you to explore how an idea is best transformed into a shippable product using agile practices. It frees you from worrying about a legacy code base that may be difficult to understand and lack the necessary tests. What's more, Scrum is particularly well suited to cope with the flux, uncertainty, innovation, and risk that are characteristic of new product development. Before you now select your pilot project or decide to delay experimenting with agile practices, consider the following advice: Know your goal: Understand why you want to try out a certain agile approach and what benefits you expect – even if it’s just to see what all the hype is about. Just do it: While it is helpful to look for the right pilot, nothing beats applying agile practices – even if you can only use selected techniques within your established process. “What I hear, I forget. What I see, I remember. What I do, I understand. “ ~ Confucius ~ - Published: 2011-03-07 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/product-backlog-board/ - Categories: Product Backlog & User Stories - Tags: requirements, risk, user interface design Are you struggling with your product backlog? Then try my Product Backlog Board, a structured hierarchical product backlog that helps make sure you have ready items, capture non-functional requirements, and integrate your requirement models. Please note that the product backlog board has been superseded by the Product Canvas, a new type of backlog designed for creating new products and for product updates aimed at new markets. It extends the backlog board and connects personas with the product features. Please see my post "The Product Canvas" for more information. A Multidimensional, Nonlinear Product Backlog Most product backlogs I have come across either contain too much or too little information, ranging from literally a handful of user stories to many hundred items. Many backlogs don’t consider non-functional requirements and do not provide high priority items that are “ready” – clear, testable and feasible. How come product owners and teams struggle to use the product backlog effectively?  One of the reasons lies in the linear nature of a traditional product backlog: It is a list of “features, functions, technologies, enhancements, and bug fixes,” as Schwaber and Beedle (2002) write. Such a list can work well for updating an existing product. But it is often insufficient for developing a new product. I have therefore started to work with a multidimensional and nonlinear product backlog, which I call “Product Backlog Board. ” Here is a sample product backlog board: The product backlog board depicted above provides the following elements: A prioritised story area with a ready section and a section containing themes with their epics. A constraint area with the global operational qualities and the critical product design and user interface requirements. An optional model area that contains requirement models. I am not the first person to recognise that flat product backlogs can be inappropriate; Jeff Patton did so a few years ago when he developed his story maps, for instance. You could even use a story map within your product backlog board if you wanted. The Story Area The story area is divided into two sections: items that are likely to be worked on in the next sprint, and the other outstanding work that is essential to create a successful product. The items in the ready section must be clear, feasible and testable. They are preferably captured as small and detailed user stories with well-written acceptance criteria.  The epics, however, are coarse-grained and sketchy. They are placeholders for future detailed stories which are progressively derived from them. Epics are grouped into themes with each theme representing a product capability. The stories in the ready section must be strictly prioritised, from one to n, to focus the work of the team. You don't have to order the themes and epics unless you want to indicate when functionality will be released, for instance, in form of an early product increment (beta). But don’t forget to review the epics on a regular basis, and consider risk and uncertainty as well as dependencies. This will help you to decide how to stock the ready section and to determine which stories have to be carved out of your epics. The Constraint Area This area contains the global non-functional requirements of the product – operational qualities as well as product design and user interface ideas that apply to the entire product. It’s important to recognise and address these constraints: They influence the user experience, drive architecture and the technology decisions, impact the total cost of ownership and the product’s life expectancy. I prefer to capture operational qualities using constraint cards. The critical aspects of product and user interface design are best described visually as sketches or screenshots of mockups and prototypes.  Note that the items in the constraint area are not estimated. Instead, the definition of done states that all constraints must be fulfilled.  (I discuss design in more detail in my post on Agile User Interface Design. ) The Model Area Workflows and models don’t fit into a linear, flat product backlog. Consequently, many Scrum teams ignore them. While requirements modelling should be applied lightly in an agile context, teams often benefit from connecting individual stories and epics, for instance, by showing how the user roles interact with the epics. The same is true for workflows: It’s often helpful to look at a user story sequence to understand how a user interacts with the product and to explore the resulting user experience. If requirement models and workflows are helpful to develop your product, then add a model area to the product backlog board.  Like the constraint items, the models and workflows are not estimated. But they are also not included in the definition of done, as they simply elaborate stories and epics. (I describe user story sequences and... - Published: 2010-12-16 - Modified: 2024-02-02 - URL: https://www.romanpichler.com/blog/the-definition-of-ready/ - Categories: Product Backlog & User Stories - Tags: product owner, scrum, teamwork, user story “Ready are you? What know you of ready?” says Yoda to Luke Skywalker in the Star Wars movie “The Empire Strikes Back.” Just as it’s important for Luke to understand what “ready” means, so is it for product owners. Luckily, you don’t have to become a Jedi to find out. Reading this post will do. Why Ready Matters A few years back I was asked to help a team that has trouble meeting commitments. After taking a look at the product backlog, it became clear why the dev team had trouble making realistic, achievable commitments: Most of the high-priority items were big, coarse grained stories. None of them was sufficiently refined; none of them was ready. The idea that the high-priority product backlog items should be “ready” or “workable” dates back to the first Scrum book published in 2002. Ready items can be pulled into the sprint by the team and quickly turned into a product increment, as the following image illustrates. If the user stories that are likely to be worked on in the next sprint aren't ready, then the team will struggle to make a realistic commitment or forecast in the sprint planning meeting and fully meet the sprint goal. It is therefore important to ensure that there are enough ready items on the product backlog before a sprint starts. Remember: A sprint is a function that takes high-priority items and turns them into a product increment. If you don’t pay attention to what goes into a sprint, it’s garbage in, garbage out. And garbage, as we know from the first Star Wars movie, is not a good place to be stuck in. What Ready Means A “ready” item should be clear, feasible and testable, as I suggest in my book Agile Product Management with Scrum. A story is clear if all Scrum team members have a shared understanding of what it means. Collaboratively writing user stories, and adding acceptance criteria to the high-priority ones facilitates clarity. Bear in mind that development teams that are new to the product or market/domain typically have a need for clearer, more detailed stories. As the team member's knowledge increases, stories can often become less detailed. An item is testable if there is an effective way to determine if the functionality works as expected. Acceptance criteria ensure that each story can be tested. As a rule of thumb, I like to employ three to five acceptance criteria per user story. A story is feasible if it can be completed in one sprint, according to the definition of done. This implies two things: The item must be small enough, and it must not be too complex. I prefer to work with stories that can be implemented and tested within a few days, as this allows the product owner to provide feedback on the software during the sprint. What a Ready Story Looks Like A ready story is a detailed user story with a narrative and acceptance criteria. It should also be clear if there are any story-specific operational qualities such as performance, and what the user interface design roughly looks like. You can simply capture the qualities on constraint cards, and the design on a piece of paper. The artefacts are then attached to the story, as the picture below illustrates: How Ready Is Best Achieved The best way to ensure that the high-priority product backlog items are ready is to work on the backlog together with the development team. This tends to naturally lead to workable stories. What's more, it leverages the creativity of the team members, creates a shared understanding, and reduces the amount of story-related questions during a sprint. You might find that over time, you don't need a definition of done any more, as everybody understands what it takes to have ready product backlog items available at sprint planning, and all development team members contribute to discovering and refining user stories. - Published: 2010-11-11 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/how-to-ensure-product-failure/ - Categories: Product Vision and Strategy - Tags: product owner, requirements, Scrum Master, user feedback This blog post provides a tongue-in-cheek collection of common product creation mistakes. Combined they are a recipe for certain failure and provide a lesson in how not to develop products. Sadly, they are not made-up but based on my experience working with different companies and teams. I hope that listing the mistakes helps you avoid them thereby increasing your chances of developing a successful product. 1. Apply the product owner role pragmatically: Spilt the role across several people or work with a product owner committee. 2. Shoot for the maximum marketable product–a product that pleases everyone and has a myriad of features. 3. Have a can-do attitude, say yes to every requirement, and add it to the product backlog. You surely want to avoid disappointing any stakeholders. 4. Capture and detail all the requirements in the product backlog prior to the first sprint. This reduces uncertainty and risk, and it enables accurate planning and efficient execution. 5. Don't bother with prioritisation. All requirements are certainly must-have's. 6. Don’t waste your time collecting user feedback on early product increments and MVPs. You know what’s best for them! 7. Opt for a big-bang release to surprise your competitors, impress your customers, and achieve complete market domination instantly. 8. When push comes to shove, add more features and cut quality. Users love complex products. Don't worry about technical debt. View it as an opportunity to create a brand-new product in the near future. 9. Tell the ScrumMaster to act as a proper project manager. Work the team hard, and assign tasks to people. Sustainable pace is for wimps. 10. Be a true leader: make sure you get all the praise, and blame others when things aren't going well. - Published: 2010-11-01 - Modified: 2023-01-13 - URL: https://www.romanpichler.com/blog/one-page-product-owner/ - Categories: Product Roles - Tags: empowerment, product owner, scrum, stakeholders, teamwork The product owner is a product management role that emerged in Scrum in the late 1990ies. But many organisations still struggle to effectively apply it. In this article, I offer an overview of the role including its authority and responsibility. Authority and Responsibility A product owner in Scrum is responsible for maximising the value a product creates. The role has to ensure that the product offers the desired value to the users and the customers, as well as to the company that develops and provides it. To fulfil this responsibility, a product owner has to be empowered to own a product in its entirety—to make the necessary tactical and strategic product decisions. In other words, a Scrum product owner has to have the final say on the key decisions, from setting the product vision and determining the product strategy to developing the product roadmap and prioritising the product backlog. In practice, however, Scrum product owners are not always sufficiently empowered. A widespread misunderstanding is that they should focus on delivery and execution, write user stories, and ensure that a development team does a good job. But it is impossible to take responsibility for the value a product creates without having the authority to make the necessary strategic decisions. It's worthwhile to note that there is another product owner role, the SAFe product owner. This role is focused on the tactics and does not have full ownership of a product. While both roles are called product owner, they differ significantly and have little in common. It’s therefore important to clearly distinguish them, as I explain in the article Six Types of "Product" Owners. Common Tasks Here is a list of six common tasks that help a product owner maximise the value of their product: Carry out (continuous) discovery and strategizing work. This includes connecting with users and customers; performing competitive analysis; and monitoring market trends. Create and update product plans like a product strategy and a product roadmap. Update, prioritise, and refine the product backlog. Break larger product backlog items into smaller ones so that they are ready for the next sprint. Attend meetings including product strategy review meetings as well as sprint planning, sprint review, and sprint retrospective meetings. Collect and evaluate feedback and data on the latest product increment and measure the product performance using the right key performance indicators (KPIs). A common mistake I see Scrum product owners make is to neglect the discovery and strategy work—sometimes because they are not empowered to take care of them, but often, because these tasks are not as urgent as breaking epics into more detailed user stories to keep the team moving forward. But if you deprioritise the strategic work, you might overlook a market development, get caught out by a competitor, and find yourself struggling to catch up. I therefore recommend that as a rule of thumb, you spend at least half-a-day per week on product discovery and strategy-related tasks, be it interviewing users, reviewing the latest performance data, or monitoring the competition. Collaboration You might be wondering how a single Scrum product owner can carry out all the tasks I mentioned, and how the individual is able to make the right product decisions. The answer is: by collaborating with the right people—the key stakeholders, one or more development teams, a Scrum Master, and possibly other product people in case if the product is too big to be successfully managed by a single product owner. The key stakeholders are those individuals that have an interest in the product and whose contributions are required to provide the product. For a commercial product, a key stakeholder might be a marketer, sales rep, and customer service team member. A development team in Scrum is a cross-functional, self-managing group with up to nine members. For end user-facing products, the team usually consists of UX/UI designers, architects, programmers, testers, and other roles that are required to design, develop, test, document, and deploy product increments. I find it helpful to involve the key stakeholders and at least some development team members in the discovery and strategizing work. For instance, invite the individuals to quarterly strategy reviews where you inspect and adapt the product strategy and roadmap. Additionally, ask the stakeholders to regularly attend the sprint review meetings, at least once every month, as a rule of thumb. Carry out the product backlog work together with the development team members. This includes updating and prioritising the backlog and breaking larger items into smaller ones. Some development teams are even happy to carry out part of the refinement work on their own. Finally, let the Scrum Master take care of process and organisational issues so that you can focus on managing the product, as the Scrum product owner.... - Published: 2010-09-08 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/stable-teams/ - Categories: Product Roles - Tags: empowerment, product owner, scrum, self-organisation, teamwork It’s not uncommon for me to visit a new client and discover that the agile development teams frequently change, sometimes after every single sprint. Changing the team composition too frequently is usually undesirable, though. Teams need stability to flourish and realise their full potential. This post provides practical tips to help you create stable agile teams. Get the Right People on Board Carefully consider who should be on an agile development team. Having the right individuals on board is probably the biggest success factor for any development effort, no matter which process is used. Determine the necessary hard and soft skills required and ask your Scrum Master for help if you are unsure which capabilities will be needed. Don't forget that an agile development team is cross-functional and typically includes individuals with UX / UI design, architecture, programming, and testing skills. You may also required additional capabilities to create or extend a product, like database administration and configuration management. The following picture shows a sample agile development team. A great technique to find the right individuals is self-selection: Let people decide if they want to be on the team or not. Consequently, the team members are likely to take full ownership of their work and be motivated to work together, which is a prerequisite for growing a great team and building a successful product. Minimise Changes to the Team Once the right people are on board, I find it helpful to minimise any changes to the development team. It takes time for a group of individuals to become a true team–a tightly knit unit with members that trust and support each other and that work together productively, as the following picture illustrates. The picture above shows Tuckman's team building model. According to the model, people in a newly formed team have to get to know each other (forming) and rub shoulders (storming) before they can establish common ways of working (norming) and finally become a productive team (performing). Changing the team composition causes the this process to start all over again. As a result, productivity and self-organisation are likely to suffer. If you change a team too often, it may never reach the performing stage and fulfil its true potential. You should therefore carefully manage changes to the development team. A good time for people to leave and new individuals to join is after the release of a new product version. The majority of the team members, however, should continue to work on the product in order to avoid loss of information, defects, and delays. Align Teams and Products Last but not least, align development teams and products. Every product should be developed by one or more dedicated teams, as the picture below shows. This does not only facilitate ownership and learning, but it simplifies the allocation of people and resources and it can help minimise cross-team dependencies. In the picture above, team A is responsible for designing, developing, and testing product A, and team B does the same for product B. Ideally, both teams have full control over their respective product and can test ideas and release new features independently of each other. Note that the organisation has to have a shared definition of what a product is in order to take full advantage of the approach shown in the picture above. To put it differently, if you are not clear what a product is, then you can't organise around the assets in a consistent and helpful way. - Published: 2010-08-18 - Modified: 2024-02-02 - URL: https://www.romanpichler.com/blog/refining-user-stories/ - Categories: Product Backlog & User Stories - Tags: epic, product owner, user story User stories come in different shapes and sizes. Large stories, also called epics, allow quickly sketching product functionality, which is handy for scoping a major release. But it means that larger stories have to be eventually refined and broken down into smaller, detailed ones, which the development team can implement. This post shares some tips to help you systematically refine your user stories. Grooming the product backlog entails breaking down user stories from larger product backlog items until they are small enough to fit into a sprint. Although detailing product backlog items should be delayed until the last responsible moment, you might have to start refining a story a couple of sprints in advance before it can be implemented, particularly if the story is large or complex. Let’s look at an example of how user stories can be broken down progressively. As the picture above illustrates, the epic “Compose email” is broken down into several stories. The user story “State recipient” is then further decomposed into two more fine-grained stories. These are now small enough to fit in a sprint. The epic is an example of a compound story, a user story that has more than one goal. To decompose such a story, we introduce a separate story for each goal. “Compose email” is therefore broken into “State subject,” “State recipient,” and “Set importance” to allow an incremental delivery of the functionality. This technique is also called slicing the cake. There are other user stories that need to be made smaller, including complex stories and stories with monster criteria. A complex user story is a story that is too big to be delivered in one sprint because of its inherent uncertainty or because it covers too much functionality. If it is too uncertain, you may want to introduce one or more items into the product backlog that explore that uncertainty and generate the relevant knowledge, for instance, “Investigate JavaServer Faces as the user interface technology. ” Stories sometimes look fine until we consider the acceptance criteria. If there are too many—more than about five—or if requirements hide in the criteria, you should rework and decompose the story. Here is an example: “As a user, I want to delete a text message. ” The acceptance criteria state, “I can select any text message. I can remove the message text. I can save the modified message. ” Not only is the second condition redundant, but the other two introduce new requirements rather than specifying acceptance criteria. This story should be split into three: a story about deleting text messages, a story about editing text messages, and another story about saving the modified messages. - Published: 2010-07-23 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/the-lean-product-backlog-variation-and-overburden/ - Categories: Product Backlog & User Stories - Tags: product owner, requirements Many product backlogs are too long, detailed and complex. This is in stark contrast to what the product backlog should be: a simple artefact listing the outstanding work to bring the product to life. This blog post discusses lean techniques to make the backlog concise and focussed by avoiding variation and overburden. Limit Unnecessary Variation Variation, also called unevenness, prevents a smooth flow of work. While not all variation in the product backlog is bad -- the size of its items should vary depending on their priority to minimise waste, for instance -- reducing unnecessary variation helps create a lean backlog and a lean workflow: Standardise the techniques for describing product backlog items. Choose user stories to capture functional requirements and operational qualities such as performance and robustness requirements, for instance. Agree on a common way to describe usability requirements such as sketches, wire-frames or mock-ups. Use a sprint goal. The sprint goal summarises the desired outcome of the sprint, and moves the Scrum team a step closer toward the release of the product. A shared sprint goal ensures that everyone is working toward a common goal. It minimises variation by limiting the type of requirements worked on in a given sprint, for instance, by choosing items from the same theme. This facilitates close teamwork and can increase velocity. Ensure that the high-priority items have roughly the same size and favour small items – items that can be transformed into a part of the product increment within a few days. This reduces variation, improves the progress tracking within the sprint, and prevents defects by allowing the product owner to provide just-in-time feedback on the work results. Note that this approach works best when the team uses agile development practices including story-driven development. Create a steady cadence by using fixed-length releases. Time box your projects: Identify the window of opportunity based on the product vision and the product backlog, and freeze the release date. Take Salesfore. com, a leading provider of on-demand customer relationship management services. The company releases a product update every four months. As a consequence, Salesforce. com experienced an amazing increase in the number of features delivered while drastically reducing its lead-time for new functionality. Note that a fast, steady cadence supports other measures including minimising the inventory in the product backlog. Prevent Overburden As long as people work crazy hours, and as long as projects and teams are overwhelmed by the amount of work, the removal of waste and variation is ineffective. Waste and variation are likely to creep back in unless we limit the amount of work to the capacity and capabilities of the organisation. Let's assume we try to eliminate defects but the project still suffers from overburden. Chances are that quality problems reappear since the project members still feel pressured and are overworked. In fact, overburden is a major source of waste including work-in-progress, waiting and delays, task-switching, and defects. To eliminate overburden, let the product backlog evolve based on customer and user feedback. View changing requirements as a competitive advantage and leverage the feedback together with the project progress to decide which functionality is implemented. Encourage the team to pull only as many items into the sprint as they can transform into a product increment in a sustainable way. Ensure that the high-priority items are ready: They should be clear, testable and feasible. This avoids that the team overlooks tasks and pulls too much work into the sprint. And last but not least, make high-priority items small. This allows the team to optimise its work utilisation. It also avoids the danger of missing tasks – which is a common issue with large stories. - Published: 2010-07-09 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/the-lean-product-backlog-eliminate-waste/ - Categories: Product Backlog & User Stories - Tags: product owner, requirements, waste Many product backlogs are too long, detailed and complex. This is in stark contrast to what the product backlog should be: a simple artefact listing the outstanding work to bring the product to life. This blog post discusses lean techniques to make the backlog concise and focussed by eliminating waste. Think Lean “We have 12,000 stories in our product backlog. How can we best groom it,” I was recently asked. Trying to deal with a huge product backlog is more common than we would like to think. Many product backlogs are too long, detailed, and complex. This is in stark contrast to what the product backlog should be: a simple artefact listing the outstanding work to bring the product to life. It’s time to put any over-weight product backlog on a diet making it lean and concise. Lean thinking aims to create a smooth, levelled flow of work by removing waste, minimising variation and avoiding overburden. Waste includes inventory and work-in-progress, defects, delays, and unused employee creativity. Examples of variation are frequent changes to the team and varying release cycles. Overburden occurs when people and resources cannot cope with the workload placed on them. If we want a lean product backlog, then it should contain as little waste and variation, and cause as little overburden as possible. This post focuses on eliminating waste. I will discuss minimising variation and avoiding overburden in a future post. Eliminate Waste Waste consumes valuable resources and makes it harder to focus on what’s important. To remove waste in the product backlog, reduce the inventory the backlog holds, avoid overproduction and minimise defects, handoffs and wasted creativity, as I explain in more detail below. Reduce the inventory in the product backlog: Minimise the amount of detailed product backlog items and only include items in the backlog that are essential for creating a successful product. Ensure that just-enough high-priority items are detailed just in time for the next sprint planning meeting. As a consequence, product backlog items are progressively decomposed and refined – from sprint to sprint. Lower-priority items stay coarse-grained and sketchy until their priority changes. Avoid overproduction – providing more functionality than users and customer need. Focus on the minimum functionality necessary to bring the product to life, and only list truly valuable items in the backlog. Have the courage to remove all other items from the product backlog. This keeps the product backlog concise and the Scrum team focused. If an item becomes important for a future version, it will re-emerge. Minimise defects, handoffs and unused creativity by involving the team members and the stakeholders in grooming the product backlog. Jointly discovering and describing product backlog items avoids handing off requirements to the team. It ensures clarity of the requirements thereby reducing defects; and it leverages the creativity and knowledge of the team members and stakeholders. Jointly prioritising the product backlog ensures that technical risks and dependencies are accounted for. Problems consequently surface early, which prevents defects at a later stage of the project. - Published: 2010-07-02 - Modified: 2026-02-02 - URL: https://www.romanpichler.com/blog/think-product/ - Categories: Product Management Process, Product Vision and Strategy - Tags: product owner This blog post explores the notion of a product in Scrum. Being clear on what a product is a prerequisite for effective product innovation. Scrum has a strong product focus; it knows a product owner, a product vision, a product backlog, and a product increment. But what is a product? The answer to this question can be tricky. Take the attendees of a recent product owner workshop I ran who found it difficult to agree on what their products are. Another client of mine was completely project-driven before using Scrum; short projects often involved updating a number of applications and systems. When asked about their products, developers would answer, “Oracle,” or “Websphere”, rather than referring to the software they created. And another company I worked with had more than 20 different definitions of the term product. So what is a product? I like to think of a product as a collection of attributes (or features) that address customer or user needs, thereby providing value. A good first step in identifying products is to ask, “Who benefits from our software? Who purchases and who uses it? ” and “What value does the software provide? ” A product is developed using a project, which creates one or more releases and results in a new product version, as the following sequence shows: Customer and user needs→ Are addressed by a product→ Has a version→ Is developed by a project→ Creates one or more releases Products are means to an end to meet customer and user needs. Projects and teams serve to bring the next product version to life. Understanding which products an organisation develops is the prerequisite for achieving product success. It enables longer-term thinking and finding the right people. Only if it’s clear what the product is can management find the right product owner, and can the right people be invited to join the development effort. So think products. Not projects, not teams, and not components. Focus on what ultimately counts – to create a great product to help customers and users–and organise accordingly. - Published: 2010-06-18 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/prioritising-the-product-backlog/ - Categories: Product Backlog & User Stories - Tags: product owner, requirements, risk, teamwork This blog posts explores four useful factors to prioritise the product backlog: value; risk and uncertainty; releasability; and dependencies. Why Product Backlog Prioritisation Matters Prioritisation requires us to decide how important an item is. If everything is high priority, then everything is equally important. This means in effect that nothing is a priority, so there is only a slim chance of delivering what the customer really needs. Prioritisation is part of product backlog grooming, and it directs the team’s work by focusing the team on the most important items. It also freezes the product backlog contents progressively. As items are detailed according to their priority, flexibility is built into the process and allows delaying decisions about the lower priority items, buying you more time to evaluate options, gather feedback from customers, and acquire more knowledge. This ultimately results in better decisions and a better product. The reminder of this posts explores four useful factors to prioritise the product backlog: value; risk and uncertainty; releasability; and dependencies. Value Value is a common prioritisation factor. We certainly want to deliver the most valuable items first. But what makes a product backlog item valuable? My answer is simple. An item is valuable if it is necessary for bringing the product to life. If that’s not the case, the item is irrelevant; it is excluded from the current release or product version. You either de-prioritises the item and places it right at the bottom of the product backlog or better, discards it altogether. The latter keeps the product backlog concise and the development team focused. If the item is important for a future version, it will re-emerge. Risk and Uncertainty Risk is an intrinsic part of software development; no product can come to life risk-free. Correlated with risk is uncertainty. The more uncertainty there is the riskier the project is. Because risk and uncertainty influence product success, uncertain and risky items should be high priority. This accelerates the generation of relevant knowledge, drives out uncertainty, and reduces risk. For instance, if you are unsure about some aspects of the user interface design, then the relevant design options should be explored and tested by gathering feedback from users. Tackling uncertain, risky items early creates a risk-driven approach that may enforce early failure. Failing early allows you to change course while there is still the opportunity, for example, to modify the user interaction or the architecture and technology selection. Releasability Releasing early and frequently is a great way to let the software evolve into a product that customers love. It’s also an effective way to mitigate risks. If you are uncertain about if and how a feature should be implemented, then early releases can answer this question. Being able to release product increments early and frequently should therefore influence the product backlog prioritisation. Each release should provide functionality that is useful to customers and users and that generates the desired feedback. Note that it’s usually not necessary to fully implement a theme; a partial implementation is often sufficient for early releases. Dependencies Wether we like it or not, dependencies in the product backlog are a fact. Functional requirements, for instance, often depend on other functional and even non-functional requirements. And if several teams work together, dependencies between them can influence the prioritisation. Dependencies restrict the freedom to prioritise the product backlog and influence the effort estimates; the item others depend on has to be implemented first. You should therefore try to resolve dependencies whenever possible. If that's not an option then the dependencies are likely to influence the product backlog prioritisation. Two dependent items may have to be implemented in the same sprint, for example. - Published: 2010-06-11 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/when-to-break-up-your-product-backlog/ - Categories: Product Backlog & User Stories - Tags: product owner, requirements The product backlog is meant to be a simple tool that allows product owners to express detailed product decisions and direct the work of the development team. But in practice, product backlogs can grow big and become large and unwieldy. Break up your product backlog can address this issue, as this article explains. The product backlog is a beautifully simple artefact – a prioritized list of the outstanding work necessary to bring the product to life. In reality, many product backlogs are large and unwieldy – rather than simple and concise. If you regularly groom your product backlog but still struggle with its size and complexity, then you may have a backlog that contains items from more than one product: requirements describing different products but kept in the same backlog. This may be due to one Scrum team developing several products concurrently or creating a new software system while maintaining its predecessor. If that’s the case, break up your product backlog and create a separate backlog for each product. This will not only result in smaller backlogs that are easier to groom. But it will allow you to better prioritize which product takes priority – the development of the new software or the maintenance of the old system, for instance – thereby making the corresponding portfolio management decisions explicit. You can simplify your product backlog even further by focussing on the next product version and by minimising the number of items describing future releases. As the future is uncertain and markets are likely to change, carrying many future requirements does not only bloat your product backlog; it is wasteful and makes it difficult to adapt your product to the market response. Have the courage to weed out items that are not essential to creating the next product version. Simplify, prune, and strive for order. Discarded items will come back to you if they do become relevant in the future. - Published: 2010-05-26 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/pull-processes/ - Categories: Product Management Process - Tags: scrum Pull processes do not only play an important role in Kanban, they are also fundamental to Scrum. This post characterises pull and how it differs from push, the traditional way of organising work. Pull processes do not only play an important role in lean approaches such as Kanban, they are also fundamental to Scrum: Applying the framework generates a pull process where teams pull work from the product backlog into the sprint. Understanding what a pull process is and how it works helps you apply Scrum and Kanban effectively. The easiest way for me to illustrate the difference between push and pull is to evoke a childhood experience you may share with me: drying the dishes. I vividly remember being called into the kitchen after Sunday dinner where my mum had already piled up the clean wet dishes. Even though I would frantically try to reduce the size of the pile in front of me, I always ended up finishing off the job long after my mum had retreated to the living room together with the rest of the family. Now imagine running cleaning and drying the dishes in pull mode. The first thing my mum and I would do is to agree on a small buffer of clean wet dishes, say three. I would then wait for my mum to populate the buffer. As long as the buffer is full, my mum is not able to clean any new dishes. Only once I have started drying one of the dishes, she would clean the next dish. Establishing a pull process changes how work is carried out: It closely links formerly disjointed process steps; problems and impediments now surface quickly. A pull process eliminates waste such as partially done work (also called work-in-progress or WIP). What's more, it creates a sustainable pace by avoiding overburden: In Scrum, the team determines how much work they can pull into the sprint and hence manages its own workload. In Kanban, WIP limits ensure that demand is matched to capacity. Be aware that establishing pull usually involves disruptive change. It it requires that the people carrying out the work take on ownership and are empowered. Work can no longer be pushed onto anyone. It now has to be pulled along. - Published: 2010-05-20 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/when-scrum-is-not-a-good-fit/ - Categories: Product Management Process - Tags: scrum Scrum is a simple, powerful framework created to manage the development of complex products. But seeing Scrum as a silver bullet is an easy trap to fall into, as this post illustrates. Scrum is a simple, powerful framework created to manage the development of complex products. But seeing Scrum as a silver bullet is an easy trap to fall into, as the following story illustrates. I was recently asked to help a client apply Scrum to its localisation work to make the progress of work items more transparent. The client had already used Scrum in product development for some time, and spreading it to other business areas seemed like the next logical step. To better understand the client’s context, we held a workshop and performed a value stream analysis – walking through the entire workflow from issuing a localisation request to delivering the finished piece of work. Visualising the process showed that two steps in the process caused problems including delays and defects. But unfortunately, the workshop participants were not able to back them up with empirical data. Reflecting on the value stream map, I was not able to see how Scrum could be effectively applied to the process. There was no team and no need for close teamwork; there was no product that could be built up incrementally – requests were worked on independently and concurrently by translators in different countries; the localisation backlog was neither dynamic nor made it sense to detail its items at different levels; and work was pushed from one step to another with the project manager chasing requests and individuals. To help the localisation team better manage their work and collect important data such as where and when impediments occur, how long it takes to complete a certain type of localisation requests, we simplified the value stream map and created a simple Kanban board captured in a Google spreadsheet. The board itself does not improve the process at all but it provides a simple high-level view of the entire process visualising the progress of individual items. We colour-coded different request types and decided to mark blocked items in red. The team now has the right tool to collect the necessary data to quantify their problems and calculate the business impact. What's more, the board makes it easier to manage the work thereby reducing the project management overhead and encouraging collaboration. Once the data is available, it will help promote process improvements including changing the process from push to pull and increasing the stakeholder participation. Interestingly, clarifying the ownership of localisation requests will be fundamental to making significant progress – moving from handing off requests to close collaboration. But product ownership and the role of the product owner in a lean, Kanban-based context is the topic of a future post. - Published: 2010-05-11 - Modified: 2024-02-02 - URL: https://www.romanpichler.com/blog/user-stories-or-use-cases/ - Categories: Product Backlog & User Stories - Tags: product owner, requirements, teamwork, user story User stories and use cases are both powerful techniques to capture requirements. But which one is right for you? This post shares my recommendations. Use Cases and User Stories in a Nutshell Use cases describe how a customer interacts with the product using one or more scenarios. It commonly consists of several structured scenarios including main success scenario, alternative scenarios and failure scenarios as well as the actor, a trigger, and pre- and postconditions. (Note that there are also so-called casual use cases that simply consist of a brief narrative but I find that these are not very common. ) User stories describe how a customer or user employs the product. Stories consist of a name, a brief narrative (the actual story) and a set of acceptance criteria. The latter formulate conditions that must hold true thereby making the story more precise. User stories are more informal than use cases, as they complement the text with a conversation: The person in charge of the product and the development team members must discuss each story. This creates a shared understanding and ensures that the story is feasible and testbale. Both techniques put the customer or user at the center of the development effort. Use cases use actors to characterise the people interacting with the product; user stories use user roles or personas; and the functionality is described from the perspective of a customer or users. This encourages a user-centric and a void a solution centric mindset, that is, to focus first and foremost on the customers and users rather than being guided by technology. Benefits and Drawbacks User stories have become so popular since they appeared in the second half of 1990s for one main reason: they help you move fast.  User stories encourage you to quickly sketch an idea or requirement, discuss it with the development team, expose the resulting software to the customers and users, analyse the feedback or data, and then decide what to do next. User stories move from documenting requirements to tacit knowledge: product owner and development team have a shared understanding of what the product needs to do, as they discuss and sometimes even co-write the stories. This saves time, but it does require close and effective collaboration. Use cases are more structured and detail-rich, and they can embedded in models, such as, context diagrams. Creating a use case is usually much more work than capturing a user story, and this means that the development speed tends to be slower. But more detailed requirements are useful when a close collaboration between product owner and development team cannot be achieved, for example, when you work with a remote or offshore team. Recommendation My advice is: work with user stories whenever you can and write use cases if you must, that is, when you cannot enable close and regular collaboration between the person in charge of the product and the development team—be it in form of onsite or online workshops. This does not imply, however, that you shouldn't learn more about use cases, including the modelling techniques they offer. The opposite is true: I'd like to encourage you to try out both approaches so you can determine which one works best for you. Alistair Cockburn's book Writing Effective Use Cases and Mike Cohn's book User Stories Applied are two classic reads, which will help learn more about the two techniques. - Published: 2010-04-26 - Modified: 2024-10-14 - URL: https://www.romanpichler.com/blog/how-much-product-discovery-is-necessary/ - Categories: Product Vision and Strategy - Tags: innovation, product life cycle, product manager, product owner Product discovery, exploring the value proposition, market, differentiators, business goals, and business model of a new or updated product, is crucial to achieve success. But getting the product out as quickly as possible is often equally important. In this post, I explore the question how much product discovery is required and how to best balance the necessary discovery work with reducing time to market. How much product strategy work is necessary? While I find it impossible to give a general, precise, and accurate answer, there is one factor that has a big influence on the time and effort necessary to create a valid product strategy: the product's lifecycle stage. The younger a product is, the more strategy work it tends to require. A new product development effort may spend several weeks carrying out necessary prep work such as creating an initial product strategy and iteratively testing and correcting it. Contrast this with incremental enhancements of a mature product that may require very little strategy work, as the following picture shows. Please note that the line representing the strategizing effort in the picture above is only a rough approximation. In the case of your product, the effort might be higher or lower, and it might fall later or sooner. The picture also assumes that the product moves from growth into the maturity and decline stages. Be aware, though, that when you extend the life cycle of your product, for example, by creating a variant for a new market (segment), unbundling one or more features, or changing the business model, you will have to carry out a significant amount of discovery and strategizing work, as the picture below illustrates. When determining the strategizing effort, don't make the mistake of skipping or shortcutting the necessary work. Don't start the actual development work without a valid product strategy in place, without having nailed the value proposition, market, differentiators, and business goals of the new or changed product. Consider showing the necessary work on your product roadmap, particularly when you make bigger changes to an existing product. At the same token, avoid overdoing the discovery work. There is no way to guarantee that the product strategy is correct and that the new product or next version will be a success. Your goal should therefore be to get a good enough product out as fast as possible, and then adapt it to the market feedback. - Published: 2010-04-08 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/why-product-owners-should-care-about-quality/ - Categories: Product Roles - Tags: product owner, requirements, software quality Software quality is often perceived as something the nerds should worry about. But it can significantly impact customer satisfaction and brand value; the total cost of ownership and life expectancy of your product; and the product’s competitiveness. This post explains what product owners can do to help their development teams get quality right. Why Quality Matters Quality influences customer satisfaction and brand value. It's like drinking coffee. Who wants bad-tasting or strange looking cup? Only if the product’s functionality works reliably as expected will customers be satisfied and value the brand highly. Defective software does not only leave customers dissatisfied, frustrated or angry, it also damages the brand value. Think about the issues Microsoft experienced with Windows Vista. These contributed customers defecting Microsoft and to the company to discontinuing the Vista brand calling its next OS version “Windows 7. ” Quality impacts the total cost of ownership and life expectancy of a product. Getting software out of the door quickly with poor quality may achieve a short-term win but it incurs technical debt: The software becomes difficult to extend and maintain, as Ward Cunningham observed nearly two decades ago. This results in high cost and long lead times for new functionality. And software with poor quality often has to be replaced sooner rather then later resulting in a short life expectancy and a poor return on investment. Quality affects the product’s competitiveness: To create a product that incorporates customer feedback on early product increment, to release software in response to the latest market development, and to bring new functionality to the market quickly is only possible if the product exhibits the right quality. Take the development of Google News, an application that aggregates news from around the world. Google used user feedback on early versions of the software and user requests for new features to determine which functionality the product should contain. Compromising software quality means trading in short-term gains for longer-term growth cheating the company of a better, brighter future. As the product owner, you are first and foremost responsible for product success. Software quality should hence be a concern to you. What Product Owners can do to Ensure Right Quality Think products, not projects: A product owner should own a product and look after it for an extended period of time thereby managing the product’s lifecycle. A longer-term responsibility counteracts the temptation to compromise quality in order to get the next release out as soon as possible. It creates a desire for sustained success and it encourages long-term thinking. Create a common understanding of quality. Make sure that a definition of done is available and apply it properly. The definition should clearly state the general quality criteria product increments must fulfil. It usually requires that a (potentially) shippable product increment is available at the end of each sprint: executable software that has been tested and documented and that could be released. As a consequence, quality assurance and control measures form an integral part of the development work—instead of being carried out at the end of the project as an afterthought. Be specific what tested and documented mean for your product; I have worked with teams that used metrics to refine and measure the quality criteria. As the product owner, you have to apply the done criteria to accept or reject work results when reviewing items; only work results that fulfil all the done criteria can be accepted. By enforcing the definition of done the product owner acts as the guardian of quality. Minimise defects and unnecessary rework. Groom the product backlog together with the team and by be available to answer questions as they arise. With requirements emerging and changing, the product backlog needs continued attention and care. New items have to be captured, existing ones adjusted or removed. Items have to be prioritised and estimated; and the high-priority items have to be ready for the next sprint planning meeting. User stories likely to be implemented in the next sprint should now have well-formed acceptance criteria, for instance. Jointly grooming the product backlog ensures that it contains the right items in the right order. It also reduces the likelihood that an items implementation differs from how the product owner intended it to be realised. When it comes to product owner availability, I often suggest the one-hour rule: Product owners should spend at least one hour per day on average with their teams in the same room. This ensures that the product owner is available to answer questions and to provide feedback on work results. Invest in quality: Product owners must understand that team members need time to create high-quality software and regard agile development practices like test-driven development and continuous integration as a great way to ensure sustained product health. Setting aside time for team members to experiment with new practices... - Published: 2010-03-31 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/desirable-characteristics-of-a-product-owner/ - Categories: Product Roles - Tags: product owner, skills I often get asked what characteristics a product owner should exhibit. Even though the answer depends on a number of factors including the type of the product, its importance, complexity and newness as well as the size of the project, successful product owners I have worked with share the attributes discussed in this post. Visionary and Doer The product owner is a visionary who can envision the final product and communicate the vision. But the product owner is also a doer who sees the vision through to completion. This includes validating ideas and capturing user stories, closely collaborating with the team, analysing feedback from stakeholders and users, and updating the product backlog. As an intrapreneur, the product owner should be comfortable with change, ambiguity, debate, conflict, and informed risk taking. Leader and Team Player As the individual responsible for the product’s success, the product owner provides guidance and direction for everyone involved in the development effort and ensures that tough decisions are made. For instance, should the launch date be postponed or should less functionality be delivered? At the same time, the product owner must be a team player who relies on close collaboration with the other Scrum team members, yet has no formal authority over them. You can think of the product owner as primus inter pares, first among peers, regarding the product. Being a leader and team player can be a hard line to toe. By no means should the product owner dictate decisions, yet at the same time neither should the product owner be indecisive or employ a laissez-faire management style. Instead, the individual should act as a shepherd for the innovation process, guiding the project and seeking team consensus in the decision-making process. Making decisions about the product collaboratively ensures the team’s buy-in, leverages the team’s creativity and knowledge, and results in better decisions. Working this way requires facilitation and patience because team members often have to disagree and argue first before a new solution can be synthesised from the different ideas and perspectives. Communicator and Negotiator The product owner must be an effective communicator and negotiator. The individual communicates with and aligns different parties, including customers, users, development, marketing, sales, service, operations, and senior management. The product owner is the voice of the customer, communicating customer needs and requirements and bridging the gap between “the suits” and “the techies. ” Sometimes this means saying no and other times negotiating a compromise. Empowered and Committed The product owner must have enough authority and the right level of management sponsorship to lead the development effort and to align stakeholders. An empowered product owner is essential for leading the effort to bring the product to life. The product owner must have the proper decision-making authority—from finding the right team members to deciding which functionality is delivered as part of the release. The individual must be someone who can be entrusted with a budget and at the same time has the ability to create a work environment that fosters creativity and innovation. Finally, the product owner must be committed to the development effort. Available and Qualified The product owner must be available and qualified to do a great job. Being the product owner is usually a full-time job. It is important to give product owners enough time to sustainably carry out their responsibilities. If the individual is overworked, the project’s progress suffers and the resulting product may be suboptimal. Being adequately qualified usually requires an intimate understanding of the customer and the market, being passionate about the user experience, and the ability to communicate needs and describe requirements, to manage a budget, to guide a development project, and to be comfortable working with a cross-functional, organising team. Nobody is Perfect Before you now look for the perfect product owner or worry that you might not fit the bill, be aware that product owners usually need time and support to transition into the role and to acquire the necessary skills. And nobody is perfect: Every product owner has some strengths that facilitate playing the role as well as some weaknesses that can make it challenging. A product owner may be very good at envisioning the product, talking to customers, and creating the product roadmap but may not be used to work closely with a bunch of techies or lack the necessary strategic skills, for instance. A common challenge is finding employees with the necessary product management and market/product-specific knowledge to do the job well. - Published: 2010-03-24 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/creating-products-that-customers-love/ - Categories: Product Vision and Strategy - Tags: user feedback We all want to create great products–products that customers love and that meet or exceed our financial goals. But the odds of failure are high: an estimated 25% to 45% of new products fail. This post discusses three practices that I have found helpful to create successful products with Scrum: shared product vision, a focused product, and early and frequent customer feedback. Shared Product Vision Ensure that you have a shared vision in place that describes the target customers and users, the needs the product is going to address and what the product will roughly look like and do. Consider not only the key functional attributes but also non-functional ones including user experience and operational qualities such as performance and robustness. Use prototypes and mock-ups to develop the vision and to gather feedback from target customers and users. Focused Product Envision the minimal marketable product – a product with minimum functionality that meets the selected customer needs. This shortens time-to-market and allows you to find out quickly how the market responds. If the response is not great then adapt then product to better meet the customer needs. Note that even if you carefully select the target customers and users to gather early feedback as described below, their views might not be representative for the entire market or market segment. And hardly ever is the first version of a product perfect. Early and Frequent Customer Feedback Third, gather early customer and user feedback by inviting (selected) customers and users to sprint review meetings and by releasing product increments early and frequently. This integrates customers and users into the development process, and it lets the product evolve based on their feedback. It also shows you quickly if you are shooting for the right goal or if your product vision is ill-conceived. - Published: 2010-03-16 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/product-owner-product-manager/ - Categories: Product Roles - Tags: product manager, product owner This blog post explores the differences between working as a product manager and playing the product owner role. “The Product Owner is responsible for maximizing the value of the product (... ),” states the Scrum Guide. This sounds like a core product management responsibility to me. So what’s the difference between a product manager and a product owner? Working as the product owner implies taking on many product management responsibilities including understanding the market, describing product functionality, and preparing the product launch. This makes product managers well suited to play this new role. But a product owner is more than just a re-branded product manager: Product owners tend to take on a wider range of duties, which makes the role multi-faceted and challenging. The following formula captures this insight: Product Owner = Product Manager + x My experience suggests that the x above comprises additional strategic duties including envisioning the product and managing the product roadmap as well as further tactical ones, such as collaborating with the development team throughout the development effort, writing user stories, carrying out release planning, and managing stakeholders. Consequently, product owners often require more authority and more focus to do their job well. Note that product ownership is teamwork in Scrum: Requirements are no longer identified and described by one person. Product owner, ScrumMaster and team collaborate on a regular basis to groom the product backlog. Working as a first-time product owner is hence a new experience and a challenge. The right training and coaching measures can help product owners get up to speed faster. “Early immersion and training of the product owners in agile principles, product backlog creation, user story design and estimation and planning is key to the success of any agile team. Also, beyond initial training, continuous product owner coaching throughout the rollout is necessary to ingrain the new process into the culture,” write Fry and Greene about their experience at Salesforce. com in their article “Large Scale Agile Transformation in an On-Demand World. ” - Published: 2010-03-09 - Modified: 2023-05-09 - URL: https://www.romanpichler.com/blog/business-analysts-in-scrum/ - Categories: Product Roles - Tags: product owner, scrum Business analysts play an important role: Traditionally, they act as the link between the business units and IT, help to discover the user needs and the solution to address them, and specify requirements. But in Scrum, there is no business analyst role. So what happens to the individuals? Business Analyst as Product Owner One option for business analysts is to take on the product owner role, as the following picture shows. I feel that this option is often a natural extension of the business analyst role. But it usually implies significant changes: The individual should now own the product on behalf of the company, make the appropriate product decisions, and be responsible for product success. The new product owner often has to learn new skills to effectively play the role. This includes creating a valid product strategy, developing an actionable product roadmap, and aligning the stakeholders in addition to working with the development team and managing the product backlog. Consequently, the individual will usually benefit from developing the appropriate product management skills. Business Analyst as Team Member The second option for business analysts is to work as team members. This option is depicted by the picture below. Business analysts working on team often help their peers refine the product backlog. But as backlog refinement should be a team effort, analysts working on the team will take on additional responsibilities, for instance, working closely with the testers or the technical writer. As a business analyst on the team, you should hence expect to learn new skills and broaden your expertise. Avoid the Proxy Product Owner Trap Dealing half-heartedly with the role of business analysts in Scrum is a common mistake: Business analysts neither play the product owner role nor are they team members. Instead, they end up as proxy product owners, a go-between the real decision maker and the development team, as shown below. Avoid using a proxy product owner—certainly as a permanent solution. Take the following example from one of my clients. The head of a business unit was asked to take on the product owner role for a new product. As the individual struggled to effectively fill the role due to their other work commitments, the business analyst stood in as a proxy. While the analyst took care of the product backlog, the business unit head make the strategic product decisions and told the analyst which product features should be implemented. Unfortunately, this resulted in misalignment, a long-winded decision-making process, and poor morale. - Published: 2010-03-01 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/what-is-agile-product-management/ - Categories: Product Management Process - Tags: product definition, product discovery, product owner, requirements, user feedback Find out how agile product management differs from traditional approaches. This post summarises the key differences between old-school and agile product management. Agile product management has been fashionable for some time. But different people associate different meanings with it – from simply using the product backlog to extending Scrum by employing complex new frameworks.  I view agile product management as fundamentally different from traditional product management approaches.  To better understand the differences, let's see how agile and old-school product management compare.  The following table–adapted from my book Agile Product Management with Scrum–summarises five key changes. Old School New School Several roles, such as product marketer, product manager, and project manager, share product decision-making. One person—the product owner—is in charge of the product and leads the project. Product managers are detached from the development teams, separated by process, department, and facility boundaries. The product owner is a member of the Scrum team and works closely with the Scrum Master and team on an ongoing basis. Extensive market research, product planning, and business analysis are carried out up front. Minimum up-front work is expended to create a vision that describes what the product will roughly look like and do. Up-front product discovery and definition: requirements are detailed and frozen early on. Product discovery is an ongoing process; requirements emerge. There is no definition phase and no product requirements specification. The product backlog evolves based on customer and user feedback. Customer feedback is received late, in market testing and after product launch. Early and frequent releases together with sprint review meetings generate valuable customer and user feedback that maximises the chances of creating a successful product. Agile methods embrace an age-old truth: They see change as the only constant. If flux and unpredictability are dominant forces, then our ability to accurately forecast markets and predict customer behaviour is limited. Instead of employing a primarily analytical approach with big upfront market research and business analysis and detailed, frozen requirements, agile product management follows an empirical approach: Gathering customer and user feedback on prototypes and early product increments facilitates inspecting the work results and adapting the product accordingly. The product evolves based on customer and user feedback. This not only saves time and money but it increases the likelihood of developing a great product. - Published: 2010-02-22 - Modified: 2021-12-21 - URL: https://www.romanpichler.com/blog/envisioning-your-product/ - Categories: Product Vision and Strategy - Tags: product discovery, validation Being able to envision what a new product or the next product version should look like and do is essential for getting there. This post discusses creating a vision and product strategy and iteratively validating the strategy to align everyone involved in the development effort and to maximise your chances of creating a successful product. Two Common Mistakes: Big Upfront Research and No Prep Work Being able to envision what a new product or the next product version should look like and do is essential for getting there. Traditionally, organisations tend to carry out extensive upfront market research, product planning, and business analysis activities resulting in a product concept or a market requirements specification. Some fall into the other extreme: They rush into development without having carefully thought about the product’s target market and its value proposition. Neither of these two approaches is desirable. The first one ignores the likelihood of change. It assumes that customer needs and how they are best met can be correctly predicted upfront rather than viewing flux and unpredictability as dominant factors in software development. The latter leaves the team without a common goal making it virtually impossible to understand what it takes to develop a successful product. This post discusses creating a vision and product strategy and iteratively validating the strategy to maximise your chances of creating a successful product. Product Vision and Strategy What's the alternative to the two approaches described above? I find it helpful to keep things simple and focus on two artefacts that should be available before starting development starts: vision and product strategy. A vision describes the purpose of a product, its overarching goal, the positive change it should create. Say we want to develop an app that helps people become more aware of what they eat, then the product vision might be "helping people eat healthily". An effective product strategy describes the path chosen to realise the vision, and it should answer the following questions: Who is going to use the product? Who are its target users?  Is anybody going to buy the product? If so, who are the target customers? Which needs will the product address? What value does the product add? Which problem will it address, or which benefit will it provide? Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel? How does the product compare against existing products, from both competitors and the same company? What are the product’s unique selling points? What is its target price? How will the company make money from selling the product? What are the sources of revenue and what is the business model? Is the product feasible? Can the company develop and offer the product? Strategy Validation After you have created a vision and an initial product strategy, you should systematically identify and address the key risks contained in your strategy in order to maximise the chances of releasing a successful product. A great way to do this is to iteratively test and correct the product strategy following the process shown in the picture below. (The process is based on Eric Ries' work). Start by selecting the biggest risk: the uncertainty that must be addressed now so that you don’t take the product in the wrong direction and experience late failure—that is, figuring out at a late stage that you are building a product that nobody really wants or needs.  For example, the need for your product might not be strong enough, the segment you’ve chosen might not be right, or the technologies might not be feasible. Next, determine how you can best address the risk, for instance, by observing target users, interviewing customers, or employing a minimum viable product (MVP). Carry out the necessary work and collect the relevant feedback or data, preferably together with the development team and other key stakeholders. Then analyse the results and use the newly gained insights to decide if you should pivot, persevere, or stop—if you should stick with your strategy, change it, or no longer pursue your vision—and take the appropriate actions accordingly. Follow this process until no crucial risks are left, you are confident that your strategy is correct, and you have enough evidence to support it—or until you have run out of time and money. Iteratively reworking the product strategy encourages you to carry out just enough market research just in time to avoid too much or too little research. It also suggests a risk-driven approach—addressing the biggest risks first so that you can quickly understand which parts of your strategy are working and which are not, thus avoiding late failure. As you iterate your strategy, you should see its uncertainty decrease; fewer and fewer risks should be... - Published: 2010-02-15 - Modified: 2023-05-09 - URL: https://www.romanpichler.com/blog/refining-the-product-backlog/ - Categories: Product Backlog & User Stories - Tags: product owner, refinement, requirements, scrum, teamwork, user feedback Product backlog refinement, or grooming, plays an important part in delivering a product. Done correctly, it increases the chances of offering a successful product. This article shares my tips to help you effectively refine your product backlog. Why does Product Backlog Refinement Matter? Product backlog refinement, also called product backlog grooming, is the set of activities necessary to make detailed product decisions based on the feedback you have received, update the backlog accordingly, and get it ready for the next sprint. It's an ongoing process, as your product backlog is likely to change based on the learning obtained from developing software and exposing it to customers, users, and other stakeholders, as the image below illustrates. Refining the product backlog helps you capture the latest insights and it ensures that you develop a product with the right user experience and features. It also makes sure that the product backlog is workable, that it is prioritised, and that there are enough ready items to start the next sprint. What does Refinement Entail? Grooming the product backlog consists of the following steps, which are described in more detail in my article "The Product Backlog Refinement Steps": Analyse feedback / data from users, customers, and internal stakeholders. Integrate the learning. Decide what to do next. Refine the items. Get the high-priority items ready for the next sprint. Carrying out the grooming steps should result in a product backlog that is DEEP: detailed appropriately, emergent, estimated, and prioritised. You should also ensure that your backlog is concise and visible for everyone involved in the development effort. A concise product backlog allows to effectively integrate the insights gained. A visible backlog encourages creative conversations. Who should Carry out the Refinement Work? Refining the product backlog should be a collaborative effort that involves the product owner and the cross-functional development team. This allows you to leverage the team's knowledge and creativity, including taking into account technical feasibility and risks; it increases the team's understanding of the product backlog items and generates buy-in for the backlog changes; it reduces your workload as the product owner, and helps ensure that the high-priority items are ready. When should Refinement Take Place? Refinement activities can take place before new development work starts or while it is being carried out, for instance, during the next sprint. If you require user and customer feedback to ensure that you are taking your product in the right direction, then you should first obtain the relevant data, analyse it, and integrate the new insights into the product backlog before you continue coding. You can find out more about the right time to groom you backlog in my post "When should Product Backlog Refinement Take Place? ". Where is the Initial Product Backlog Derived from? You may have noticed that the refinement steps above start with "Analyse the customer and user feedback". This implies that we have already built a first product increment. But how can we bootstrap the process and create the initial product backlog? I like to derive the inaugural backlog from a product roadmap, as the picture below illustrates. The product roadmap describes the journey you want your product to take including major releases, goals, key features, and dates. I discuss the relationship between the product backlog and the product roadmap in more detail in the article "The Product Roadmap and the Product Backlog". How much Time does Refinement Require? To answer this question, it is helpful to take into account the life cycle stage of your product and the sprint duration. The more stable and mature your product is, the lower the refinement effort tends to be in the sprints. The reason for this is that there are less unknowns and risks and you rely less on feedback and experimentation to discover the right requirements. The following picture illustrates this correlation. (I discuss choosing the right level of detail in the product backlog in my article "How Detailed should the Product Backlog be? ". The second factor is the duration of your sprints. I find that a two-week sprint usually requires 2-4 hours of focussed refinement work that involves the Scrum product owner and the development team. Which Tools and Techniques are Helpful? I like to work with my Product Canvas, a structured, multi-dimensional product backlog. The canvas allows me to capture all relevant aspects of a product, which is particularly helpful for new products and for product updates aimed at new markets. A great way to do the refinement work is to organise a product backlog workshop. The workshop involves the Scrum product owner and the development team, and carries out the five steps listed above. - Published: 2010-02-08 - Modified: 2024-11-18 - URL: https://www.romanpichler.com/blog/make-the-product-backlog-deep/ - Categories: Product Backlog & User Stories - Tags: product owner The product backlog is intended to be a simple tool. But in reality, product backlogs are often too long, too detailed, and difficult to use. This post explains how you can avoid this common trap by making your backlog DEEP: Detailed appropriately, estimated, emergent, and prioritised. Going DEEP Imagine your boss telling you: "Congratulations, we’d like to ask you to take on the product owner role for our new product! And we’ve done some upfront work for you: Here is the initial product backlog. " You thank her and walk back to your desk, where you look at the backlog and discover that it contains several hundred items. "That's a big product backlog," you think and "where should I start? " This story illustrates a common challenge: Product backlogs are often too long and detailed, and therefore difficult to use. Part of the solution is to ensure that your product backlog is DEEP: It should be detailed appropriately, estimated, emergent, and prioritized. I find that particularly the first and the third property are often overlooked. Additional, I recommend that you focus the product backlog on the next product goal, as I discuss in my article Product Goals in Scrum. Detailed Appropriately The product backlog items are detailed appropriately if higher-priority items are described in more detail than lower-priority ones. "The lower the priority, the less detail, until you can barely make out the backlog item," write Ken Schwaber and Mike Beedle in their book Agile Software Development with Scrum. Following this guideline keeps the backlog concise and ensures that the items likely to be implemented in the next sprint are ready. Estimated The product backlog items—certainly the ones necessary to meet the product goal selected—should be estimated. The estimates can be coarse-grained and are often expressed in story points or ideal days. Knowing the rough size of the items helps prioritise them and track the progress of the development effort. Let your development team choose the estimation unit they are most comfortable with. If this turns out to be difficult for the, then the Scrum Master should advise. Emergent The product backlog has an organic quality: It evolves and its contents change frequently. New items emerge based on the customer and user feedback you receive and are added to the backlog. Existing items are modified, reprioritised, refined, or removed on a regular basis. Prioritised All items in the product backlog are prioritised or ordered. The most important and highest-priority items are implemented first. They can be usually found at the top of the product backlog, as illustrated in the picture above. Once an item is done, it is removed from the product backlog. Note that the Scrum framework does not suggest any prioritisation factors. But I recommend that you first prioritise your product backlog by risk. Once the key risks have been addressed, use cost-benefit and dependencies to determine the order in which the items should be implemented. Regularly Update Your Backlog To ensure that the product backlog is DEEP and stays that way, you have to regularly update and refine it. Refining the product backlog is an ongoing, collaborative process that involves the product owner and team, as I describe in more detail in the post Refining the Product Backlog. To conclude the story from the beginning of this post, my preferred course of action as the designated product owner is to explain to the boss that the product backlog is too detailed and long, which makes it difficult to evolve it based on any user feedback received. This in turn reduces the likelihood of delivering a successful product. The product backlog resembles a disguised requirements specifications, which is a common trap to fall into. My recommendation is to discard the product backlog, create a product roadmap, and derive a new backlog from it that fulfils the DEEP criteria, even if that's not necessarily what the boss might want to hear. - Published: 2010-02-01 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/avoiding-common-product-owner-mistake/ - Categories: Product Roles - Tags: product owner, scrum Applying the product owner role can be challenging. The role has diverse responsibilities, and its application is context-sensitive: it varies depending on the type of product, the product lifecycle stage, and the people involved. This post will help you recognise some of the most common product owner challenges. The Underpowered Product Owner A product with an underpowered product owner is much like a car with an underpowered engine: The car runs, but it struggles when the going gets tough. An underpowered product owner lacks authority. There may be several causes: The product owner does not have enough management attention; the sponsorship comes from the wrong level or the wrong person; management does not fully trust the product owner or finds it difficult to delegate decision-making authority. As a consequence, the product owner struggles to do an effective job, for instance, to align the Scrum team, stakeholders, and customers or to exclude requirements from the release. If you feel that you should increase your product owner power, then take a look at my article Boost Your Product Leadership Power. The Overworked Product Owner Being overworked is not just unhealthy and unsustainable on a personal level; overworked product owners can become bottlenecks and limit the progress their products make. Symptoms of an overworked product owner include neglecting product discovery and strategy work, and product backlog refinement, missing sprint planning or sprint review meetings, and not being available for questions. There are two main causes of product owner overburden: not enough time to perform the role and not enough support from the team. Availability tends to be an issue when the product owner role is just one of many jobs competing for time and attention or when the product owner looks after too many products or teams. Not enough support from the team is rooted in a wrong understanding of product ownership: Even though there is one product owner, most of the product owner work is performed collaboratively. The team and Scrum Master must support the product owner. Scrum allocates up to 10% of the team’s availability in the sprint to work with the product owner, for instance, to break down and refine product backlog items together. The Partial Product Owner Some organisations split the product owner role and distribute its duties across several people, for instance, by employing a product manager and a “product owner. ” The product manager takes care of the product marketing and strategic product management aspects, owns the vision, is outward-facing, and keeps in touch with the market. The “product owner” is inward-facing, drives the sprints, and works with the team. In these cases, the so-called product owner is little more than a product backlog item writer. This approach reinforces old barriers, blurs responsibility and authority, and causes handoffs, delays, and other waste. The Distant Product Owner A distant product owner works separately from the team. This can range from working on the same site in different rooms to product owner and team being separated across continents and time zones. I have found recurring issues with distant product owners, including mistrust, miscommunication, misalignment, and slow progress. There is a reason: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation,” as the Agile Manifesto for Software Development states. You should hence aim to collocate product owner, Scrum Master and team. This can give you a significant productivity and morale increase. If that's not an option, then try to partially collocate people make, for example, by spending the first few sprints together and then working in the same office at least once every three months. Additionally, make sure that you effective use remote working tools like video calls. The Proxy Product Owner A proxy product owner is a person acting as a placeholder for the actual product owner. I have found proxy product owners used to compensate for overworked, partial, and distant product owners. For instance, a business analyst who does most of the product backlog grooming work and answers questions from the team on a daily basis is a proxy for the actual product owner who decides the product backlog prioritisation and accepts or rejects work results at the en of the sprint. Using a proxy product owner is an attempt to superficially treat a systemic issue. Rather than employing a quick fix, you should address the underlying issues. The Product Owner Committee A product owner committee is a group of product owners without anyone in charge of the overall product. There is no one person guiding the group, helping to create a common goal, and facilitating decision making. A product owner committee is in danger of getting caught in endless meetings with conflicting interests and politics—something also referred to as “death by committee. ” Always ensure that there... - Published: 2010-01-18 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/blog/demystifying-the-product-owner-role/ - Categories: Product Roles - Tags: product owner, teamwork The product owner role in Scrum has attracted plenty of interest and controversy. Some people believe it rebrands the traditional product manager. Others think it is a team lead or Scrum’s take on the project manager role. And some say the product owner is a helper role, a product backlog item writer so to speak. None of theses views is true. But each has some truth in it. This post attempts to demystify this important role. The Role Defined Let’s have a look at what Ken Schwaber, the co-founder of Scrum, writes about the product owner in the Scrum Guide (May 2009 edition) : The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the team performs. This person maintains the Product Backlog and ensures that it is visible to everyone. This definition sounds rather harmless until we consider its implications. It requires the product owner to lead product discovery, to help identify and describe requirements, and to ensure that the product backlog is ready for the next sprint planning meeting. It also means that the product owner has to engage in product planning, visioning and product road mapping, decides what goes into a release, carries out release planning, provides feedback to the team and reviews work results, and manages customers, users and other stakeholders. And Ken Schwaber recommends in his book Agile Project Management with Scrum on p. 18: The Product Owner’s focus is on return on investment (ROI). If we take this advice seriously, then product owners will have to look after products over an extended period of time – at least until ROI can be determined – if not after the product’s entire lifecycle. Having one person in charge from bringing a new product to life to discontinuing the product also creates continuity and eliminates wasteful handoffs. A Complex, Multi-faceted Role The different responsibilities make the product owner a challenging and multi-faceted role that shares some of the responsibilities traditionally attributed to a product marketer, product manager and project manager. The specific shape of the role is context-sensitive: It depends on the nature of the product, the stage of the product lifecycle, and the size of the project, among other factors. For example, the product owner responsible for a new product consisting of software, hardware, and mechanics will need different competencies than someone who is leading the effort to enhance a web application. Similarly, a product owner working with a large Scrum project will require different skills than one collaborating with only one or two teams. Filling the Role Who should play the product owner role? For commercial products, the product owner is typically a product manager or marketer. An actual customer tends to assume the role when a bespoke product is being developed, for instance, an external client who requires a new data warehouse solution or an internal client (e. g. , the marketing department) asking for a web site update. I have worked with customers, users, business line managers, product managers, project managers, business analysts, and architects who filled the product owner role well in the given circumstances. Even CEOs can make great product owners. No Solo Act but Teamwork Being the product owner is no solo act. The product owner is part of the Scrum team and closely collaborates with its other members. While the ScrumMaster and team support the product owner by jointly grooming the product backlog, the product owner is responsible for making sure that the necessary work is carried out. The product owner needs the support from the other Scrum team members. Otherwise, the individual will end up being overworked and will miss out on the knowledge, creativity, and experience of the ScrumMaster and the team. ## FAQs - Published: 2024-02-19 - Modified: 2024-02-19 - URL: https://www.romanpichler.com/blog/ufaqs/how-long-have-you-been-teaching/ - FAQ Categories: Training Roman started teaching his Product Strategy and Roadmap course as a public workshop in 2014 and his Product Leadership training in 2016. Both courses have significantly changed over the years, and Roman regularly updates the training materials and exercises to incorporate his latest insights. - Published: 2023-02-21 - Modified: 2024-03-14 - URL: https://www.romanpichler.com/blog/ufaqs/company-specific-training/ - FAQ Categories: Training Yes, Roman offers company-specific training. If you are interested in having Roman teach one of his training courses for your organisation, please get in touch. - Published: 2021-06-03 - Modified: 2021-06-03 - URL: https://www.romanpichler.com/blog/ufaqs/can-i-pass-on-my-ticket-to-someone-else/ - FAQ Categories: Tickets & Payment You can transfer your ticket to another person if you notify us by email no later than 14 days before the start of the course. If you would like to pass on your ticket to someone else, please contact us. - Published: 2021-03-15 - Modified: 2021-03-16 - URL: https://www.romanpichler.com/ufaqs/will-i-get-a-place-when-i-am-on-the-waitlist/ - FAQ Categories: Training When you have joined the waitlist of one of our courses, we will email you as soon as we receive a cancellation, along with everyone else on the list. We then offer the place on a first come, first served basis. It is unfortunately hard to know if and when someone will cancel. But if you sign up for the next available course, we will rebook you free of charge if we can offer you a place on the fully booked one. If you would like to join a waitlist, please get in touch and tell us which course you are interested in. - Published: 2021-03-11 - Modified: 2021-03-16 - URL: https://www.romanpichler.com/ufaqs/can-i-purchase-a-voucher/ - FAQ Categories: Tickets & Payment Yes, you can buy a voucher to attend Roman's training courses. Please contact us and tell us which training course(s) you are interested in and how many places you need. - Published: 2021-03-02 - Modified: 2025-01-06 - URL: https://www.romanpichler.com/blog/ufaqs/do-you-offer-a-discount/ - FAQ Categories: Tickets & Payment We offer the following discounts on the regular ticket price: Group: 15% discount when three or more tickets are purchased together. Startup: up to 50% discount for early-stage startups (no older than two years and no more than 20 employees). Charity: up to 50% discount for registered charities that directly improve people's lives or the environment/the planet. Hardship: up to 50% discount for anybody who is unemployed or experiences financial difficulties. If you would like to request a discount or if you have any discount-related questions, then please get in touch. - Published: 2021-03-02 - Modified: 2021-03-16 - URL: https://www.romanpichler.com/ufaqs/can-i-change-to-another-class/ - FAQ Categories: Tickets & Payment You can transfer your booking to the same course on an alternative date if you notify us by email no later than 14 days before the start of the course. To change your booking, please contact us. - Published: 2021-03-02 - Modified: 2024-08-12 - URL: https://www.romanpichler.com/blog/ufaqs/how-big-are-romans-classes/ - FAQ Categories: Training Roman's online classes are limited to a maximum of 15 attendees for his product leadership training and to a maximum of 20 participants for his product strategy and roadmap course. This ensures that they are small enough to answer specific questions and big enough to have a sufficiently diverse group and engaging discussions. - Published: 2021-02-18 - Modified: 2024-03-14 - URL: https://www.romanpichler.com/blog/ufaqs/what-is-romans-online-training-like/ - FAQ Categories: Training Roman's online training is live, interactive, friendly, and engaging. Think of it as an instructor-led remote workshop with the appropriate mixture of lectures, group and individual exercises, and Q&As so that you can get your questions answered by Roman. Additionally, you'll be able to try out the techniques and tools covered and apply them to your own products in the form of hands-on exercises. The training contents are developed and exclusively used by Roman, and he teaches all classes himself. But see for yourself: https://www. youtube. com/watch? v=KWk3UJ7vSrM Here is what the attendees say: The online delivery of the course was excellent. I was concerned that it may not quite give the same interaction with the trainer as classroom-based training, but it absolutely did. Roman used the online tools extremely well. Tom Brian, Product Owner at Petrofac Kudos to Roman for delivering a fantastic, engaging, and interactive online training course. Nhung Nguyen, Product Manager at Eurail & Interrail We got the same out of the online training as if we had been all in the same room. I really like Roman’s on-the-fly PowerPoint presentation. Kristina Underwood, Product Owner at HiHi - Published: 2021-02-18 - Modified: 2024-03-14 - URL: https://www.romanpichler.com/blog/ufaqs/can-i-pay-by-invoice/ - FAQ Categories: Tickets & Payment Yes, you can pay by invoice if payment by credit card and PayPal is not an option for you. To do so, please contact us and tell us which course you want to attend and how many places you want to book. Please note that a place is guaranteed when the invoice has been settled, and the attendee has registered for the course using the code we will provide. Additionally, we may have to add a small surcharge for payments by invoice, as these significantly increase our overhead. - Published: 2021-02-18 - Modified: 2024-03-14 - URL: https://www.romanpichler.com/blog/ufaqs/how-many-people-from-the-same-company-can-attend/ - FAQ Categories: Training We limit the number of employees from the same company to four attendees per course. This ensures a balanced class, and it avoids specific challenges of one company dominating the discussions. - Published: 2021-02-18 - Modified: 2025-03-03 - URL: https://www.romanpichler.com/ufaqs/can-i-cancel-my-ticket-and-get-a-refund/ - FAQ Categories: Tickets & Payment If we receive your notification at least 14 days before the start of the course and if we are able to rebook your place, we will offer you a full refund for a training course ticket. Please contact us if you want to cancel your ticket or if have any questions or concerns about your booking. - Published: 2021-02-18 - Modified: 2024-05-02 - URL: https://www.romanpichler.com/ufaqs/which-tools-do-i-need-to-be-able-to-attend-online-training/ - FAQ Categories: Training You will need a computer with a webcam and a microphone, preferably a device with a large enough screen, like a laptop or tablet, and a stable Internet connection. Additionally, you will have to be able to use Zoom, Miro, and Google Docs. This includes the following: Join a Zoom meeting, use the chat, mute and unmute yourself, and use reactions. Add cards to a Miro board and edit them. Access a shared Google doc, save a new version, edit it, and share it with Roman. - Published: 2021-02-18 - Modified: 2024-03-14 - URL: https://www.romanpichler.com/ufaqs/why-do-i-need-to-do-some-prep-work/ - FAQ Categories: Training Carrying out the recommended prep work will help you reflect on your understanding of the subjects covered and familiarise yourself with Roman's teachings. This will make it easier for you to participate in the exercises, and it will give you a better learning experience. You can find the prep work on the individual training course pages. - Published: 2021-02-18 - Modified: 2024-03-14 - URL: https://www.romanpichler.com/ufaqs/will-i-get-a-copy-of-the-presentation-used-in-class/ - FAQ Categories: Training You will receive a PDF document that contains the slides Roman shows in class, screenshots of all the artefacts created in the group exercises, as well as references and links to books and articles. We share the document after the course has taken place, usually on the next day. ## YouTube Videos ## Events - Published: 2026-03-02 - Modified: 2026-05-13 - URL: https://www.romanpichler.com/event/product-leadership-workshop-5/ - Event Categories: Product Leadership Succeed in Leading Stakeholders and Product Teams - Published: 2026-03-02 - Modified: 2026-05-13 - URL: https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-january-2026-2-2/ - Event Categories: Product Strategy and Product Roadmap Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - Published: 2025-12-12 - Modified: 2026-03-02 - URL: https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-january-2026-2-2/ - Event Categories: Product Strategy and Product Roadmap Learn how to Create a Winning Product Strategy. - Published: 2025-10-06 - Modified: 2026-05-13 - URL: https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-january-2026-2/ - Event Categories: Product Strategy and Product Roadmap Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - Published: 2025-07-14 - Modified: 2025-12-12 - URL: https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-january-2026/ - Event Categories: Product Strategy and Product Roadmap Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - Published: 2025-03-17 - Modified: 2025-10-14 - URL: https://www.romanpichler.com/event/product-leadership-training-july-2025-2/ - Event Categories: Product Leadership Succeed in Leading Stakeholders and Product Teams Achieving product success is not possible without strong leadership: You have to secure the stakeholders' support, guide other product people, and lead development teams without having the authority to tell the individuals what to do. This training course will teach you how to effectively lead others and be an inspiring and inclusive leader. You will learn proven leadership techniques that you can immediately apply to secure stronger buy-in and achieve greater alignment. The training is ideally suited for product professionals who want to take on a senior product role, lead a group of product people, and get better at managing challenging senior stakeholders. Roman teaches this course as instructor-led workshop with a mix of lectures, discussions, hands-on exercises, and plenty of Q&A. You can find out more about Roman's online training by visiting the Training FAQs on his website including a video that shows him teaching online. Find out more at: https://www. romanpichler. com/training-courses/product-leadership/ - Published: 2025-03-17 - Modified: 2025-03-17 - URL: https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-14-2-2-2-2-2-2-2-2/ - Event Categories: Product Strategy and Product Roadmap Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - Published: 2024-12-06 - Modified: 2025-06-04 - URL: https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-14-2-2-2-2-2-2-2/ - Event Categories: Product Strategy and Product Roadmap Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - Published: 2024-11-25 - Modified: 2025-06-16 - URL: https://www.romanpichler.com/event/product-leadership-training-july-2025/ - Event Categories: Product Leadership Succeed in Leading Stakeholders and Product Teams Achieving product success is not possible without strong leadership: You have to secure the stakeholders' support, guide other product people, and lead development teams without having the authority to tell the individuals what to do. This training course will teach you how to effectively lead others and be an inspiring and inclusive leader. You will learn proven leadership techniques that you can immediately apply to secure stronger buy-in and achieve greater alignment. The training is ideally suited for product professionals who want to take on a senior product role, lead a group of product people, and get better at managing challenging senior stakeholders. Roman teaches this course as instructor-led workshop with a mix of lectures, discussions, hands-on exercises, and plenty of Q&A. You can find out more about Roman's online training by visiting the Training FAQs on his website including a video that shows him teaching online. Find out more at: https://www. romanpichler. com/training-courses/product-leadership/ - Published: 2024-10-07 - Modified: 2025-02-04 - URL: https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-14-2-2-2-2-2-2/ - Event Categories: Product Strategy and Product Roadmap Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - Published: 2024-08-21 - Modified: 2025-01-13 - URL: https://www.romanpichler.com/event/product-leadership-training-5-2-2-2/ - Event Categories: Product Leadership Succeed in Leading Stakeholders and Product Teams Achieving product success is not possible without strong leadership: You have to secure the stakeholders' support, guide other product people, and lead development teams without having the authority to tell the individuals what to do. This training course will teach you how to effectively lead others and be an inspiring and inclusive leader. You will learn proven leadership techniques that you can immediately apply to secure stronger buy-in and achieve greater alignment. The training is ideally suited for product professionals who want to take on a senior product role, lead a group of product people, and get better at managing challenging senior stakeholders. Roman teaches this course as instructor-led workshop with a mix of lectures, discussions, hands-on exercises, and plenty of Q&A. You can find out more about Roman's online training by visiting the Training FAQs on his website including a video that shows him teaching online. Find out more at: https://www. romanpichler. com/training-courses/product-leadership/ - Published: 2024-04-30 - Modified: 2024-12-10 - URL: https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-14-2-2-2-2-2/ - Event Categories: Product Strategy and Product Roadmap Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - Published: 2024-01-22 - Modified: 2024-05-24 - URL: https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-14-2-2-2-2/ - Event Categories: Product Strategy and Product Roadmap Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - Published: 2024-01-22 - Modified: 2024-09-05 - URL: https://www.romanpichler.com/event/product-leadership-training-5-2-2/ - Event Categories: Product Leadership Succeed in Leading Stakeholders and Product Teams Achieving product success is not possible without strong leadership: You have to secure the stakeholders' support, guide other product people, and lead development teams without having the authority to tell the individuals what to do. This training course will teach you how to effectively lead others and be an inspiring and inclusive leader. You will learn proven leadership techniques that you can immediately apply to secure stronger buy-in and achieve greater alignment. The training is ideally suited for product professionals who want to take on a senior product role, lead a group of product people, and get better at managing challenging senior stakeholders. Roman teaches this course as instructor-led workshop with a mix of lectures, discussions, hands-on exercises, and plenty of Q&A. You can find out more about Roman's online training by visiting the Training FAQs on his website including a video that shows him teaching online. Find out more at: https://www. romanpichler. com/training-courses/product-leadership/ - Published: 2023-11-22 - Modified: 2024-04-17 - URL: https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-14-2-2-2/ - Event Categories: Product Strategy and Product Roadmap Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. - Published: 2023-11-02 - Modified: 2023-11-02 - URL: https://www.romanpichler.com/event/product-leadership-training-5-2/ - Event Categories: Product Leadership Succeed in Leading Stakeholders and Product Teams Achieving product success is not possible without strong leadership: You have to secure the stakeholders' support, guide other product people, and lead development teams without having the authority to tell the individuals what to do. This training course will teach you how to effectively lead others and be an inspiring and inclusive leader. You will learn proven leadership techniques that you can immediately apply to secure stronger buy-in and achieve greater alignment. The training is ideally suited for product professionals who want to take on a senior product role, lead a group of product people, and get better at managing challenging senior stakeholders. Roman teaches this course as instructor-led workshop with a mix of lectures, discussions, hands-on exercises, and plenty of Q&A. You can find out more about Roman's online training by visiting the Training FAQs on his website including a video that shows him teaching online. Find out more at: https://www. romanpichler. com/training-courses/product-leadership/ - Published: 2023-09-21 - Modified: 2024-01-15 - URL: https://www.romanpichler.com/event/product-strategy-and-product-roadmap-training-14-2/ - Event Categories: Product Strategy and Product Roadmap Learn how to Create a Winning Product Strategy and a Compelling Product Roadmap. ## Episode - Published: 2026-07-13 - Modified: 2026-07-13 - URL: https://www.romanpichler.com/podcast/how-to-create-a-truly-inspiring-product-vision/ - Tags: ai, alignment, emotion, product vision board - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast “If you are working on something exciting that you really care about, you don’t have to be pushed. The vision pulls you,” Steve Jobs once said. Creating such a forward momentum is a key benefit that a product vision should offer. Unfortunately, I’ve seen many visions that failed to move people. In this episode, I explain how you can create a truly inspirational vision that engages and motivates people. Related episodes: The Product Strategy Framework: A Revised Guide for Product Leaders 5 Product Vision Mistakes You Should Avoid Double Vision: Choosing the Right Approach to Capture the Product Vision Six Qualities of a Great Product Vision Six Qualities of a Great Product Vision - Published: 2026-06-08 - Modified: 2026-06-26 - URL: https://www.romanpichler.com/podcast/emotional-intelligence-in-product-management/ - Tags: ai, conflict, emotion, empathy, self-leadership, stakeholders, teamwork, trust - Topic: Product Leadership - Podcasts: Roman's Product Management Podcast As product management becomes increasingly data-driven and AI-powered, one human capability is growing in importance: emotional intelligence. In this episode, you'll discover why emotional intelligence is a critical complement to data, analytics, and AI, how it helps product managers and product leaders create better products and build stronger relationships, and why it may have a greater impact on product success than intellectual ability alone. You'll also learn practical techniques for strengthening your emotional intelligence—from increasing self-awareness and self-management to developing empathy, active listening, and conflict-resolution skills. Related episodes: How to Leverage Conflict in Product Management Empathy in Product Management Dealing with Difficult Emotions in Product Management - Published: 2026-05-11 - Modified: 2026-05-11 - URL: https://www.romanpichler.com/podcast/romans-product-strategy-framework-v3/ - Tags: empowerment, GO product roadmap, product team, product vision board, stakeholders, validation - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast One of the biggest mistakes I see product managers make is making decisions in isolation: Deciding on strategy without considering how it impacts product discovery and delivery, or determining UX and features without letting strategy guide those choices. Great products, however, aren’t built by separating strategy from execution. They’re created by connecting them. That’s exactly why I developed my product strategy model—a simple but powerful way to link product vision, strategy, roadmap, and backlog. This episode describes the framework in its latest, revised version. Related episodes: Product Strategy Discovery How to Get Started with Outcome-Based Product Roadmaps Continuous Strategizing Related articles: Product Vision Board GO Product Roadmap Download the Product Vision BoardDownload the GO Product Roadmap - Published: 2026-03-09 - Modified: 2026-03-09 - URL: https://www.romanpichler.com/podcast/get-the-outcomes-on-your-product-roadmap-right/ - Tags: ai, GO product roadmap, KPIs, product goal, product manager, stakeholders, sustainable pace - Topic: Product Roadmap - Podcasts: Roman's Product Management Podcast Product outcomes define the specific value a product creates—for users, customers, and the business. When applied correctly, they align stakeholders, create focus, and give development teams clear direction. But getting them right isn’t easy. Too often, product teams choose outcomes that are vague, oversized, or worse, features dressed up as goals. The result? Confusion, misalignment, and roadmaps that look strategic but fail to drive meaningful impact. In this podcast episode, I’ll address these issues and provide practical advice to help you define the right outcomes that help you achieve product success. Related episodes: How to Get Started with Outcome-Based Product Roadmaps Continuous Strategizing Maximising Stakeholder Buy-in to Product Strategy and Product Roadmap Download the GO Product Roadmap Learn more about working with the GO Product Roadmap - Published: 2026-02-02 - Modified: 2026-02-02 - URL: https://www.romanpichler.com/podcast/succeeding-with-the-product-operating-model/ - Tags: ai, business strategy, empowerment, GO product roadmap, product discovery, product manager, product vision board, stakeholders, strategy stack, sustainable pace - Topic: Product Leadership - Podcasts: Roman's Product Management Podcast In this episode, I explain how you can successfully implement the product operating model—based on my experience of helping companies introduce and improve a product-led way of working over the past 15 years. Related Episodes: What Should the Head of Product Do? Should Stakeholders be on the Product Team? Setting up Product Teams for Success Everything You Need to Know About Product Portfolio Strategy Succeeding with Portfolio Roadmaps Featured Tools: Product Vision Board GO Product Roadmap Goal-Setting Framework Strategy Stack - Published: 2026-01-12 - Modified: 2026-01-13 - URL: https://www.romanpichler.com/podcast/how-to-create-a-product-strategy-for-an-existing-product/ - Tags: ai, business model, GO product roadmap, product goal, product vision board, stakeholders, validation - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast Every product has a strategy. But not all product strategies are clearly articulated, let alone communicated and understood. This can lead to confusion and misalignment: Different people have different ideas about what the actual strategy is and disagree on which features should be implemented. But it doesn’t have to be this way. In this episode, I describe a clear, five-step process that helps you build an effective strategy for an existing product and create clarity and alignment. Related episodes: Product Strategy Discovery Continuous Strategizing How to Get Started with Outcome-Based Product Roadmaps Download the Product Vision Board. Download the GO Product Roadmap. - Published: 2025-12-08 - Modified: 2025-12-08 - URL: https://www.romanpichler.com/podcast/self-managing-product-teams/ - Tags: empowerment, product team, product vision board, self-organisation, stakeholders, teamwork - Topic: Product Leadership, Product Roles - Podcasts: Roman's Product Management Podcast Product teams play a key role in solving user problems and achieving product success. But who should lead the team and manage its work? The Head of Product, the product manager, or someone else? In this episode, I explain why product teams should be self-managing. I describe the benefits this approach offers and what it takes to succeed at self-management. Related episodes: Setting up Product Teams for Success Should Stakeholders Be on the Product Team? Strategy and Product Teams Decoding Product Leadership - Published: 2025-11-03 - Modified: 2025-11-03 - URL: https://www.romanpichler.com/podcast/how-to-use-ai-to-create-a-product-strategy/ - Tags: ai, product discovery, product vision board, validation - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast AI has significantly impacted product management. But so far, most product teams have used it to create new features and discover and deliver products faster. While helpful, this approach overlooks the area that most determines product success: strategy. In this episode, I’ll explain how to move beyond execution and use AI as a strategic partner—helping you create a product strategy that achieves lasting success. Related episodes: Product Strategy Discovery Continuous Strategizing AI and Product Strategy Product Strategy as a System - Published: 2025-10-06 - Modified: 2025-10-06 - URL: https://www.romanpichler.com/podcast/stakeholder-management-tips/ - Tags: decision-making, empathy, product goal, product vision board, sprint goal, stakeholders - Topic: Product Leadership - Podcasts: Roman's Product Management Podcast Stakeholder management is as important as it is challenging: Without the support of the stakeholders, it is virtually impossible to achieve product success. Aligning them, however, can be tricky. In the worst case, you experience endless meetings, conflicting opinions, and bad compromises. But it doesn’t have to be this way. In this episode, I share five practical measures to help you succeed with stakeholder management. Related episodes: Should Stakeholders be on the Product Team? How to Leverage Conflict in Product Management Download the Product Vision Board: https://www. romanpichler. com/tools/product-vision-board/ Download the GO Product Roadmap: https://www. romanpichler. com/tools/the-go-product-roadmap/ - Published: 2025-09-08 - Modified: 2025-09-08 - URL: https://www.romanpichler.com/podcast/product-strategy-okrs-and-kpis/ - Tags: KPIs, OKRs, product vision board - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast Product strategy, OKRs, and KPIs are popular product management frameworks. But how can they be applied successfully together? What comes first, strategy, OKRs, or KPIs? Can OKRs describe or replace strategy? And what should you do when a senior stakeholder tells you what OKRs and KPIs to use? Listen to this episode to hear my answers. Listen to this related episode: OKRs and Product Roadmaps Download the Product Vision Board to capture the product strategy. - Published: 2025-07-07 - Modified: 2025-07-07 - URL: https://www.romanpichler.com/podcast/product-vision-mistakes/ - Tags: alignment, emotion, product life cycle, product vision board, stakeholders - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast The product vision can be a powerful vehicle for creating a shared purpose, inspiring people, and galvanising them. Unfortunately, I have seen many visions that did not fulfil their potential, as they suffered from a number of mistakes. In this episode, I discuss five common issues and explain how you can avoid and correct them. Download the Product Vision Board and Checklist here. The acronym BHAG was coined by Jim Collins. - Published: 2025-06-09 - Modified: 2025-06-09 - URL: https://www.romanpichler.com/podcast/strategy-and-product-teams/ - Tags: business strategy, empowerment, portfolio management, product team, product vision board - Topic: Product Leadership, Product Vision and Strategy - Podcasts: Roman's Product Management Podcast Strategy and product teams are both key to achieving product success. But what exactly do we mean by strategy, and to what extent should product teams shape strategic decisions? These are the questions I discuss in this episode. Related episodes: The Strategy Stack Setting up Product Teams for Success Maximising Stakeholder Buy-in to Product Strategy and Product Roadmap Everything You Need to Know about Product Portfolio Strategy Building High-Performing Product Teams Download the Product Vision Board: https://www. romanpichler. com/tools/product-vision-board/ - Published: 2025-04-07 - Modified: 2025-04-07 - URL: https://www.romanpichler.com/podcast/ai-and-product-strategy/ - Tags: decision-making, empathy, ethics, innovation, KPIs - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast AI has significantly impacted software-based products and has started to change how product management is practised. But how is it affecting product strategy? Can AI-powered tools lead to better strategies? Can they even make strategic product decisions on their own? In this episode, I discuss the benefits and limitations of using AI to create a product strategy, as well as the foundations you should put in place to take full advantage of AI tools. Content referred to in the podcast: Roman's Product Strategy Model: https://www. romanpichler. com/podcast/my-product-strategy-model/ Product Strategy Discovery: https://www. romanpichler. com/podcast/product-strategy-discovery/ Product Vision Board: https://www. romanpichler. com/tools/product-vision-board/ GO Product Roadmap: https://www. romanpichler. com/tools/the-go-product-roadmap/ - Published: 2025-03-03 - Modified: 2025-03-03 - URL: https://www.romanpichler.com/podcast/setting-up-product-teams-for-success/ - Tags: empowerment, head of product, product team, teamwork - Topic: Product Leadership, Product Roles - Podcasts: Roman's Product Management Podcast Product teams are key in enabling product-led growth and offering successful products. In this episode, I explain what product teams really need to do a great job and how you can best support the teams you work with. Content mentioned to in the podcast: Design Questionnaire for Product Teams: https://www. romanpichler. com/downloads/tools/Team-Design-Questionnaire. pdf Building High-Performing Teams: https://www. romanpichler. com/podcast/building-high-performing-product-teams/ Decoding Product Leadership: https://www. romanpichler. com/podcast/decoding-product-leadership/ Hackman’s book Collaborative Intelligence. - Published: 2025-02-07 - Modified: 2025-02-08 - URL: https://www.romanpichler.com/podcast/product-portfolio-roadmap/ - Tags: GO Portfolio Roadmap, GO product roadmap, OKRs, planning, portfolio management, portfolio team - Topic: Product Roadmap - Podcasts: Roman's Product Management Podcast As helpful as they can be, product roadmaps are not always enough. To closely align a group of products and ensure that they all move in the same direction, you’ll benefit from a portfolio roadmap. In this episode, I explain what a product portfolio roadmap is. I share a template to help you build your own outcome-based portfolio roadmap. I show how you can connect your portfolio roadmap to the portfolio strategy and use it to direct the product roadmaps, and I describe who should be involved in developing the plan. Content referred to in the podcast: Sample GO Product Portfolio Roadmap: https://www. romanpichler. com/podcast/product-strategy-system/ GO Product Roadmap template: https://www. romanpichler. com/tools/the-go-product-roadmap/ GO Product Roadmap Introduction: https://youtu. be/NBNsnKPbah0 Everything You Need to Know about Product Portfolio Strategy: https://www. romanpichler. com/podcast/product-portfolio-strategy/ - Published: 2025-01-20 - Modified: 2025-01-20 - URL: https://www.romanpichler.com/podcast/product-strategy-system/ - Tags: GO product roadmap, product team, product vision board, stakeholders, validation - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast When it comes to product strategy, people often focus on templates, tools, and frameworks. While these matter, they are only a small part of what’s needed to develop a successful strategy. In this episode, I take a holistic approach and discuss product strategy from a system perspective. I consider people, processes, and principles in addition to tools, I share the strategy system I have developed and explain how you can take advantage of it. Downloads: The Product Strategy System The official Product Vision Board The Product Strategy Stack Episodes referred to in the podcast: Product Strategy Discovery Continuous Strategizing The Strategy Stack - Published: 2024-11-11 - Modified: 2024-11-11 - URL: https://www.romanpichler.com/podcast/product-strategy-and-product-life-cycle/ - Tags: product life cycle, product vision board, validation - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast Developing a winning product strategy is hard. Keeping the strategy relevant and achieving product success on a continued basis is even harder. In this episode, I discuss how you can use the product lifecycle model to address this challenge. I explain how the model can help you make the right strategic choices, focus and evolve the product strategy, and proactively progress and grow the product. Episodes referred to in the podcast: Product Strategy Discovery Continuous Strategizing - Published: 2024-10-07 - Modified: 2024-10-08 - URL: https://www.romanpichler.com/podcast/when-you-should-not-use-a-product-roadmap/ - Tags: empowerment, GO product roadmap, product vision board, stakeholders - Topic: Product Roadmap - Podcasts: Roman's Product Management Podcast The product roadmap is a popular product management tool that communicates how a product is likely to evolve. But despite its popularity, it’s not always applicable. In this podcast episode, I share three scenarios in which using a roadmap is not advisable. I explain why not using a roadmap is the right course of action, what you can do instead to plan ahead, and which steps you can take to get closer to developing a realistic, actionable roadmap. Episodes referred to in the podcast: Product Strategy Discovery How to Get Started with Outcome-Based Product Roadmaps Understanding Empowerment in Product Management - Published: 2024-09-02 - Modified: 2024-09-02 - URL: https://www.romanpichler.com/podcast/product-strategy-discovery/ - Tags: business model, ethics, product discovery, product team, validation - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast The product strategy is probably the most important artefact in product management. But how do you come up with an effective strategy in the first place? How can you minimise the risk of offering an unsuccessful product and instead maximise the chances of achieving success? In this episode, I introduce product strategy discovery as a systematic, disciplined approach to help you develop a winning strategy for your product. Episodes referred to in the podcast: Product Strategy and Product Discovery Building High-Performing Product Teams The Strategy Stack Everything You Need to Know About Product Portfolio Strategy Continuous Strategizing - Published: 2024-08-12 - Modified: 2024-08-12 - URL: https://www.romanpichler.com/podcast/stakeholders-on-the-product-team/ - Tags: product team, Scrum Master, stakeholders, teamwork - Topic: Product Leadership, Product Roles - Podcasts: Roman's Product Management Podcast A product team is a cross-functional group whose members work together to achieve product success. Most people would agree that the person in charge of the product, a UX designer, and one or more developers should be on the team. But if stakeholders should be included, is more contentious. In this podcast episode, I discuss two types of product teams, core and extended ones. I explore the benefits and challenges of using a larger team that includes the key stakeholders, and I share practical tips to make this approach work. Episode referred to in the podcast:Maximising Stakeholder Buy-in to Product Strategy and Product Roadmap - Published: 2024-07-08 - Modified: 2024-07-08 - URL: https://www.romanpichler.com/podcast/stakeholder-buy-in-product-strategy-roadmap/ - Tags: decision-making, stakeholders, teamwork - Topic: Product Leadership, Product Vision and Strategy - Podcasts: Roman's Product Management Podcast The most amazing product strategy and product roadmap are ineffective if the stakeholders don’t support them. Without their buy-in, you’ll struggle to execute the strategy and find it hard to deliver the roadmap. But it doesn’t have to be this way. This podcast episode shares my tips to help you secure strong stakeholder buy-in to strategic product decisions, align people, and achieve product success together. The episodes mentioned in the podcast are:Building High-Performing Product TeamsHow to Offer Constructive Feedback - Published: 2024-03-12 - Modified: 2024-03-12 - URL: https://www.romanpichler.com/podcast/the-strategy-stack/ - Tags: business strategy, empowerment - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast For any business to succeed, it is crucial to make the right strategic decisions. To achieve this, you’ll benefit from using four different types of strategies: business, portfolio, product, and technology strategy. But that’s not enough. You’ll also have to successfully align the plans. To help you address these challenges, I have developed a new framework, the Strategy Stack, which I introduce in this podcast episode. Download the Strategy Stack here: https://www. romanpichler. com/downloads/tools/Romans-Strategy-Stack. pdf - Published: 2023-10-10 - Modified: 2023-10-10 - URL: https://www.romanpichler.com/podcast/go-product-roadmap-checklist/ - Tags: GO product roadmap - Topic: Product Roadmap - Podcasts: Roman's Product Management Podcast The GO Product Roadmap is a simple yet effective tool to help teams create goal-oriented, outcome-based roadmaps. Despite its simplicity, I find that it’s not always correctly applied. To address this challenge, I’ve created a checklist, which I share in this podcast episode and which you can download for free from my website. Download the checklist here: https://www. romanpichler. com/tools/the-go-product-roadmap/ - Published: 2021-07-06 - Modified: 2021-09-16 - URL: https://www.romanpichler.com/podcast/tips-for-becoming-a-head-of-product/ - Tags: conflict, empathy, empowerment, trust - Topic: Product Leadership - Podcasts: Roman's Product Management Podcast Becoming a head of product and managing a group of product people is a significant career step. In this podcast episode, I share my recommendations to help you get ready for the new job and be off to a great start. This podcast episode is based on the article Tips for Becoming a Head of Product. - Published: 2021-06-07 - Modified: 2021-09-16 - URL: https://www.romanpichler.com/podcast/making-effective-product-decisions-tips-for-deciding-with-stakeholders-and-dev-teams/ - Tags: decision-making, empathy, stakeholders, teamwork - Topic: Product Leadership - Podcasts: Roman's Product Management Podcast I am a big fan of making decisions collaboratively, as it leverages the expertise of the stakeholders and dev teams; it creates a shared understanding; and it generates stronger buy-in. But deciding together can be challenging: The most senior stakeholder might try to dictate the decision, the group might shy away from difficult conversations, or people might get stuck in endless debates without knowing how and when a decision will be made. This episode shares eight practical tips to help you avoid these pitfalls and harness the full power of collaborative decision-making. This podcast episode is based on the article Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams. - Published: 2021-05-11 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/podcast/five-product-owner-myths-busted/ - Tags: product manager, product owner, scrum - Topic: Product Roles - Podcasts: Roman's Product Management Podcast The product owner is a role which is often misunderstood and frequently misapplied. In this podcast episode, I address five common product owner misconceptions. I explain why they are wrong and how the role can be effectively implemented. This podcast episode is based on the article Five Product Owner Myths Busted. - Published: 2021-04-13 - Modified: 2021-09-16 - URL: https://www.romanpichler.com/podcast/how-to-choose-the-right-kpis-for-your-product/ - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast A key challenge of working with KPIs is to select the right indicators: There are so many different metrics to choose from including daily active users, net promoter score, and profit, to name just a few. What’s more, senior managers and stakeholders can have strong views on which indicators should be used. This episode helps you select the metrics that really matter and are truly helpful for your product. This podcast episode is based on the article How to Choose the Right KPIs for Your Product. - Published: 2021-03-09 - Modified: 2025-04-22 - URL: https://www.romanpichler.com/podcast/product-goals-in-scrum/ - Topic: Product Management Processes - Podcasts: Roman's Product Management Podcast The 2020 edition of the Scrum Guide introduced a new type of goal, the product goal. This episode shares my recommendations to help you as the person in charge of the product set effective product goals. This podcast episode is based on the article Product Goals in Scrum. - Published: 2021-02-02 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/podcast/how-agile-has-changed-product-management/ - Topic: Product Management Processes - Podcasts: Roman's Product Management Podcast As the Manifesto for Agile Software Development celebrates its 20th anniversary, I take a look at how agile practices have influenced and changed product management. I discuss the benefits that have been achieved and the challenges that still remain. This podcast episode is based on the article "How Agile Has Changed Product Management". - Published: 2021-01-12 - Modified: 2021-09-16 - URL: https://www.romanpichler.com/podcast/5-tips-for-saying-no-to-stakeholders/ - Topic: Product Leadership - Podcasts: Roman's Product Management Podcast Saying no is a firm part of our job as product people: Trying to please everyone and taking on board every idea is hardly a recipe for achieving product success. But saying no can be tough, especially when we are faced with a senior, assertive stakeholder. This episode offers five practical tips to help you say no in the right way. This podcast episode is based on the article "5 Tips for Saying No to Difficult Stakeholders". - Published: 2020-12-01 - Modified: 2021-09-16 - URL: https://www.romanpichler.com/podcast/okrs-in-product-management/ - Tags: sprint goal, stakeholders - Topic: Product Leadership, Product Vision and Strategy - Podcasts: Roman's Product Management Podcast OKRs—objectives and key results—have experienced a renewed popularity in recent years. Consequently, I am regularly asked if and how OKRs can be applied in product management. This episode shares my thoughts. This podcast episode is based on the article "OKRs in Product Management. " - Published: 2020-11-03 - Modified: 2022-01-11 - URL: https://www.romanpichler.com/podcast/the-product-strategy-cycle/ - Tags: product discovery, scrum, teamwork - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast Despite its importance, product strategy is not always effectively practiced. One of the key issues I encounter in my work is that strategy and execution are not aligned but rather disjointed. To address this issue, I have developed an iterative process called the product strategy cycle. The cycle systematically connects strategy and execution so that the former guides the latter and insights gained from the tactical work help evolve the product strategy. In this episode, I explain how you can use the cycle to join up product strategy, product roadmap, KIPs, product backlog, and development work, and I discuss the role stakeholders and development team members play in making effective strategic product decisions. This podcast episode is based on the article "The Product Strategy Cycle". - Published: 2020-09-02 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/podcast/prioritising-a-product-backlog-when-everything-is-important/ - Topic: Product Backlog & User Stories - Podcasts: Roman's Product Management Podcast The product backlog is an essential product management tool: It captures detailed product decisions and directs the work of the development team. The latter requires it to be prioritised or ordered. But how can you prioritise a product backlog when everything seems equally important? In this episode shares my answer. It recommends taking four steps to get to an effective, prioritised product backlog. This podcast episode is based on the article "Prioritising a Product Backlog When Everything is Important". - Published: 2020-03-11 - Modified: 2021-09-16 - URL: https://www.romanpichler.com/podcast/how-to-overcome-6-key-product-leadership-challenges/ - Topic: Product Leadership - Podcasts: Roman's Product Management Podcast Products are developed, provided, and enhanced by people, and effectively leading them is crucial to achieve product success. But leading stakeholders and development teams is hard: It requires product managers and product owners to overcome six leadership challenges. This episode—which is based on my new book “How to Lead in Product Management”—discusses the challenges and offers practical tips for overcoming them. This episode is related to the article "How to Overcome 6 Key Product Leadership Challenges". - Published: 2020-02-14 - Modified: 2021-09-16 - URL: https://www.romanpichler.com/podcast/leveraging-software-platforms/ - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast Software platforms can be powerful tools to grow a product portfolio and create new revenue streams. However, successfully using them can be tricky. This episode shares my tips to help you take advantage of your platform. This podcast episode is based on Roman's article "Leveraging Software Platforms. " - Published: 2020-02-13 - Modified: 2024-02-02 - URL: https://www.romanpichler.com/podcast/10-tips-for-writing-good-user-stories/ - Topic: Product Backlog & User Stories - Podcasts: Roman's Product Management Podcast User stories are probably the most popular agile technique to capture product functionality: Working with user stories is easy. But telling effective stories can be hard. This podcast episode shares ten tips help you create good stories. This podcast episode is based on Roman's article “10 Tips for Writing Good User Stories”. - Published: 2020-02-13 - Modified: 2022-03-07 - URL: https://www.romanpichler.com/podcast/product-manager-vs-product-owner/ - Podcasts: Roman's Product Management Podcast For many years, people have debated what the difference between the product manager and the product owner role is, if the roles can coexist or not, and which one should be used. This podcast episode shares my thoughts on the topic and reflects on the origin of the product owner role. This podcast episode is based on Roman's article "Product Manager vs. Product Owner". - Published: 2020-02-13 - Modified: 2021-09-16 - URL: https://www.romanpichler.com/podcast/elements-of-an-effective-product-strategy/ - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast Creating a successful product requires attention to the details, from getting the user interaction and the visual design right to providing the right functionality and using the right technologies. With so much focus on the nitty-gritty, it’s easy to no longer see the wood for the trees. This is where the product strategy comes in. It helps you manage your product proactively and it prevents you from getting lost in the details. This podcast episode discusses what an effective product strategy is and how it benefits you. This podcast episode is based on Roman's article "Elements of an Effective Product Strategy". - Published: 2020-02-13 - Modified: 2021-09-16 - URL: https://www.romanpichler.com/podcast/tips-for-creating-a-compelling-product-vision/ - Topic: Product Vision and Strategy - Podcasts: Roman's Product Management Podcast Creating and managing a successful product requires a lot of time and energy. In order to be fully committed, you have to be convinced that what you are doing is right and have a clear vision of where to take your product. This episode shares eight tips to help you create a compelling product vision that inspires the development team and the stakeholders. This podcast episode is based on Roman's article “Tips for Creating A Compelling Product Vision”.