Three layers of “products”: conceptualization framework

Abstract

Using well-defined terms from systems engineering can lead to clear communication within product development teams. We put a label of “product” onto the product system of interest (SoI), service SoI, and product-as-practices-of-making-money. These three types of products produce hierarchy, a systems’ holarchy. We have capabilities, make services on top of them, and find additional monetization models besides selling things and service subscriptions. We call all these different things “products,” though various organizations build them using different kinds of plans and multiple approaches.

Opinionated domain

Imagine that the R&D director who commands 4 product lines comes to the CEO and states that he doesn’t know how to:

• Establish a coherent methodology for planning and control across all product lines. He doesn’t know what milestones, phases, and typical deliverables are required; whenever the customer wants a new product, he starts planning almost from scratch.
• He cannot establish organizational structure and reporting lines for departments. He doesn’t know if project management, operations, and design should report to him or another CxO.
• And finally, he concludes that it is impossible to discover and follow best practices for prioritization, planning, and new product launch for development tasks. And there are no dedicated tools to do R&D jobs, and they perform most of the functions in Excel, Notion, or Confluence. Texts and tables, that’s all they have.

As CEO, you know what to do — you need to fire the guy who isn’t qualified and promote someone from R&D to the new position. You also talk to the best people from this department and find out they are clueless. 9 out of 10 are dissatisfied with the organization and consider that the product’s success depends on a particular leader. If she is good, the product survives. If not, it will be a failure. Then you go on the market to understand if it is just your problem and find out that maybe the top 20 companies do better, but most of the market lives like that, and that’s normal. When you try to find out why things are the way they are, 20% give a weak explanation, but most are clueless.

The problem above is almost bogus. And that’s a bizarre situation, don’t you find? Every business function knows how to organize its activity. They know what to do in finance, production, operations, purchasing, and logistics. Engineers also don’t have these problems. Engineers have had locally optimized processes that are not integrated across the entire enterprise, poor alignment and coordination of the extended enterprise, or unclear roles, responsibilities, and accountability (Oehmen J. et al., 2012) ten years ago, but at least now they don’t lack the knowledge about how to build R&D organization to achieve different goals.

But product organizations still have them (The 2023 State of Product Management Report, 2023):

1. Product organizations don’t know and cannot follow best practices in planning, control, and resource prioritization — nine people out of ten are dissatisfied with these business aspects and consider that success depends on the skills and aptitudes of particular professionals.

2. The industry does not have an answer to the root cause of these organizational problems (systems engineers know that very well in hard figures). Only around 20% of respondents gave some reason for the poor corporate performance. Others state the problem and don’t know how to resolve it, even in theory.

3. These problems are immaterial for other business functions. Engineers, finance controllers, and product floor people have proven business rules, best practices, and fact-based guidelines. They are not as opinionated as product management, where many gurus and working groups develop incoherent frameworks.

The research hypothesis is that there is a fundamental misunderstanding of product management concepts. And that has implications: product organization (structure, business functions, organizational interfaces, processes) is still fluid. Unstable domain boundaries and unclear definitions impede the understanding, onboarding, and career path planning and drive inefficient knowledge and information management of the product management domain. I argue that we can achieve the proper overall understanding of the product manager role only when considering how three transdisciplinary approaches work together. Namely, how system engineers, program managers, and product managers work together and what concepts and tools they operate while using the same terms for entirely different things, which causes ontological rattling during communication. This work is the first step that establishes the foundational concepts in the product category.

The missing protocol

Science and technology studies (STS) revealed how researchers and engineers agree on something, how they develop theories, how one approach wins over the competitors, and how the social construction of the facts works. STS gives us the know-how to produce evidence from mere and unreliable data. In other words, it explains how research protocols operate in the laboratory and design center to make a convincing narrative in a room full of decision-makers. When I looked at the ProductPlan report through the lens of STS methods, I saw this problem differently.

Let’s be specific for the sake of further argument. The report mentioned above shows that the old discussion about outcome vs. feature product development plans is still far from resolution, as 54% say that their product roadmaps focus more on outputs, and 43% say they focus on desired outcomes, with 3% choosing other options. We look at the presupposed dichotomy when we see a 100% pie cut into three portions, but here we make a mistake in ontological foundations.

