Naming is one of the two hard things in Computer Science. VSM uses the term Product very deliberately in order to guide its customers. This page provides background as well as a comparison to similar concepts. Further, it provides a best practice on attributes & integration to LeanIX EAM.
The goal of VSM is fast time-to-value, hence we would encourage you to get started with the defaults. In case you feel the need to adjust naming, attributes or more, please revisit the Data Model configuration
There are four main views on the term products influencing VSM's understanding:
Gartner sees a product as a named collection of Business Capabilities valuable to a defined Customer Segment.
Aha! provides a comprehensive guide to take a holistic view on products - stating that "a product is any item or service you sell to serve a customer’s need or want".
The Scaled Agile Framework (SaFE) uses the term Solution to comprise all "products, services, or systems delivered to the customer, whether internal or external to the Enterprise"
The Project-to-Product movement represents a seismic shift in the understanding of modern software engineering. It is common sense in the industry that Empowered product teams produce the best outcomes, taking accountability for customer needs, reliability, security, and further software requirements. The role of empowered teams is amplified by a setup outlined below.
Prefunded - encourages hoarding & large batches, no incentive for feedback loops
Based on business results & demands, feedback loops encouraged
End date - maintenance is not highly important
No predefined end date - maintenance is core
On time, on budget
IT as black box
Transparency through direct mapping of business context
The goal of a Product in VSM is to provide the product teams with the business context around their work. For this reason, VSM comes with four major dimensions that allow a standardized, transparent understanding.
Subscriptions are an intuitive way to manage product responsibilities. Typical setups see at least a Business Owner, other roles might be:
- UX Responsible
- Lead Product Manager
- Main Sales Contact
- Main Customer Success Contact
Subscriptions have a combined function. With the role type Responsible, they unlock data quality mechanism, e.g. notification on changes. With the role type Observer, they mainly provide indication about whom to contact.
Lifecycles are LeanIX's concept to capture different phases of a product. They allow advanced filter functionality as well as roadmap planning.
In order to get started fast, you can also use a Tag instead.
There are certain key attributes for a product, its maturity & utilization that drive the joint understanding of stakeholder groups:
- Category: Is a product customer-facing? Or a platform?
- Customer types: Is the product targeting external customers? All - or just a segment (e.g. midmarket)? Or internal customers?
- Strategic focus: In addition to the lifecycle, it is key to understand what is driving product decisions:
- Incubation - the goal is to learn rapidly, even to the extent that the focus is still changing
- Growth - the focus is on execution, in strong collaboration with customers & prospects
- Stability - the functional scope is nearly complete, or the strategic focus is declining (e.g. due to a changing market)
- Sunset - there is active work in moving customers away from the product
- Net Promoter Score (NPS) - how satisfied are customers with the product
- Monthly active users (MAU) - how is user adoption developing over time
VSM is centered around Software Artifacts, so the strong belief is that engineering teams gain an understanding of the customer view by a direct mapping to products. This mapping can be driven by the teams themselves, e.g. from metadata in CI/CD, or by governance processes.
As the API economy is growing, understanding which public APIs a product is offering is also key. This knowledge is often not codified, so a manual mapping based on automatic discovery (e.g. from MuleSoft ) is often recommended.
In addition, especially for complex products Domains helps to create an internal segregation layer, e.g. based on functionality or on technology. Often, Domains are used to align internal processes, e.g. support.
Finally, the contribution of Teams to products can often be derived by the transitive relation (via Software Artifact, Domain, API) so there is no need for direct mapping.
From an Enterprise Architecture point of view, it's important to distinguish between products that are internally used (could be dedicated developments for processes like HR or Finance, but also "drink your own champaign" - e.g. LeanIX usage at LeanIX) and externally used (products that are sold to and / or managed for customers). We see some areas where it's mandatory for a modern Enterprise Architect to get involved, others as optional
All aspects around a modern Application Portfolio (e.g. business support, ownership, GDPR compliance, technical risk).
Support the CTO to drive business transparency, e.g. by supplying core maturity & utilisation information
Seek synergies in the corporate & product architectures, e.g. by streamlining skill sets or driving digitalization initiatives jointly
Based on the involvement, there are two major approaches regarding the lifecycle:
- If the main use case is internal products (e.g. for an insurance company), typically the lifecycle is starting from Enterprise Architecture Management - in LeanIX EAM as an Application. The Application is transferred to VSM to serve as context for the product team, and the linkage (e.g. to Public Cloud information) is provided back to EAM
- If the main use case is external products (e.g. for a SaaS company), than the lifecycle typically starts from the VSM side - data are synchronised into LeanIX EAM, e.g. to allow the Enterprise Architect to establish certain stage gates.
Updated 8 days ago