Product Definition

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.

Does a close relationship with your stakeholders position you to become a successful Product Owner?

Experienced Product Owner Maarten Dalmijn explains how he had to cope and persevere with critics and bullying from his stakeholders throughout his Product Ownership journey.

He states that it was a challenge working with that caliber of stakeholders but he strengthened his relationship with the stakeholders by involving them deeply in the product.

As a result, the expert product owner realized the mutual relationship he created contributed to his success and suggests some important lessons that he adopted through his journey as a Product Owner.

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

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.

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?