That is a natural way to think about feature-based and outcome-based as opposed because product organizations oscillate between these approaches. We see that a lot. And that makes us feel that these product planning frameworks comprise classification — we are either in this box or in the other. Running is contrary to sitting, falling is contrary to flighting, and serving a customer is contrary to following instructions. It is easy to mistake two different states of a system for two operational modes of a system, but they are fundamentally different. States can overlap, like I can be both hungry and sick, modes cannot, and I cannot be both excited and depressed. And My organization uses output-oriented roadmaps as a state, not a mode.

It’s much more like I was running, then I got hungry, then I was running again. Yes, you can build a pie chart that will say what percent of the day you were running and what you were hungry for, but something will be off with it. It’s just not so apparent with questions about product road mapping techniques. And as product managers are missing the consensus-building protocol laboratory researchers utilize, they cannot uncover such hungry vs. running situations and become victims of endless debates.

Three layers of “products”

(Kun, 2016) describes the first step for such protocol — provide clear definitions, with good examples and counterexamples. And here, you will find a big surprise, as different language communities use the term “product” with roughly three different meanings. But we can arrange these definitions into a clear hierarchy, using systems thinking and 4D ontologies (West, 2011; Partridge et al., 2020; Partridge, 2021; Apollo-Protocol/4d-activity-editor). A product has a layered architecture if we consider it a system.

The best illustration of this idea provides in Figure 1: General types of Engineered System of Interest (SoI) (‘Types of Systems — SEBoK,’ 2022). It introduces the following concepts:

The first layer

Technology system of interest. That system contains the core functionality engineers build, for example, a working prototype of Fortnite in the development environment. Or an operational breadboard for a new industrial computer. Sometimes engineers can call that a product because it results from a technology development project, but in most cases, they use the term “system.” Elements of the development plan on this level are technical capabilities and system requirements.

Then comes the “product system of interest.” This usually goes under the term “product” in systems engineering communities. In the Russian language, there is a very exact term “изделие.” COTS software release, industrial computer, commercial plane, or phone. It has a technology SoI at its core, with a product interface, product control, and related technology. For example, U.I., license, and installation package for software. Or industrial design, warranty, and wireless connectivity for computers. Or Android launcher and shell, platform app store, and branded case design for a phone. Or some particular plane configuration for a transportation company, with several service and warranty contracts and a technological package. The usual approach to distributing roles and responsibilities is that R&D develops technology SoI, and design, marketing, and product organizations are responsible for a product SoI. We plan to release and validate product features as product specifications’ elements on this level.

But not all products SoI are usable by themselves. Sometimes you need to integrate a complex solution from them. Xbox + controller + TV-set + phone + Fortnite. Or CAD/CAM/CAE working station. Or Obsidian + Logseq + Cobian Reflector + Zotero + Office365 + Grammarly setup for a Zettelkasten. It is very similar to the previous one in an engineering sense. In the case of the automobile, we get a highly complex solution already collected together and don’t need to tweak the car in a garage.

But sometimes, we need to perform such system integration on our own. It could take the form of constructing some design from a T.V. set, self-made antenna, and amplifier like at some point we did in the 80s in the rural areas of Russia (and you needed to know radio technics to operate a T.V. properly). Or we are applying much effort to build a properly working personal computer from components and O.S. distributive in the middle 90s. For that, I will write a separate piece on “integration on the customer side” as it is a fascinating phenomenon of technological advances.

What’s important to understand here is that we can discuss this system level as a technical package or “product infrastructure.” Innovation happens not in one type of system or product but in some “technological packages.” For example, during the Great Discoveries making open sea navigation devices was a very profitable business, and they improved a lot, but only because of enormous progress in shipbuilding, crew education, cartography, and other parts of the technological package of trans-Atlantic transportation. The same happened with software, the progress of which heavily depended on advances in hardware, network equipment, applied mathematics breakthroughs, and venture funding technologies.

