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 updated a number of application 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 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.