How to Define a Product

A question that frequently comes up in my Scrum Training courses is how to define a product.

Scrum was created to help small teams solve complex problems and deliver products of the highest possible value. Scrum is used well beyond software because many teams and organizations recognize their work is complex, and they need to be nimble, creative, and value-focused. Yet defining your product can be challenging in both a software and non-software context.  

How to Define a Product

What if you have a large complex system with multiple pieces that work together to deliver value to customers?  What if your team provides processes or services such as marketing, sales, or innovation research?  And what if those services you provide are a wide variety of work types that are not “integrated” in the same way software is?

Like most things in the complex world, there isn’t one right answer, and you may need to explore and adapt. In this blog post, I share how I coach people to think through defining their product. There are two essential things that help you define your product: Done and value.

Define a Product – Done

• The Scrum Guide talks about an Increment being valuable and useable. The Increment must meet a Definition of Done to ensure appropriate quality and transparency to progress. Prior to November 2020, the Scrum Guide used the term "releasable" to describe the Increment (see this post about the 2020 Scrum Guide update). The concept of releasable sometimes causes confusion when the product is a service or perhaps R&D/ experimental outcomes.

Let’s remember that the purpose of a Sprint is to create a Done Increment, and the key benefits this offers are:

• Transparency to progress.

• Transparency to quality.

• Enough focus to get something meaningful accomplished.

• Limit the risk of investment.

• Easily change direction frequently.

• Make more informed decisions about what to invest in next Sprint.

• Validate assumptions about what you are building and how you are building it.

Whether or not it makes sense to “release” the value to users or customers, your Definition of Done should bring the above benefits. If you are not getting enough of these benefits, consider different ways of doing the work that creates iterative and incremental value for customers and the organization. That of course brings us to the value conversation.

Define a Product – Value

Scrum is not just about delivering more stuff.  It’s about creatively delivering products of the highest possible value. I like to talk about this as outcomes over outputs. But what is value? How do you know you are creating valuable outcomes?

Well, you have to define value in order to have transparency to what value you are trying to create.  And then you can inspect and adapt your way towards greater value every Sprint. This may mean continuing forward or integrating new ideas. Or this may mean course-correcting when you discover assumptions were wrong or something has changed in your environment.

If you are a services or processes team, you may discover you provide different types of value through different work types.  For example, a creative services team may provide graphics, market research, social media, and comprehensive marketing campaigns.  Each of these are different types of work that create different types of valuable outcomes, and they may also have different Definitions of Done.  The concepts of value and Done go hand-in-hand.

The benefits of having these conversations will carry forward as you then consider how to create a Product Backlog that enables the benefits of Scrum.  It is often challenging to shift from task-oriented planning to creating Product Backlog items (PBIs) that can provide value iteratively and incrementally.  Yet it is becoming more essential in our rapidly changing world.

Now lets look at some questions that can help you have better conversations and gain more clarity around how you define your product.

Define a Product: 7 Questions to Explore

#1 – Why do we exist?

This really hones in on a team’s purpose, and more specifically what value and/ or benefits they create.  Another way to look at this is how you would “pitch” the organization to hire your team.

#2 – Who gets value from us?

This helps us connect to end users and customers.  For teams who provide processes and services used by other internal teams, it may not be obvious how they connect to external customers and/ or a business model.  When you start to connect those dots, you can break out of the mindset of focusing on tasks and deliverables and see opportunity to deliver value in entirely new ways.

#3 – At what point is value realized?

This helps us connect value and Done in a more clear way.  If you cannot realize the value of a piece of work for several Sprints, or you hand off work to other teams to get further worked, that is a lot of investment risk to carry.  Perhaps that is a constraint that is part of the nature of your product, however, it’s important that you have transparency to the risk and seek to lower the risk over time.

#4 – How and when do we validate assumptions about value?

This helps us think creatively about validating assumptions more frequently.  Another way to explore is to look for patterns when we tend to get surprised and have to shift direction and/ or do re-work.

#5 – In what ways can we build quality in along the way?

This helps us think about how we can avoid quality surprises late in the process.  Quality issues may include bugs/ defects, gaps in truly understanding the users and what they need, discovering incoherence or lack of integration with larger systems/ processes, or  missing regulatory or security constraints.

#6 – What activities can we incorporate sooner?

Perhaps there are peer reviews, customer or stakeholder reviews, copyediting, business process impacts, user training, or experiment results analysis.

#7 – If you need to completely change direction in the next Sprint, how much value would you realize by the work you’ve done to date and how much work would be waste?

This challenges us to look at the cost of how we are working and brings transparency to the impacts of any constraints we may currently have.  And it inspires us to continually push ourselves to get more creative and enable the benefits of Scrum and business agility.

Summary

There is no one right way to define a product.  Just start somewhere. Use the questions in this post to start a conversation and gain enough insights to define your product (i.e. services, product suite) and if necessary your work types, ensuring clarity on value and Done.  Inspect and adapt.

You may discover that you need to tweak it or completely overhaul it based on what you learn and how your business models, markets, and teams are evolving.  Trust in empiricism!