You cannot ignore and unfollow the evolution of the technological package your product is part of because otherwise, you can find yourself on the losing side of a format war. I leave alone the current boom of generative A.I. and LLMs, which again results from graphical chips, cloud computing, transformer models, and a lot of manual labor of labelers. What’s important here is that your product is only a part of such “ecosystem” or “infrastructure” or “technology” and shares the proliferation success of the overall solution. And this end-use solution, customers deploy, integrate, and build on their own at the place of operation, fulfilling the role of system integrators. So it would help to have a monitoring and response plan on this level.

Because of the deterioration of Internet infrastructure, personal search engines need to store referent sources locally or in a cloud or server and not rely on websites as information sources anymore. A phone development team can watch and adapt to Android releases. Streaming companies change the content format following the development of large screens, and game-developing companies respond to the availability of more powerful graphical chips. IKEA adapted the furniture form factor to the typical flat layout. The operational environment matters; sometimes, this environment is part of your innovation wave.

Not every time this technology package is so apparent. Suppose you are developing a personal productivity tool. In that case, you will track new Notion features release, changes in data exchange APIs for data storage cloud solutions or Rust libraries, and follow the change log of Transformer models: an introduction and catalog — 2023 Edition. If you know your technology package well, small changes (like tweaking API or config) sometimes enable new product features, and you can make a difference in product offers.

As we see from the cases above, this is not some goal-oriented planning. These are not roadmaps. It is response planning, part of risk and opportunities management, or trust architecture development. The logic of such planning differs significantly from road mapping, so we cannot mix it up without breaking the classification scheme of the plan. Many project and product managers forget that any plan is some taxonomy, a cohesive set of types, and a breakdown containing the same objects (tasks, resources, risks, organizations, features, functions, or locations). And suppose you violate this structure too much. In that case, disorganization will happen (Star, 1995; Bowker and Star, 2000; Garfield, 2023).

The feature-based and technology package response plans above are perfectly covered by the product line engineering discipline (Product Line Engineering: Are You Missing a Piece in Your Digital Engineering Puzzle?, 2023) and Capability Engineering — SEBoK (sebokwiki.org) and their planning techniques. A prevalent implementation of this approach for software development is the SAFe framework. This is what ProductPlan in the report called “output/features roadmaps.”

We see now that this is a required planning level. It’s an essential engineering job. Engineers need product specs because they cannot communicate without them (Madden and Stewart, 2014). And Cagan mentions it explicitly, saying it is the engineering manager’s and CTO’s responsibility to develop a plan at this level. In a perfect world, it is not a job for a product manager (Cagan, 2019). So, there is another planning level and another discipline responsible for it.

The second layer

The first-level systems provide capabilities that can be packed as products and sold. Planes, cars, phones, and laptops are good examples. Pfizer’s COVID vaccine is a beautiful example of how to win a competition by having the best capability on the market when the product itself (shot) is more or less the same. The business model for product SoI is feature-based, hence output-based roadmaps. There is a feature pack (car options, for example), and each feature gives the user some advantages and delivers benefits. It is a classic FAB sales and marketing technique from the 40s.

But let’s consider the evolution of technological business models that started in the 2000s. We began to use capabilities to slice them and provide cloud services or merge them to indicate weather and obtain GPS position in smartwatches. We also can build an enormous set of different capabilities, bundle them together, and sell sophisticated tiered access to them as Microsoft does with Office365. Or we make a massive capability but sell only a tiny interface module, as Uber or Alibaba does.

We must not be mistaken — though we need capabilities for our products to run, it doesn’t mean we should build and operate them. Let’s take the famous case of “the blue box” (Steve Jobs — The Lost Interview, 2013). It was a small device that mimicked the service codes of a telephone network and got you free-of-charge calls. The extensive telecommunication system has provided a proper function, and hackers were selling the product that just abused it, providing unauthorized access to the capability. That brings us to an essential concept of a service as “…a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.” (Reference Ontology for Semantic Service Oriented Architectures v1.0, 2008).

And many products are exactly like this — Uber app (and service regional operator) is a mechanism to enable access to the transportation system; your mobile bank app (together with the frauds department and customer support) is a mechanism to facilitate access to the banking system; and chatGPT is a mechanism to enable access to a massive generative A.I. system with a significant social component.

