Hand Holding Mobile Phone Snap Taking Photo
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.
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.
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.)
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.
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.
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.
OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs…
For any business to succeed, it is crucial to make the right strategic choices. To…
Being empowered can make all the difference in doing a great job. Sadly, not all…
Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think…
Product discovery has become increasingly popular in recent years as a way to determine the…
Strong product leadership is crucial to offering successful products and enabling product-led growth. Unfortunately, there…
View Comments
Hi Roman,
This is a great article and a gift that keeps on giving in the comments section. I wonder if you could also point to a crisp definition of a user journey and how that relates to products and product invariants?
Is a user journey generic enough that it can cut across multiple products and invariants, or does user journey have a more precise and constrained definition in your experience?
Hi Nick,
Thank you for sharing your feedback and question. I am glad that you find the article and the discussion in the comments helpful. I view a user journey as the steps that a user has to take in order to interact with the product and achieve a specific benefit. Say you want to shop for a new insurance online. You then have to find the insurance, evaluate it, make a purchase decision, register with the provider, and pay for it. A user journey can touch several products. In the sample I just stated, you might use the insurance company's website, which might consist of several digital products, as well as the insurance product. Similarly, you might interact with different product variant. Image that after a few weeks, you decide to download an app offered by the insurance company and administer the policy on your phone.
Btw, I generally advise to work in a product focused way and organise around products, as I find products to be more stable than user journeys.
Does this help?
Hey Roman,
This helps a lot, I couldn't have asked for a better answer. I'm very grateful.
There is just 1 more question that came to my mind. How would you define an internal system which people inside a company use to run business processes, like an admin dashboard. It's like a product with many features, but we don't offer it to customers and monetise it.
Could this still be considered a product or is there a more descriptive name that clarifies its purpose better?
Glad that the answer was helpful Nick. If the system creates some specific value for internal users and at the same time for the company, like reducing cost or increasing productivity, then I would view it as an internal, non-revenue-generating product.
Hi Roman,
Thank you for the clear and concise article. Question - Where do you draw the line between a product and a service? Why would Facebook be considered a product and not a service? How different are Product Management principles from those of Service Management? welcome your thoughts.
Thank you for your feedback and question Rattan. The main difference between a product and a service is that the latter has to be instantiated or provided, typically by one or more human beings, in order to create value. Facebook, for example, is a product that allows people to share and consume stories, photos, and videos. A Facebook-based service would be an offering where a video production company shoots bespoke videos for a person so that individual can post them on Facebook. Does this help?
Hi Roman,
Your articles are always insightful and helpful as usual. Thank you for this post.
Should I as a product manager consider the support services we provide + our help centres as part of the product they are meant to support or as product entities on their own as they address specific needs of our customers ie getting help they need at the right time and speed to achieve a goal in say our mobile variant?
Many thanks.
Hi Erica,
Thank you for sharing your question and feedback. I would regard them as separate entities that form a product-service system together with the mobile app(s), thereby jointly creating value for your customers.
Does this help?
Hi Roman,
Excellent piece and the fact that it was written back in 2016 but has growing relevance even in 2019 speaks volumes of your foresight, of which I am a big fan.
Have a question - There are many horizontals in any sizeable organization- be it Supply Chain Management, Finance and Accounting, Marketing, Sales, Procurement etc.
In a typical project world, they all cater and support the various vertical entities in the organization- say Energy and Utilities, Manufacturing, Retail etc.
But in a Product world, would each of these be a part of the vertical set up? That is in a squad of resources dedicated to create Retail apps for my organization, would I have people competent in Supply Chain, F&A, Marketing etc.? And I, as a Product Manager, with all the vision, strategy and roadmap that I have for the product, with the limited budget that I have at hand, will have the liberty to deploy the resources at the optimal best manner possible? The horizontals therefore would become a part of the verticals? Is that understanding right?
Thank you for sharing your feedback and question Ved. If you manage a retail product, then I would assume that people from supply chain management, marketing, and other business units work with you and the dev team as stakeholders, as I explain in more detail in the article "Getting Stakeholder Engagement Right". Hope this helps!
Our organization is going through some growing pains as we stand up a product team. One concept you touched on is the “bundled” idea.
We’ve begun to think of that as a “platform” containing many products that have many shared features/components.
So Facebook is a platform containing many products (news feed, messenger, marketplace) which has many shared features (search, likes, comments, photos).
Which leads to a broader discussion: do we need a Platform Manager with Product Managers and Feature/Component Managers all supporting the ultimate business goals?
Hi Justyn,
Thanks for sharing your question. I would consider putting someone in charge of the aggregate product or bundle who works with the people who look after the individual products to align product strategies and roadmaps, create shared, cross-product standards, identify, manage, and remove dependencies, and align release dates. You may find my article "A Strategy Map" helpful to see how business, portfolio/bundle, and product strategy can be aligned.
Hope this helps!
Thank you for this article, and all other great content!
You wrote the following answer to Terry's comment on this article (March 16, 2018 at 1:18 pm): "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."
How would you propose to set up portfolio/program management. What roles should this team consist of, and how do they relate to the Product Owners? Is there a protfolio/program backlog and, if so, how does it relate to the product backlogs?
Any insight you can bring is much appreciated.
Hi Jonas,
Thank you for your feedback and question. Assuming you have a portfolio of related products in place, I would consider having an overall product portfolio owner/manager who is responsible for the portfolio success and supports the product owners/managers of the portfolio member products, for example, by aligning major releases, ensuring appropriate cross-product consistency (UX, tech), and harmonising product roadmaps. Sometimes, the head of product plays this role. The individual product people would still own their products and work with their own product backlogs.
Does this help?
Hi Roman and congratulations about this wonderful post !
About "Web vs. Mobile", i globally agree with you, but in our case, for instance, we want that our users give us feedbacks and ratings on our product and we can have a very good "desktop-web"
experience and and terrible iphone's application one. As we want to build a repository of our digital products, we need to define precisely what is a product.
Thanks for your feedback Vincent. As suggested in the article, I would call an iPhone app that is related to your web app a product variant. Ideally, it should offer the same user experience so that people can seamlessly use the two apps.
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.
Should I consider the product in an holistic way (components from BE + features from FE) or can I consider a product a set of components or a set of features that enable a specific experience to the final customers (e.g. purchase an item or add it to the wishlist)? Thanks
Hi Fiammetta,
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.
Does this help?
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!
Hi Christi,
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.
Does this help?
Hi,
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?
Cheers
Hi Jessica,
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.
Does this help?