Product Ownership

The basics of story mapping and how to scope a minimum viable product.

Story mapping is the part of the complex product management process where define what the problem is and why it exists. In this article, Christian Strunk shares how he used to create story maps and how he teaching others to execute them these days. You will learn the basics, and three levels of a user story map, along with how to build it in with a lean-agile mentality.

The whole point of the user story could be just to trigger a useful discussion.

In an interesting thought process, Daniel Pokrývka breaks down the user story artifact into its elements to identify the essential parts which can be captured. Then, in an attempt to generate a meta-template, priority is given to the value and motivation, then to the usage and user contexts, and finally to the problem. This results in a value story template, or a different approach to understanding user stories.

Understanding the what and the why of User Stories from a talk that is still one of the best explanations of it out there.

The video features Mike Cohn at the Norwegian Developers Conference making arguably one of the best User stories explanations ever. Mike believes that User stories are a requirement technique as they point you to the desired requirement when developing projects. He further explains that they help create a mutual connection between the business and the developers by obliterating problems like imbalance of power, imperfect schedules, and scarcity of resources. Delve into this video conference to learn more about User stories and how Mike explains them using Ron Jeffries's three Cs - Card, Conversation, and Confirmation.

An explanation of what agile requirements are, to help you writing and using user stories.

Agile requirements evolve through the lifetime of a product, since it is not possible to know all of them at inception. In this article, Alex Gray outlines what they are, how they are written and handled for emergent designs. He add tips for writing user stories, it's format and how to know if they are ready for development. You will learn how to outline your requirements in a clear, efficient and effective way.

Writing good user stories is harder than it sounds.

User Stories have the familiar format: "As a 'user' I want to 'perform an action' so I can 'achieve an end result'". This format is so to help product, design, and engineering folks in taking a user-centered approach to design. Janet Taylor proposes that simply relying in this format is not enough, as it is easily misunderstood and misused. The purpose of user stories is to create empathy, and she tells you what to do instead.

Nudging our definitions of stories towards less social complexity and/or less technical complexity.

A brief description of why project stakeholders should forgo the traditional method of estimating stories while the project is young as it leads to making commitments that later prove costly and a suggestion of the best way to about this for the project to thrive. We learn that when a project is young do not make estimates of the work but rather slice the work by understanding its complexity. Read the article to find out about how to simplify meetings, order stories to asses risks, and more.

Discussing the expected behavior of a product to prepare a development increment.

User Stories, the description of the next feature increment, are often best seen as a placeholder for a conversation. This conversation should take into consideration all the needed perspectives in order to make informed decisions, contrasting business, technical and quality issues as it progresses. Kent McDonald shares concepts from Behavior-Driven Development BDD to shed a light on what, when and who should be included.

Learn how a team was able to heal a small part of the business/development divide by listening to users and delivering small incremental work.

Incremental delivery is a concept where value is delivered in stages instead of as a single increment. Steve Kuo shares a real life example as to the difference this approach makes, and how it can improve trust and engagement of the end users. By delivering features that the users leveraged every day, small ideas became big improvements and change became intuitive. A very relatable example of how to evolve simple solutions by increments.

A Shared Understanding of value (and its boundaries) is hard, but great teams figure out how to keep their mental model accurate.

User stories are an Agile technique of defining product functionality and requirements.

Acronyms to help us create and remind us of the good characteristics of stories and project tasks.

Bill Wake notes that good user stories act like a pidgin language by simplifying a system for the customers to collaborate with the developers and work together towards the ultimate software goal. However, which characteristics define a good user story and the effectiveness of the tasks within the user story? The author explains the characteristics of the acronym INVEST and SMART in detail here citing how XP teams should use them to create a good software user story with effective tasks.

A technique for splitting user stories that helps teams view things from their comfort zone.

Learn how to use a technique to split user stories into smaller stories that help teams to visualise business workflows from different perspectives. It details six key steps of applying the User Story Hamburger that helps inexperienced teams break down stories into smaller tasks that still deliver incremental business value. The Hamburger method works well to teams that insist on breaking down a story into technical workflow or component tasks by helping them embrace division of stories into more achievable steps.