We sell a product (Haines, 2021), and in the case of service SoI, its boundaries do not coincide with capabilities boundaries. Services live on top of capabilities — taxi companies, banks, and LLMs have already existed with another service layer. We can rebuild the service layer separately with very few tweaks of the core capability to make a successful product from a failing system. Here are a couple of cases.

One research university deployed a comprehensive Wi-Fi campus network. Though technologically, it was a very successful project (capability was ok), the dean was unhappy. The network was expensive, and students overloaded its segments when large groups visited some particular site simultaneously. The CTO asked for additional equipment to address such complaints, but they could not be justified. The project was already too expensive. So the dean appointed the product manager to fix the problem. And with just a few small changes in user experience and network reconfiguration, the PM introduced paid tariffs that allowed prime access for a small charge and other product modifications. With its budget from these payments, the project survived and thrived.

The online trader’s fulfillment center has had difficulties measuring the effectiveness of pick-up procedures. The PM came up with the idea of using smartwatches to monitor the movements of warehouse and delivery operators. It took only small API changes to collect the data from bracelets. Again, there was no capability change, but it ultimately resulted in another system function (a smartwatch is an indicator and autonomous sensor module, speaking of system functions) and service. And it was a much more successful product than the classical warehouse monitoring solutions industry used.

Again, the above figure explains the systems engineering concept of service very well. The Fortnite service, for example, includes subscriptions, payments, marketing, tournaments, regional servers, a map editor, customer support, updates, match-making, etc. We don’t need product line or capabilities engineering to plan these activities; we have service science and service engineering. Technical capabilities of Fortnite technological core are well outside of game service, and service development requires separate planning, with service elements, not capabilities, as objects of planning. A couple of years ago, I heard a story about how Grundfos turned their pumps into service SoI with subscriptions, and my guess is it did not take very much capabilities engineering. The same happened with service contracts for plane engines and car subscriptions.

Services isolate you from capabilities and give you an abstracted technology interface. And you have to plan their development and deployment separately from the product SoI that delivers capabilities. Look at the OASIS standard I cited above; it gives an excellent conceptualization of service systems (and for the categories of service development planning) concisely.

The third level

And, finally, here goes the “layer of products” as product managers from Meta or SVPG write about them (Cagan, 2022; Ganti, 2023) — products as a set of practices for making money. When we label “product,” we just want to say that we understand how we make money. Or, making the definition more strict, “a product is a construct that reduces uncertainty in practices of making money.”

Technologically a product can be minimal, like the Uber app. It is a functionally insignificant part of the transportation system of systems that provides functional capability and services. The same applies to the YouTube app and YouTube system and services on top of it, or chatGPT, or Carrefour online store, which is a small visible part of the enormous retail chain. Product managers discover such parts and monetize them. Users do not consider the value of some hidden capabilities, and you cannot charge them in service models.

Critical remark regarding the cost of products — in systems engineering planning, we look at a project with the eyes of a very qualified investor and operator who wants to get into the details of everything. System-of-interest, enabling systems, the operational environment, and all lifecycle costs must be calculated and justified with economic effects and benefits. But when people were buying Amazon AWS, they didn’t want to think about all that sunk costs of data centers and the necessity to return these investments for Amazon, so carefully designed product-as-practices provided precisely that. They limit concepts only to your operational domain, so you perceive it as “jobs-to-be-done,” and not system functions that can have emergent behavior and adverse effects.

So, when you consider Fortnite products, you have all three levels. You pay for the product SoI, which is the application itself, you can pay for the service Xbox Game Pass to access the game, and finally, you can pay for Fortnite Crew and other perks and bonuses. All three levels work cohesively to hold you in the environment where you spend money. Seasonal campaigns are free of charge, but they reduce churn, and some gamers who stay will pay for a Fortnite Pass and Crew. The same goes with YouTube — you can pay for a premium subscription, or businesses pay for ads you watch. It’s all the product manager’s job, and they have their disciplines, which are beautifully described in (Steinhardt, 2017). And when I hear “outcome-based roadmaps,” I understand that people want this third type of “product.” And when you think about products like systems engineer, how can you sum up technological SoI and product-as-practices and demand they must produce 100% together? They cannot.

