What is a Digital Product? by Roman Pichler
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 several organisations with a 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 discusses what a product really is and how it differs from features, components, bundles, and the user experience.
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.
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.
3 comments on “What is a Digital Product?”
MARCH 15TH, 2018
If you had a few different web-based applications you were trying to pull together into one application (let’s call it “SuiteX”) would SuiteX be the “product” with features, or would each application within the suite be a product? Note they would be highly integrated data and functionality wise, but would be used for different things and offer different value to varying users. Having said that, single users will use many of the separate features.
If the answer is that they are separate products (under a product bundle as the article articulates), how would this differ project wise as opposed to one product with distinct features?
Roman Pichler reply:
MARCH 16TH, 2018
Thank you for sharing your question. As the applications have different value propositions and address different user groups, I would treat them as separate products that together form a portfolio or suite, much like Microsoft Office. You may therefore want to establish shared user interaction and interface design standards across the products to ensure that users can seamlessly switch between them, and possibly bundle shared assets (components or services) into a common platform to speed up development and reduce cost. Additionally, you may want to put one person in charge of the suite who is responsible for aligning the different products, evolving shared UX standards, and resolving dependencies.
Does this help?
- Greg De Tisi
DECEMBER 8TH, 2017
Amazing post here! Always love learning about the powerful strategies of producing and delivering value driven digital products – its a fascinating area. Thanks for a great post here Roman keep up the awesome work.
Roman Pichler reply:
DECEMBER 8TH, 2017
Thanks for your feedback Greg
JUNE 5TH, 2017
thank you for again very interesting article.
I like to read your opinion and experiences. But I’ve missed a more precise distinction between different views reading the first few parts of this article “Product vs. Project” & “Features and Components”:
– company’s end user view. This is as described by you above.
– company’s view. For the company (Amazon or John Lewis) the e-commerce site would be the product it purchases to solve it’s problem: creation of quick, flexible and cheap distribution channel. The same could be used for the team’s view inside of one company. Especially if companies organize their departments / teams usig service concept.
Roman Pichler reply:
JUNE 6TH, 2017
Thanks for your comment Maria. You touch on an interesting point: From which perspective should a product be defined? I firmly believe that you should always take the users’ perspective. A product exists to create value and value creation for the company is only possible (at least in the long term) if the product does a good job for the users. I therefore recommend that you start with the users when defining products and ask which problems they want to see addressed and which benefits they want to gain–independently how your current product landscape is structured and what systems and tools you use. Hope this helps!
Thank you Roman Pichler for your insights.