As product professionals, we create a product strategy and product roadmap; we manage the product backlog; we release minimum viable products and product increments; and we are responsible for achieving product success. But what is a product? While it might seem a trivial question, it is surprisingly hard to answer for many organisations. But a poor understanding of this fundamental concept can lead to unclear roles and responsibilities and result in ineffective product management practices. This article offers my definition of what a digital product is and how it differs from features, components, projects, 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 an entity that creates specific value for a group of people, the customers and users, and for 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 tangible 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 promote or sell other products or services, think of iTunes and Google Chrome, for example, 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 product that contains 30-year-old code, for instance. This distinguishes products from projects.
Product vs. Project
A project delivers a specific product release—think of Windows 10 or iOS 14.5—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 much 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 creates the desired value for the users, the customers, and the business. Revenue-generating products typically become successful and profitable when they have achieved product-market fit and entered the growth stage. This may be months, and in some cases, years after the initial development project was finished.
The job of a product manager or Scrum product owner 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 be inclined to view them not as products but as features: end-user facing product capabilities that they do not provide value on their own to the customers and the business. I don’t go to Amazon or John Lewis just to search or to checkout. Instead, I want to buy the right product at the right price with minimum hassle. A feature does therefore not address a need or solve a problem on its own. Instead, several features have to interact to create the desired value.
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 and iOS. Does this mean that the mobile version is a product in its own right? And similarly, are the Android and iOS apps separate products?
My answer to both questions is no. Here is why: The assets create the same value 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 might differ in the user experience and functionality offered. But the core value proposition is 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 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 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 the users’ patience or leave them confused, it is important to recognise that the experience people have is also 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.