The definitive guide to splitting features & stories, including the latest versions of Richard Lawrence's popular story splitting flowchart.

The article outlines a definitive guide to splitting features & stories, including the latest versions of Richard Lawrence's popular story splitting flowchart. It gives us an in-depth understanding of user stories and why splitting them matters. Within the context, it details that splitting user stories into smaller valuable/manageable pieces allows teams to get high-quality feedback from the user's perspective. Read this guide to learn more about splitting user stories, attributes of good user stories, and how to compare them to vertical slides.

How to use vertical user story slicing as part of software development and agile scrum adoption.

Kim Poremski narrates how she worked with a Product Owner to improve efficiency in a team's backlog that relied on horizontally structured user stories by transforming them into vertical slices. Together, they defined vertically sliced features and stories that allowed the team to demonstrate incremental progress and achieve better outcomes. She adds that horizontal stories do not meet a well-informed story structure of role, functionality, and outcome as well as the INVEST criteria.

Using a combination of three roadmap practices

Product roadmaps are a great way to track progress, manage expectations, keep people informed and aligned, while fostering transparency. But often the roadmap gets overloaded with features instead of focusing on a high-level, strategic plan for the products' future development. Robbin Schuurman presents three different roadmap practices, with the pros and cons of each, and how to mix them together depending on your needs.

A 1 day product ownership course compressed into 15 minute animated presentation.

Quite simply, one of the best videos on Agile. Henrik Kniberg is able to condense an entire day course into a 15 minute well done primer on the agile role and responsibilities of a Product Owner. It summarizes the key points of agile software development, providing an excellent overview covering stories, prioritization, planning and scaling. A timeless video that should be watched by everyone in the agile world.

Looking at what it means to bring a focused, valuable Minimum Viable Product (MVP) to market.

All too often, products are brought to market with a feature-first approach. A list of functions that are needed to meet business goals such as sign-ups or downloads, views or shares. There’s little thought that’s gone into who the user of the product will be, what their goals are, and what it will take to provide meaningful value to them. We’ll look at what it means to bring a focused, valuable Minimum Viable Product (MVP) to market. An MVP that can help you learn how to better serve your users, and the business that’s footing the bill.

Epics have taken on a variety of meanings in software development.

Writing a definition for epic isn’t nearly as simple as it should be. The term "epic" has taken on multiple meanings as it is used in different environments, and when it comes to dealing with the team's backlog those disparate meanings can cause quite a bit of confusion. Kent McDonald shares what he sees as the most common interpretations of epics, and what he has found to be the best way to deal with the misunderstandings.

A complete guide to User Stories and how to use them to drive thoughtful, collaborative, adaptive product development.

This article will show you how to create better user stories. You’ll learn how to write them like a designer, test them like an entrepreneur, and use them to drive better discussions like an agile coach.

How managing by outcomes impacts your prescriptive, feature-centric product roadmap and what you can do about it.

The article delves into what really happens after shifting your team to leverage OKRs for organizational goals. It states that if the team doesn't know how to do continuous learning, the deployment might not be a success. Thus it suggests that project leaders should consider training the team on product discovery when implementing ORKs. Read the text to find out more about what is product discovery and why teams should be taught how to go about it, and some of the steps that a team should take when OKRs have been confirmed.

Understanding what done means in Scrum and how your (DoD) Definition of Done determines the quality of your final product.

The Definition of Done is one of the most important concepts in Scrum. In this article Daria Bagina helps us understand what done means in Scrum, what a done product really is, and explains how your Definition of Done (DoD), greatly influences the quality of your final product as a team or organization. This article goes into detail on how to create your Definition of Done, how to use is as a guide, and motivates you to review your own DoD practices.

Visualizations to help you understand & communicate key product mgt. ideas.

Through the use of graphical visualizations, Curtis Stanier identifies 6 common product management conceptual mistakes. The usage of visuals is surprisingly helpful in understanding what the issues actually are, and a hint of how to properly apply the concept is given for each of the 6 themes.

Four lessons to move away from stakeholder management to stakeholder inclusion.

How to identify if developers are "just sitting in the factory, cranking out features, and sending them down the line".

I often wonder if I should have been fired for it

