What is a product

What is a product

What actually is a product? This is a very important question. 

The challenge of correctly defining your product is one of the most important decisions you will make. 

We describe a product as something which:

  1. Has a producer & a consumer.
  2. The consumer is either is
    • willing to pay, or
    • looking to get some cost benefit by using the product
  3. The product solves a problem for the consumer

A product does not have to be a physical object. A product could also be a material like a service.

What is your product or what things to consider when defining your product? Let’s say you drove to work in your car this morning. These days steering wheels have buttons on them to adjust the volume or initiate a phone call. Is this button a product? 

Absolutely 

  1. there’s a producer and a consumer who
  2. has bought the button and 
  3. it solves a problem. 

But now did you ever buy a button for your steering wheel? I guess the answer is no. So is the steering wheel a product? Yes, absolutely the same criteria apply. But again now did you ever buy a steering wheel on its own? I guess the answer is no, unless you are a tinkerer. Well what do you purchase? A car! A car is the product which solves an important problem for you! Transport.

 

Defining your product is about finding the right level of abstraction. 

Usually the larger you go the better it is. 

 

 

 

Why?  Let’s look at the bank example. There’s an interest calculator component, which is considered a product, which means there will be a product owner, a scrum master and a development team. There is also the account management system which again is a product and there’s the money wire service, transaction logging web front end and so on. You get the idea that you will have an army of product owners forming a web of dependencies. More important: 

Where in this picture is the real customer?

Follow the money! Combine all the components forming the value stream pointing towards the real consumer, your customer. This value stream is your product. 

Suppose that a consumer called Nancy wants to buy a house. She’s looking for a loan

  • the loan is her product  
  • the bank is the provider
  • Nancy is the consumer and
  • it solves a problem

All these components form the value stream for the loan product. Generally, you can assume that the value stream points outside the boundaries of your company. This means that the consumer is not on your company’s payroll. The resulting value stream should be guided by a single product vision, the guiding beacon for all the components. And there will be one product owner

The validation of this resulting product is much more meaningful. If the product is large, it is common to have several development teams working for this one product owner on that one value stream. Yet again, the common vision ensures a shared alignment between those teams. I strongly believe that every person working on a product should know their place within the value stream.

But, what about shared products or components that cannot be eliminated? The goal is to minimize them. The less shared components you have, the more independent and faster your value stream can act. Thus, your business can be more agile.

Having products which are defined too small and therefore depending on too many components leads to the following problems:

  • A project mindset
  • Sequential life cycle and milestones
  • Unnecessary dependency management, coordination and overall management complexity
  • Handoffs, information scatter and high inventory 
  • too much focus on efficiencies, working on low value features 
  • Opaque measure of progress
  • Inventing of work 
  • Loss of customer and Whole product focus 
  • Cost of delay and finally 
  • Less value

The more your product expands the less shared components you will have and the less of dimension problems. 

 

 

 

It’s about scaling the product, not your scrum. 

 

 

 

In summary, managing work as a product rather than project, changes structures, decisions and behavior in product development, which in itself fosters an agile mindset. 

 

Structuring your organization and company around your value stream, should be your ultimate goal.

 

Ralph Jocham runs Scrum.org sessions with Agile Actors #learning on a regular basis for PSM I, PSM II, PSPO and PSPO Advanced certifications. See our courses on agility here