Bibliography

Apollo-Protocol/4d-activity-editor GitHub. Available at: https://github.com/Apollo-Protocol/4d-activity-editor/discussions (Accessed: 18 May 2023).

Bowker, G.C. and Star, S.L. (2000) Sorting things out: Classification and its consequences. MIT Press.

Cagan, M. (2019) ‘Product vs. Feature Teams,’ Silicon Valley Product Group, 29 August. Available at: https://www.svpg.com/product-vs-feature-teams/ (Accessed: 26 April 2022).

Cagan, M. (2022) The Nature of Product, Silicon Valley Product Group. Available at: https://www.svpg.com/the-nature-of-product/ (Accessed: 25 April 2022).

Ganti, A. (2023) ‘How Meta uses analytics to assess Product Market Fit’, Medium, 21 February. Available at: https://aniganti.medium.com/how-meta-uses-analytics-to-assess-product-market-fit-c9262add2790 (Accessed: 22 May 2023).

Garfield, S. (2023) ‘Classification Process and Taxonomy’, Medium, 23 March. Available at: https://stangarfield.medium.com/classification-process-and-taxonomy-dbefa98bb396 (Accessed: 27 March 2023).

Haines, S. (2021) The Product Manager’s Desk Reference, Third Edition. 3rd edition. New York: McGraw Hill.

Kun, J. (2016) ‘Habits of highly mathematical people’, Medium, 5 August. Available at: https://medium.com/@jeremyjkun/habits-of-highly-mathematical-people-b719df12d15e (Accessed: 25 October 2022).

Madden, J. and Stewart, R. (2014) ‘One Hundred Rules for NASA Project Managers’, p. 13.

Oehmen J. et al. (2012) The guide to lean enablers for managing engineering programs. Joint MIT‐PMI‐INCOSE Community of Practice on Lean in Program Management.

Partridge, C. et al. (2020) ‘A survey of Top-Level Ontologies To inform the ontological choices for a Foundation Data Model Version 1’. Construction Innovation Hub. Available at: https://www.cdbb.cam.ac.uk/files/a_survey_of_top-level_ontologies_lowres.pdf.

Partridge, C. (2021) ‘A 4-Dimensionalist Top Level Ontology (TLO): Mereotopology and Space-Time’, in. Newton Gateway to Mathematics, INI Seminar Room 1. Available at: https://gateway.newton.ac.uk/presentation/2021-04-22/29946 (Accessed: 18 November 2022).

Product Line Engineering: Are You Missing a Piece in Your Digital Engineering Puzzle? (2023). (Calling All Systems). Available at: https://www.youtube.com/watch?v=uQy6RBfguhw (Accessed: 29 May 2023).

Reference Ontology for Semantic Service Oriented Architectures v1.0 (2008). Available at: http://docs.oasis-open.org/semantic-ex/ro-soa/v1.0/pr01/see-rosoa-v1.0-pr01.html#_Toc214854765 (Accessed: 26 February 2023).

Star, S.L. (1995) ‘The politics of formal representations: Wizards, gurus, and organizational complexity’, Ecologies of knowledge: Work and politics in science and technology, 88, p. 118.

Steinhardt, G. (2017) The Product Manager’s Toolkit®. Cham: Springer International Publishing (Management for Professionals). Available at: https://doi.org/10.1007/978-3-319-49998-7.

Steve Jobs — The Lost Interview (2013). Available at: https://www.youtube.com/watch?v=TRZAJY23xio (Accessed: 26 April 2022).

‘The 2023 State of Product Management Report’ (2023). ProductPlan. Available at: https://assets.productplan.com/content/The-State-of-Product-Management-Annual-Report-2023.pdf.

‘Types of Systems — SEBoK’ (2022). Available at: https://sebokwiki.org/wiki/Types_of_Systems (Accessed: 28 May 2023).

West, M. (2011) Developing high quality data models. Elsevier.