Shape your product to market needs.

One of the greatest challenges in creating and managing a product is creating a balanced picture of everything that must be done to be successful. The problem can be complicated by overly linear, inorganic representations of product road maps, which tend to represent product evolution as linear over time. By tapping into our understanding that products must grow in a planned way, and that products are supported by a variety of mechanisms, Prune the Product Tree allows customers to shape all aspects of the product, instead of just providing feedback on a selected set of features in a road map.

You and your customers both know that features vary in importance. We tend to want to put our efforts behind the most important features—those features that provide the greatest value to customers. Unfortunately, sometimes this means that we put too little effort behind the features that are needed to complete the product. The Prune the Product Tree game provides your customers with a way to provide explicit input into the decision-making process by looking at the set of features that compose the product in a holistic manner.

Prune the Product Tree also gives product teams the rare opportunity to identify, and potentially remove, those product features that are simply not meeting customer needs.

How to play: Start by drawing a very large tree on a whiteboard. Thick limbs represent major areas of functionality within your system. The edge of the tree – its outermost branches – represent the features available in the current release. Write potential new features on several index cards, ideally shaped as leaves. Ask your customers to place desired features around the tree. Observe how the tree gets structured – does one branch get the bulk of the growth? Does an under-utilized aspect become stronger?

Understand your customers’ definition of success.

This game is based on numerous studies in cognitive psychology that have examined how we think about the future. When we ask the question “What will our product do?” we’re left with an open-ended future, one in which every possible future is equally plausible. Of course, this isn’t strictly true, and to answer the question we will pick a possible future and describe it. However, the lack of a concrete outcome means that we don’t have to deal with the details of how our product will have done it. Others will tend to judge our answers as “hollow” or “lacking substance,” because there is no requirement that this is actually the future that will materialize.

Remember the Future enables you to not only understand your customers’ definition of success, but also their understanding of how that successful outcome happened.

How to play: Hand each of your customers a few pieces of paper. Ask them to imagine that it is sometime in the future and that they’ve been using your product almost continuously between now and that future date (month, year, whatever). Then ask them to write down exactly what your product will have done to make them happy or successful or rich or safe or secure or art – choose what works best for your product. Key point – ask “What will the system have done?” not “What should the system do?”

Understand when and how your customers use your product.

Start Your Day is about exploring different contexts in which your customers use your product. In the game, you vary the time context. As you do this, pay attention to how other contexts change. For example, you might find that your customer uses your email/scheduling program at the beginning of the day from their home office and at the end of the day from their work office. These locations are quite different, and understanding how they differ provides you with substantial insight into the problems your customer is trying to solve. This understanding, in turn, leads to innovations.

Ask your customer to describe the daily, weekly, monthly , and yearly events that are related to their use of your product on pre-printed, postersized calendars or a simple timeline on poster paper. Ask them to describe events in time frames appropriate for your project. Special event that are unique to an industry or sector (like a conference), or days in which everything goes horribly wrong and they’re looking for help. While they’re doing this, be alert for how your product helps – or hinders – their day.

Arguing that estimation is a bad thing, particularly in the Agile world, and presents ways to plan that don't involve estimation.

Presenting Allen Holub's thinking (and many other's) thinking about #NoEstimates.

Analyzing wether its a good idea to break Product Backlog Items (PBIs) down into tasks or not.

Why do over 60% of Agile teams breakdown their work into a Sprint Backlog and is it okay to decompose work into units? Tristan Libersat in this article explains whether it's effective to simplify work into tasks in a bid to achieve organizational goals. He notes that the Sprint Backlog includes both the Product Backlog Items (PBIs) and the plan on how to execute them to achieve the Product Increment or goal of the Sprint Review, basing on the Scrum Guide.

How leaving spikes unpointed reveals problems and enables corrective action sooner, fostering better clarity for customers.

Humans seem to be much better in estimating the size of something rather than estimating durations.

Removing some of the mystery surrounding Story Points, and sharing the most common misconceptions I have encountered.

Wrong estimates aren’t your fault, but they are definitely your problem.

151 tools to strategically prioritize initiatives with tons of linked resources for your inspiration.

