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.
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.
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.
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.
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.
Find out what a digital product is and how it differs from projects, features, components, bundles, and the user experience.
Hi Roman, thanks for the interesting article.
What should be considered a product for an ecommerce company that sells physical goods and it's platform-based? It means the company develops all the components (e.g. payment solutions, content management, operations, etc) to let different FE teams integrate them on their layers and offer features to the final customers.
Thank you for sharing your feedback and question. It's difficult for me to make a specific recommendation without knowing more about your context. Having said that, products can be composed of other products. You might, for example, regard a platform as a product in its own right and equip it with a platform owner and a platform development team.
But I would encourage you to define your products outside in: Start with the users (or the different user groups) who interact with your website and determine their needs and user journeys. Use these to guide you in identifying the end user-facing product. Next, determine software assets that enable you to offer end-user functionality and address the user needs.
If an asset offers specific value to a user group, such as, allowing several development teams to use a payment service, and if it creates value for your company, for instance, cost reduction through reuse, then it would make sense in my mind to call the asset a product.
If you have a website and an app, then you have one product backlog for both based on this article. If you need multiple teams to deliver features (mobile team, website team since codebases differ), do you recommend then a scrum of scrums approach with one Product Owner? Or would you have 2 product owners? Appreciate the help!
Thank you for sharing your question. The number of product people required to look after a product depends on the amount of product management work involved, which is influenced by the amount of innovation and uncertainty present as well as the number of development teams involved.
Generally speaking, the younger a product is and the bigger the changes are that it experienced, the more work there is for a product owner. Similarly, the more teams a product owner has to collaborate with, the more work the individual faces. In fact, I find that working with more than three teams is often not feasible for a single product owner.
A common scaling approach would be to have one individual act as the overall product owner and, say, the web app owner. The other product person would then act as the mobile app owner. Please see my article "Scaling the Product Owner Role" for more information on scaling.
I'm in the process of reviewing the definition of "Product" in my organisation as well and I must say this is a difficult exercise. We had initially structured our product owners around the key point of the journey such as search and checkout which is very much what you highlighted as not being a product.
I'm not sure what would be the best approach, we are basically an e-commerce platform but we don't sell physical product like amazon, but online products/services. I can define our Digital product as being the platform/software that serves those "commercial products" to the user but still struggle to make sense of then the size of work it represent for one product manager to look after the overall platform, while we still need product managers to develop those "commercial products".
What would be your view?
Thanks for sharing your question. It's difficult for me to advise without knowing more about the users and your products. But based on what you have told me, it seems reasonable to be to regard the platform as a product that markets and sells your commercial, revenue-generating products. This would be similar to the approach I have chosen for my website: I regard it as a product bundle that offers other products like my templates and books and services such as my training courses.
First of all let me congratulate you for the awesome article.
I've recently discussed about this with some coleagues and some confusion occured.
Some say that a digital product has its content created and uploaded by the users and that webapps, for example don't. I for instance see a product as something that helps users achieve and complete a certain task while giving practical and emotional value. Having this in mind is the Medium App (or similar) considered a digital product? And what about the Spotify WebApp? Can it be considered a Digital Product like the mobile app?
Hi André, Thank you for your feedback and question. I would regard the Spotify web, desktop, and mobile apps as variants of the same digital product; the same is true for the Medium web and mobile apps. Does this help?
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?
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.
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.
Thanks for your feedback Greg.
thank you for again very interesting article.
– 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.
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!
Hi Dear Mr Roman Pichler.
I found your essay really useful.
As you said above, What websites such as Amazon.com offer their customers are solely a bundle of features and they are not product?
Dear Alireza, Thanks for your feedback. My intention was not to say that amazon.com is not a digital product but to point put that I would view search and navigation or check-out as features that correspond to steps in a user journey. Hope this helps!
Perfect to help us solve the confusion between the products the company offers and the software that originates and maintains those products. Thanks!
Thanks for your feedback and great to hear that you could action the advice in the post!
Thank you for this inspiring post. Would you suggest one single roadmap for a product bundle oder roadmaps for every product/feature?
I am terribly sorry, but I just realised that I never answered your questions. It may be way too late now but still, here is my answer: I would create a roadmap for each product in a product bundle. In the case of Microsoft Office, for example, I would create a product roadmap for Word, one for PowerPoint, and one for Excel. But I would consider having one overall product strategy for the bundle, assuming that the products contained in it address the same market (segment) and offer the same (or very similar) value proposition.