VSM for Product Leaders

Intro

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.

📘

Hint

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

What is a product?

There are four main views on the term products influencing VSM's understanding:

Top-down

Gartner sees a product as a named collection of Business Capabilities valuable to a defined Customer Segment.

🚧

Attention

Business Capability Modeling is a core area of LeanIX EAM - see below

Product Management

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".

SaFE

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"

Project-to-Product

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.

Best practices in VSM

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.

Ownership

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

📘

Hint

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.

Lifecycle

Lifecycles are LeanIX's concept to capture different phases of a product. They allow advanced filter functionality as well as roadmap planning.

📘

Hint

In order to get started fast, you can also use a Tag instead.

Maturity & Utilisation

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

Composition

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.

Joint approaches with EAM

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

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.