VSM for Product Leaders
What is a product?
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.
Business Capability Modeling is a core area of LeanIX EAM - see below
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.
|Budgeting||Prefunded - encourages hoarding & large batches, no incentive for feedback loops||Based on business results & demands, feedback loops encouraged|
|Time frame||End date - maintenance is not highly important||No predefined end date - maintenance is core|
|Success||On time, on budget||Business outcomes|
|Visibility||IT as black box||Transparency through direct mapping of business context|
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
|Internal product||External product|
|Mandatory involvement||All aspects around a modern Application Portfolio (e.g. business support, ownership, GDPR compliance, technical risk).||None|
|Optional involvement||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 3 months ago