In this post, Jordan Lamborn provides 155 feature prioritization ideas for product managers. The frameworks include the agreement and certainty matrix, impact vs effort, values vs feasibility, among many others and all contain tons of linked resources.

Eight alternatives ways to represent and manage your product backlog to make it more impactful.

The Product Backlog tends to grow, seemingly exponentially, as the product matures and more users enter the system. With more and more cases to handle, it becomes essential to groom the backlog in different ways depending on context. Anthony Murphy shares 8 different ways you can organize your backlog to get the visualization that you need for every situation. Each organization illuminates clarity onto the backlog from a different perspective.

Defining the goals of a product to understand what value means and how to decide what to deliver and when.

In this Scrum Tapas video, Professional Scrum Trainer Stephanie Ockerman looks at many aspects that define a product and its goals. She addresses some of the questions around what value means and how value is critical to deciding on what to deliver for the product and when.

Creating an MVP through iterative delivery and constant customer feedback.

Willem-Jan Ageling writes about Minimum Viable Product (MVP) and the importance of Scrum when deploying an MVP, suggesting that Scrum is all about empiricism and helping stakeholders make potential future customers part of the product's journey. He also acknowledges that MVPs help reduce the risks of burning out cash on a product that might not coalesce with the customers as they enable early users to interact and provide feedback for the product's development. Check the article to gain more insight into what is an MVP, its impact on future potential customer development, and the role of Scrum in MVPs.

Defining how value is context dependent and the definition of value in a certain context may change over time.

Robbin Schuurman explores the question of 'What is value in a product?" noting that product owners should maximize the value of the Product, in order to create, deliver and maintain a successful Product. However, he also captures that 'value' is dynamic and context-dependent thus its definition might change over time. He further suggests 10 tips to product owners about business values.

Concepts around handling complexity in Agile at scale.

In a very quick overview of what is a team backlog and how to effectively manage it, the SAFe team explains the basic concepts of handling team tasks. Besides defining what the team backlog is and how to handle it, this article explains how to optimize value delivery and system health with capacity allocation, and how to handle backlog refinement.

Maintaining a suitably detailed, one year rolling roadmap - progressively disclosing options/solutions.

Roadmaps define a project's goals and major deliverables (milestones) in a given timeline. They show what the project is to deliver now, next, in the near future, and later on. However, how would you best know the most viable feature to roll out to the customers through the project's timeline? John Cutler believes that teams leveraging 'suitably detailed roadmap items', are more likely to deliver the most viable solution to the customers. Such Roadmaps contain multiple options regarding one issue that the team tries as a solution to prioritize one as the main option.

Understand customer priorities.

Effective product teams not only understand which set of features must be present to justify a release, they have carefully enumerated the ranking of each. They also know that different market segments may not agree among these rankings, so they seek to understand differences among the market segments. The 20/20 Vision game can help you collaboratively achieve the best ranking together with your stakeholders. Asking your customers to prioritize a list of features without providing them the opportunity to explore design continuums or dependencies often results in misunderstandings. By facilitating discussions of feature priorities with several customers, you will give them the chance to explore design continuums and relationships that result in a better understanding of market needs.

Activity Overview: Start by writing one feature each on large index cards. Shuffle the pile and put them face down. Take the first one form the top and put it on the wall. Take the next one and ask your customers if it is more or less important than the one on the wall. Place it above or below, depending on its relative importance. Repeat this with all of your feature cards. Your goal is to encourage the debate, but to do so you’ll need to answer their questions about features. Customers often change priorities by adjusting choices on design continuums.

Prioritize features.

Which feature will entice customers to purchase your product? Which feature will cause customers to upgrade? Which feature will make customers so happy that they’ll ignore or tolerate the features that they wish you would fix or remove?

Product planners endlessly debate these and other kinds of questions. Choosing the right set of features to add to a release often marks the difference between short-term failure or long-term success. Unfortunately, too many product planners make this choice without involving the people most affected by it—their customers. The Buy a Feature game improves the quality of this decision by asking your customers to help you make it.

