As product managers and product owners, the products we look after are fundamental to our work: they shape our day-to-day activities and determine our responsibilities. We create a product strategy and product roadmap; we manage the product backlog and use minimum viable products and product increments. But what is a product? While this seems a trivial question, I have met a surprising number of organisations where people had a wrong or conflicting understanding of what a digital product is. This can cause confusion, lead to unclear roles and responsibilities, and result in applying the wrong product management practices. This post wants to help you reflect on what a product really is and how it differs from features, components, bundles, and the user experience.
Product
What is a product? It might be tempting to say, something we can market or sell. But when it comes to digital products, this definition has only limited applicability. Take the search function on your company’s website. Is that a product? Or is the entire website the product? And how would others, including people from development, marketing, and sales, answer this question?
I view a product as something that creates specific value for a group of people, the customers and users, and to the organisation that develops and provides it, as the picture below shows. The former is achieved by solving a problem—think of Google Search or Bing that address the challenge of finding information on the Internet—or by providing a benefit—take Facebook that allows people to stay in touch with family and friends.
Creating value for the business is accomplished by directly generating revenue, like Microsoft Office and Adobe Illustrator do, helping sell another product or service, as in the case of iTunes and Google Chrome, or increasing productivity and reducing cost, as in-house developed IT applications do.
Finding a problem that’s worth solving—or a benefit that people would not want to miss once they’ve experienced it—and discovering a viable business model are two key prerequisites for successfully offering a product.
Products go through different life cycle stages: they are created and launched; they develop, grow, mature; and eventually, they die. Some digital products exist for many years and even decades. One of my clients, a company specialised in digital engineering products, offers a products that contains 30 year old code, for instance. This distinguishes products from projects.
Product vs. Project
A project delivers a product release—think of Windows 10 or iOS 9.3—and it is a temporary endeavour: The project is finished when the new release becomes available. But products have a different life cycle and typically exist for longer. The ancestor of Windows 10, Windows NT, was launched in 1993, and iOS was introduced with the first iPhone in 2007, for example.
Similarly, products have different success criteria compared to projects. A project is successful if the new release is deployed on time and budget, and if it delivers the agreed scope. A product, however, achieves success if it meets it business goals. Revenue-generating products typically become profitable when they have achieved product-market fit and start to grow. This may be months, and in some cases, years after the initial development project was finished.
A product manager’s (or owner’s) job is therefore different from a project manager’s: product people are in it for the long run—assuming that the product prospers and grows.
Features and Components
If an asset does not create value for its customers and users and for the company, then I don’t regard it as a product. Take an e-commerce site like Amazon.com or JohnLewis.com. Both offer search and check-out capabilities so that customers can find and buy goods. While these are important steps in the user journey and may require a complex technical solution involving third-party systems, I would argue that they are not products but features: they do not provide any distinct value to the customer. I don’t go to Amazon or John Lewis to search or checkout. I want to buy the right product at the right price with minimum hassle. A feature is therefore a product capability people can interact with—a part of the product that users can use. But it does not address a need or solve a problem on its own. Instead, several features have to interact to create the desired value for the customers and users.
Similarly, a user-interface layer or a (micro) service that talks to a payment gateway are not products but components, or more accurately, architecture building blocks—even if they are developed by a dedicated team. Both building blocks may offer a benefit to a group of people—the developers of other components and services—but they don’t create any measurable value for the company.
If you manage a feature or component, then that’s perfectly fine. But I don’t think you should be called a product manager or product owner. The terms feature owner or component owner describe your role more accurately: they clearly communicate your responsibilities and avoid confusion and unrealistic expectations. (See my post The Agile Product Owner Responsibilities for more information on how distinguishing between products, features, and components helps you define the right roles and responsibilities.)
Web vs. Mobile
Digital products are often provided in different forms. Google Search and Facebook are both available as a website and mobile app, for example, and the mobile apps are offered on all major mobile operating systems, including Android, iOS and Windows Phone. Does this mean that the mobile version is a product in its own right? And similarly, are the Android, iOS and Windows Phone apps separate products?
My answer to both questions is no. Here is why: The assets don’t differ in the value they create for their customers and users and for the company that provides them. They may consist of separate code bases developed by different teams and the mobile version may provide less functionality, as in the case of Facebook. But the core value proposition is the same—just like a book is offered in print and in an electronic format but its contents stay the same. I therefore view the mobile versions of a product as different product variants, variations of the same product.
Unbundling Features and Product Bundles
Interestingly, features and components can become products in their own right. Take the Facebook Messenger app for example. The messenger feature used to be part of the main Facebook app until it was unbundled in April 2014. This streamlined the main Facebook app and it allowed Facebook to evolve the Messenger app by adding new features, such as sending money to friends, communicating directly with businesses, and using chatbots.
If we take a look at Facebook.com, then we see that messenger functionality is still offered alongside newsfeed and other features. I therefore regard the Facebook website as a product bundle—a collection of related products, including newsfeed, messenger, and games apps. While some products evolve into bundles, as Facebook arguably did, others are intentionally bundled together in order to provide value to the customers and users and/or increase sales. Microsoft, for instance, decided in the late 1980ies to bundle several apps, including Word, Excel, and PowerPoint, into Microsoft Office.
The following image shows the relationship between product bundle, product, feature, and component. A product bundle contains several products, and a product has one or more features and components.
User Experience
The user experience, finally, arises when people interact with a product. It is therefore not the product. While the look-and-feel and the functionality of the product can trigger a specific experience—think of slow loading web sites, complex menus, or cryptic error messages that can test our patience or leave us confused—it is important to recognise that the experience people have is equally determined by their state of mind.
If I am stressed, upset, or angry, I get much more worked up when experiencing a slow loading site, for instance, than when I am my normal self. We should do everything we can to offer a great, pleasant user experience, but we cannot make people experience the product in one specific way. The picture below illustrates the difference between the user experience and the product.
Learn More
You can learn more about correctly defining and successfully managing your products by:
- Attending my Product Strategy and Roadmap course—to understand how to systematically evolve your products, including bundling and unbundling them;
- Reading my book Strategize: Product Strategy and Product Roadmap Practices for the Digital Age—to find out more about the product life cycle, unbundling, bundling, and product variants;
- Participating in my Certified Scrum Product Owner course—to apply the right the roles and responsibilities of product people correctly in an agile context.
| Reference: | What is a Digital Product? from our JCG partner Roman Pichler at the Pichler’s blog blog. |