Activity Overview: Create a list of features with an estimated cost. The cost can be development effort or actual cost you intend to charge for the feature. Customers "buy" the features that they find desirable, and participants may also pool resources to buy features too expensive to be purchased with individual funds. This helps motivate customers to negotiate between themselves as to which features are most important. Observation of this negotiation provides great insight into what customers are willing to pay for.

Use outrageous features to discover hidden breakthroughs.

An outrageous feature induces cognitive dissonance. That’s fancy language for saying that an outrageous feature makes customers uncomfortable. So, they work (mentally) to get rid of the discomfort. The most common ways to deal with the discomfort are rejecting the feature outright, pretending that the feature was never really discussed, or trans-forming the “outrageous” feature into something that isn’t so outrageous. The magic happens during these transformations—they are the things that can create breakthroughs in the product. The Give Them a Hot Tub game encourages you to generate your crazy ideas and let your customers determine just how crazy those ideas really are!

This game is useful if you need to build products that operate in various “extreme” environments, because you typically can’t easily simulate or access the extreme environment. Examples of extreme environments include those that are physically demanding or dangerous or those where the risk of human, societal, or financial damage is high should a failure occur. In these situations, the Give Them a Hot Tub game enables you to safely explore potential solutions for extreme environments.

Game Overview: Several potential product features appear on a shuffled set of note cards, one feature per card. Some of the proposed features are completely outrageous, such as a "crush rocks" setting for a new food blender. Observers note what happens when a customer uncovers one of these outrageous features. The biggest preparation challenge when playing this game is creating features that are extreme enough to cause cognitive dissonance, yet not so extreme as to force customers to reject the game. The facilitator presents each feature to customers and invites them to respond in one of three ways: 1) Accept the feature as is with no changes; 2) Reject the feature outright as something they don't want; 3) Transform the feature into a new feature that is something that they do want. Then ask for explanations for transformations, capturing both the initial outrageous feature and how this feature was ultimately transformed.

The Sprint Backlog is flexible, as long as changes do not distract from the focus on the Sprint Goal.

Do Development Teams commit — essentially promise — to complete all the items on the Product Backlog each sprint? Can new insights during the Sprint result in changes to the Sprint Backlog? Or is it fixed? This post by Christiaan Verwijs addresses the myth that the Sprint Backlog is fixed during the Sprint. It makes the case that the Sprint Backlog is flexible, as long as changes do not distract from the focus on the Sprint Goal.

A miro board with 8 organization strategies along with variations and explanations.

Would you like to learn some of the different ways of organizing a product backlog and their effectiveness? There are several techniques for building a backlog, for starters, you can use the '' User story map" method or the '''Funnel backlog'' technique but the former is best when building your backlog for the first time while the latter comes in handy restricting the number of product items at the top. So which of these 8 different ways would you prefer as the product manager in a bid to satisfy your customer's needs?

Four examples with the reasoning and considerations that shaped them, how they were refined during the Sprint and what was discovered along the way.

In a quest to help people build a better understanding of the kind of reasoning that informs Sprint Goals, Christiaan Verwijs writes a story of a real product that he worked on aimed to innovatively integrate a set of related HR products into one platform. He explores the goals the Scrum Team came up with in each Sprint detailing the reasons geared to creating them, what they discovered during that sprint, and how the goals refined the Sprint backlog. Let's read to find out more about how Sprint goals shape both the Sprint Backlog and refinement.

Using s a metaphor to illustrate the potential impact of having more than one product owner per product.

Learn why the Scrum guide emphasizes that a product owner should be one person, not a committee. Using a boat and crew metaphor to answer the question '' Can we have more than one product owner',' it concludes that a single accountable person whose decisions are respected by the entire organization brings clarity and speed that significantly increase your chances of success.

The Product Owner ensures that there is a Product Backlog, that it is ordered, and that it is made available to both the Scrum Team and stakeholders.

Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve complex problems with an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths.

Enabling a holistic response to learning insights by focusing on a daily rhythm of reviewing what is for Now, Next and Later.

Detailed planning creates comfort and a sense of being in control, but it is ultimately an illusion. Smaller, frequent panning helps us adapt to future changes as it simplifies and improves the way we embrace these changes. Todd Lankford shares a three planning framework - The Now, Then, and later which helps make the planning easier to adopt by following a hierarchy of needs for the backlog refinement. Carrying out the work in daily batches reduce the number of future refinements as well as give rise to new ideas ensuring targets are met.

Learn the characteristics of a well-formed story, when/how to slice them, and explore nine common patterns for effective story slicing.

Kim Poremski explores some of the common challenges that Scrum teams experience and how focusing on INVEST criteria and vertical story slicing can help. Through the session, she highlights the characteristics of a well-formed story, explores nine common patterns for effective story slicing, and offers clues for when/how to slice stories.

How to do effective Sprint Planning as a Product Owner?

Introducing a Sprint Goal template that allows you to formulate powerful sprint goals. It states the actual goal with the method and the metrics used.

Setting a good Sprint Goal is challenging and important. How do you nail Sprint Goals?

Sizing the Sprint Goal so that the team can focus and have the flexibility to create a Done Increment by the end of a Sprint.

Doing Sprint Planning in 5 easy steps.

If you can’t work with Sprint Goals, fix your Product Management issues first.

Crafting a clear and overarching Sprint Goal during Sprint Planning.

A mental model and framework you can use for new/existing products (and even PM interviews).

Ahead of launching a product, organizations collect data on what their customers actually need, what they intend to achieve with the product, and of course, they must make sure they have enough capital. However, after launch, most products' key results and value to the customers diminishes. So what should the product managers do to make sure the product is a success? Some of the actions to take would be adding new features to the product to attract customers. Such actions eventually become the product's metrics but how should you really define GREAT metrics for any product?

How To Avoid The Unintended Consequences Of The “One Metric That Matters”.

Product Consultant and Executive coach Vincent Low delivers this piece explaining the basics of metrics, essentially what it is and why it matters, how to develop a metric from scratch, and how to avoid the unintended consequences of the "one metric that matters". Through the article, he tells real-life stories and cases on the impacts of metrics.

The definitive A/B testing resource. Run better experiments, be more confident in your results and become an experimentation expert!

Identify the most important artifacts created by your product.

Show and Tell works by giving your customers a chance to dip into a deeply felt human emotion to show you when and how they are using your product to do their best. By telling you how they are doing the best they can, they will also be telling you how you can help them do it better - by gaining insights into what really matters.

Activity Overview: Ask your customers to bring examples of artifacts created or modified by your product or service. Ask them to tell you why these artifacts are important, and when and how they’re used. Pay careful attention to anything that surprises you – artifacts you expected them to create or modify that they have ignored, artifacts that aren’t used, or artifacts used in unexpected ways.

Identify what customers don’t like about your product or service.

Although most customers have complaints, few customers are genuinely “against” you or your product. Even if they express extreme frustration, the reality is that they want to succeed when using your product. Giving them a way to express their frustration without letting a group mentality or a single person dominate the discussion is what most customers want. Speed Boat creates this relatively safe environment where customers can tell you what’s wrong. You’ll find fresh new ideas for the changes you can make to address your customers’ most important concerns.

How to play: Draw a boat on a whiteboard or sheet of butcher paper. You’d like the boat to really move fast. Unfortunately, the boat has a few anchors holding it back. The boat is your system, and the features that your customers don’t like are its anchors. Customers write what they don’t like on an anchor. They can also estimate how much faster the boat would go when that anchor was cut. Estimates of speed are really estimates of pain.

Create empathy for the customer experience.

When you understand your customers’ needs so well that you can envision solutions to problems they may not realize they have, you are well on your path to creating innovative products and services. The Apprentice provides members of your product team with the opportunity to create the empathy that they need to create innovative products and services. As a bonus, it also provides them with a wealth of concrete, direct experience that they can use during the product development process.

Activity Overview: Ask your development team to perform the “work” of the system that they are building. If they’re creating a new masking tape for painters, ask them to work with real painters, using the masking tape in the field. If they’re creating a new professional oven, ask them to cook meals with a professional chef—not in a classroom, but in a real restaurant, where they have to experience the actual challenges of creating meals. If they’re building work flow management software for furniture delivery people, have them deliver furniture. They will gain direct knowledge of the problems customers face and empathy for how hard it may be to solve them.

We are running experiments like 19th century scientists. We should know better.