Using Architecture to Improve Product Management
by Daniel Lambert
​
Product management is an essential ingredient to a successful customer-centric business transformation. For many mature organizations, product management will sometimes be involved in the creation of a new product, but much more frequently it will involve revamping existing products, or more precisely architecting appealing value propositions made of tailor-made products for each specific customer segment or persona targeted by the organization. Identifying key capabilities that are needed to deliver optimized value proposals more rapidly and with lower risk is critical. More broadly, fine-tuning product management with business and enterprise architecture is all indicated. The same applies to services and even IT microservices.
​
The Necessity of Product Management
​
In my previous life, I was a somewhat successful venture capitalist investing in start-ups. I’ve quickly learned that the most important issue to increase the value of a small technology company is to thrive in product management. You ideally want your CEO to be a top product manager. More and more, large and traditional organizations recognize this imperative and are now naming product managers to increase the odds of success of their business transformation, as explained in depth in this book entitled “Practical Guide to Agile Strategy Execution: Design, Architect, Prioritize, and Deliver your Corporate Future Successfully”.
​
“Product managers are responsible among other things, for product vision, market research, competitive analysis, target market, customer requirements, and roadmap.[i]” More specifically, multiple skills are required to decode product management, which involves product knowledge, people skills, and, what I call, product architecture.
Product knowledge includes 6 skills, which are product operations, business, and organization, competition and industry domain, customer experience, and data analytics/insights. People skills consist of these 5 skills: team collaboration, stakeholder management, communication, leadership, and evangelization.
Grasping product architecture in large and complex organizations is also crucial for product managers. Product architecture ideally involves collaboration with enterprise and business architects. It implies specific skills, that are too often overlooked. As shown in Figure 1 above, product architecture includes the following 16 skills:
​
-
Product lines and customer segments,
-
Strategy definition and goal setting,
-
Opportunity assessment,
-
Problem research and definition,
-
Value propositions,
-
Identification and assessment of enabling capabilities,
-
Technical design architecture,
-
Solution design and validation,
-
Human, technical, and financial resources planning,
-
Scenario analysis and final roadmap selection,
-
Project-related business outcomes elaboration,
-
Agile development and execution,
-
Development backlog management,
-
Roll-out and product launch,
-
Customer feedback analysis, and
-
Continuous experimentation.
-
​
These 16 product architecture skills can be segmented into four tiers: 1- product strategizing, 2- product discovery, 3- product delivery, and 4- product optimization. Here, we’ll focus on the first three.
​
Product Strategizing
​
Product architecture usually starts with product strategizing, which involves these four product management tasks, as revealed in Figure 1 earlier: product lines and customer segments, strategy definition and goals setting (including lower-level tactics and objectives), opportunity assessment, and problem research and definition. Business and enterprise architects can assist product managers in fine-tuning at least two of these tasks: product lines and customer segments, and strategy definition and goal setting. Here’s how.
Typical large corporations today usually have a very sophisticated product portfolio. Such product portfolios can include one, several, or all the following: solid material, hardware electronics, software products, business process outsourcing of non-primary business activities, insurance, warranty services, etc. To add to this complexity, many products may have been obtained through acquired businesses, with or without product managers. Various business capabilities are required to deliver these products to their respective markets, as shown in the pharmaceutical product example shown in Figure 2 above. In this example, 16 specific business capabilities are required and support the pharmaceutical product. Driven by intensive competition, companies try to expose more business capabilities that can support the products that they are delivering to their market, increasing furthermore, the complexity of product management. Each one of these new business capabilities will require specific solutions that will need to be validated.
​
There is a lot more to product mapping than linking products to their enabling business capabilities. Product mapping also includes the use of these fundamental relationships, where a product is 1- part of a product line, 2- impacted by one or several strategies, 3- owned and or offered by a business unit, 4- affected by an initiative, 5- sometimes sourced from a Partner, 6- parts of a value proposition (as per Figure 5 below), 7- involves a specific customer journey (as per Figure 4 below), and finally 8- relying on capabilities (Figure 2 above).
Three-dimension diagrams are often used to make sense of product mapping. For example, Figure 3 above displays a 3-dimension table on how products and or product lines rely on capabilities and are managed and/or offered by business units.
There are other ways to use three-dimension diagrams. As shown in Figure 4 below, each time a product line is offered to a customer segment, a specific customer journey probably needs to be fine-tuned. In other words, an organization should not limit itself to only one customer journey map. It goes without saying that if a product line is not provided to a customer segment, there should not be a customer journey map. The concept and use of the customer journey map are described in detail in this article entitled “Architecting and Delivering Optimal Customer Journeys”. Value propositions, composed of one or several products or services, can preferably be used instead of product lines. It should also be noted that personas can be used instead of customer segments.
In brief, 3-dimensional tables are a key ingredient to product mapping in complex organizations. In theory, they can be built using most of the 8 fundamental product mapping cross-relationships mentioned earlier in this section.
Product Discovery
​
Product management also involves product discovery, which is about the creation of a new product or enhancing a current one. As shown in Figure 1 earlier, product discovery entails these six product management skills: value propositions, identification and assessment of enabling capabilities, technical design architecture, solution design and validation, human, technical, and financial resources planning, and finally scenario analysis and final roadmap selection. Business and enterprise architects can assist product managers in the execution of at least four of these tasks: value propositions, identification and assessment of enabling capabilities, technical design architecture, and finally scenario analysis and final roadmap selection.
​
In a customer-driven organization, where maximizing a customer’s lifetime value is a critical strategy, the concept of value proposition is essential. By definition, a value proposition is “a belief from the customer about how value (benefit) will be delivered, experienced, and acquired. A value proposition can apply to (…) customer accounts, or products, or services.[ii]”. The value proposition statement drives the design of your product and services. You want to have a perfect match between your value propositions corresponding to each one of your customer segments. Value propositions are the essence of the 9 building blocks of a business model canvas[iii]. Creating a value proposition with a specific customer segment through a customer value map, as shown in Figure 5 below will enhance the productivity of product management dramatically. A customer value map can be used for each customer segment or persona served by an organization.
​
A customer value map resembles a little to a value proposition canvas[iv]. The customer value map includes a description of a customer segment served or to be served by an organization, and a value proposition offered or to be provided by the organization. The description of a customer segment will include the needs, gains, and pains of the client. Each “need” should ideally be covered by a product and or a service composing a value proposition. Each “gain” and “pain” should be addressed by a benefit and or a feature of one of the covered products. Any need, pain, or gain not addressed by the value proposition represents a gap and may require a strategic initiative or a project that may remediate this missing link. Once needs, gains, and pains for each targeted customer type or persona are addressed, product managers can begin planning which capabilities, initiatives, business units, and information are required to deliver the products and or services of a value proposition.
One or several value streams deliver a value proposition, as shown in Figure 6 below. “Value streams are artifacts within business architecture that allow a business to specify the value proposition derived by an external (e.g., customer) or internal stakeholder from an organization. (…) The value stream is depicted as an end-to-end collection of value-adding activities that create an overall positive result for a customer, stakeholder, or end-user. In modeling terms, those value-adding activities are represented by value stream stages, each of which creates and adds incremental stakeholder value items from one stage to the next [v]”.
​
A value stream is triggered by one or several stakeholders, usually a customer, a persona, a client segment, or a partner in a customer journey context. In this example, the business unit manager, product manager, current client, or partner can all be a triggering stakeholder. A value stream delivers one or several value propositions. In this example, the value proposition is a Product Ready for Production. A value stream consists of several value stages. Each value stage includes one or more entry and exit criteria. Value stages can be decomposed into sub-level value stages for more details. For example, the entry criteria “New Product Request” is an entry criterion of the “Initiate Medication Product Candidate Request” value stage. As for the exit criterion of the “Medication Product Candidate Phase 3 Clinical Trial” value stage, it would be “Production Design Signoff”.
​
It is important to note that a value stream is not a “value chain” that models how an organization tackles resources and transforms them into finished products in a sequence of stages. A value stream is closer to customer experiences and business capabilities; a value chain is more about processes and functional capabilities.
Finding the enabling business capabilities of the value streams that deliver a value proposition, made of products and services is a very efficient way to make sure that you do not omit any enabling capabilities of a product or service. Figure 7 below shows, for example, the “Develop New Medication Product” value stream with its enabling capabilities for a customer in a bank. This value stream requires five value stages. Each value stage is enabled by between 4 to 11 capabilities, where 34 unique capabilities in total enable the value stream. Subject-matter experts must determine each enabling capability within your organization (and not just business architects and enterprise architects alone). Should you have most children of a capability enabling value stages of a value stream, it may be preferable to select only the parent capability.
Identifying the enabling capabilities of a value stream should be completed for all customer-driven value streams of an organization. Once this exercise is completed, it will become clear that some business capabilities within your organization are critical because they enable many value stages of numerous customer-driven capabilities. If these essential business capabilities are not operating optimally, the impact on the success of the organization will become evident.
A set of current and new capabilities are required to capture the value from optimal customer journeys. As revealed in a McKinsey & Co report entitled “Customer Experience: New Capabilities, New Audiences, New Opportunities”, “Decision-makers from all stakeholder groups should align together and embrace uncertainty together, developing capabilities throughout the entire design process. The use of existing resources can keep the investment in time and costs low.[vi]”
​
The increasing pace of digital disruption is forcing all organizations to move from points of customer sales to aspects of customer experience. Organizations must provide more maturity to their business capabilities around a much more dynamic customer experience. The use of business architecture in combination with customer segments (or ideally personas) throughout a customer journey is an excellent method for innovative organizations to keep up with this pace of disruption everywhere in the organization. From the value stream to the technology solution and process models, business capability mappings are becoming a vital mechanism to transform businesses into a customer-driven enterprise that provides lifetime value to customers.
​
Marketers and product managers are becoming excellent with the elaboration of enticing and optimal customer journeys. Their organizations use various agile methodologies in the hope of speeding things up, and yet most of them struggle to deliver these journeys on time and within budget. Enterprise, business, and product architecture can unravel and prioritize customer journey initiatives early on by identifying and focusing foremost on the problematic enabling capabilities of their organization’s customer-driven value streams using measurement methodologies in this article entitled “The Art of Measurement in Architecture”. Once your problematic business capabilities have been assessed and identified, make sure that they are addressed in your product roadmap, from which specific projects will be derived.
​
Product Delivery
​
Once an organization has an adequate understanding of its product strategizing, and its product discovery, product delivery should become easier to execute. As shown in Figure 1 earlier, product delivery requires these four product management skills: project-related business outcomes elaboration, agile development and execution, development backlog management, and roll-out and product launch. Business and enterprise architects can assist product managers in the execution of at least two of these tasks: project-related business outcomes elaboration, and the planning of agile development and execution.
​
Laying out the nomenclature and GANTT Chart of your projects into sub-projects needs to include a business outcome derived at minimum from strategies and tactics. At best a business outcome should be derived from goals and objectives, as shown in Figure 8 below.
Strategies consist of high–level plan items that also include short-term tactics to achieve an organization’s significant goals under conditions of uncertainty. A goal is a desired result that an organization envisions, plans, and commits to accomplishing within a finite timeframe. As for objectives, they are essentially short-term goals whose achievement brings an organization closer to its long-term goals. Goals are drawn from strategies. As for objectives are derived from tactics, which are conceptual short-period actions to deliver and execute a strategy.
If goals and objectives are nowhere to be found in the organization, the business and enterprise architecture team should try to extract them from management. In reality, many business and enterprise architects often must fall back on imprecise strategies and tactics because of the reluctance of some managers to commit to precise goals and objectives.
​
The achievement of agile initiatives and projects in an organization, in the long run, will be much lower if they are not supported by an enterprise, business, and product architecture framework that can be reused and enhanced from one project to the next. Customer-driven digital transformation is not about a one-time change project or spontaneous business activities. Digitization is more about transforming many dimensions of an organization with a structured approach that involves enterprise architecture.
​
Most organizations are now using at least one agile method to deliver their projects[vii]. In this whitepaper, we’ll focus on a major one, Scaled Agile Framework® (SAFe®), where the harmonization between architecture and agile teams can contribute to the delivery of successful projects, as described in this whitepaper entitled “Fusing Business and Enterprise Architects to Increase the Success Rate of SAFe® Projects”.
​
Enterprise and business architects should start engaging early, ideally before the beginning of the SAFe® Scrum and Kanban continuous delivery pipeline by focusing basically on these two tasks. First, enterprise and business architects should make sure to link every value stage of the SAFe® Value Streams to its enabling capabilities, information concepts, and various departments and business units to clarify how the business really works. Second, enterprise and business architects need to translate the business strategic themes into more detailed epics. By putting more resources into enterprise, business, and product architecture at the beginning of the SAFe® process, the odds that the program delivers systems and software more useful to its business users increase significantly.
As shown in Figure 9 above, architects should get involved at all levels of the SAFe® activities from very strategic activities to more tactical ones. Enterprise architects and business architects get involved most of the time at the following activity levels: portfolio management, value stream management, and product management. This corresponds to the subsequent actors within SAFe®: portfolio managers, value stream engineers, and release train engineers. Solution architects also play an essential role in SAFe®. They are involved in product management and ownership and interact with value stream engineers, release train engineers, and sometimes scrum masters. As for the system or application architects, they are engaged with product ownership and software development and testing, and they work with release train engineers and scrum masters.
​
The enterprise architects’ role in SAFe® is to provide architectural governance, technical direction, iterative collaboration, and a comprehensive solution deployment tactic across SAFe® value streams at the portfolio level. This, in turn, creates enabler epics, which are large chunks of work made of several user stories, to enable desired business and technical changes.
​
Solution architects in SAFe® should be engaged in the product management and product ownership level with or as value stream engineers and release train engineers.
The application architects then begin to set the architectural runway for the SAFe® value streams by making architecture blueprints with a systems viewpoint, based on the leadership provided by the enterprise architect. This entails crafting a future state for the architecture, and then forming a transition plan, preferably with increments to enhance the organization from its current state to the desired future state.
​
As for software architects, they will also be involved in the software development and testing phase with scrum masters.
​
Are Microservices Any Different?
​
An increasing number of large and traditional organizations are relying on IT microservices, which are autonomous applications and systems that have a single purpose, to perform their business transformation at a quicker pace as they offer more flexibility, responsiveness, maintainability, and scalability. “Microservices are an offshoot of service-oriented architecture (SOA), taking the SOA concept one step further by creating discrete and fine-grained services and protocols that are lightweight. That’s important in both new development and in the modernization of traditional monolithic systems that coalesce several complex business functions and workflows into a single system.[viii]”
Microservices have initially been developed for internal stakeholders, but more and more microservices are now also offered and used by external stakeholders, mostly customers. Like traditional products, microservices offered to external stakeholders are now even contributing to generating substantial revenue and profits. Microservices is how most organizations are eventually going to conduct most of their business, internally and externally.
As shown in Figure 10[ix] above, microservices are developed based on specific user interfaces, logical business information, and processes. One or several open application programming interfaces (API), which are a software intermediary that allows two applications to connect, will be used to communicate with enterprise data extracted from legacy applications and systems. A micro-service is meant to support one or a few level-1 or level-2 capabilities. Many more mature organizations have now developed and are now using a series of microservices, which are becoming critical and very strategic to their success. This is why microservices, like products, need to be managed and architected the same way as products.
​
Service, microservice, and product management are more than ever an essential ingredient to a successful customer-centric business transformation. For more and more mature organizations, product management and product architecture are becoming key ingredients to the satisfaction of their client and the sustainability of their success. Identifying key capabilities that are needed to deliver optimized value proposals more rapidly and with lower risk is critical. More broadly, fine-tuning product management with enterprise, business, and product architecture is all indicated.
​
_________________________________________________
[i] Quote extracted from this article entitled “Business Architects and Product Managers” written by Ganesh Balasubramaniam on the BAInstitute.org website.
[ii] Value Proposition definition according to Wikipedia.
[iii] View this video made by Strategyzer on YouTube for a rapid and good explanation of a business model canvas.
[iv] View this video made by Strategyzer on YouTube for a rapid and good explanation of a Value Proposition Canvas.
[v] Value Stream Definition according to Wikipedia.
[vi] Quote extracted from a report entitled “Customer Experience: New Capabilities, New Audiences, New Opportunities” published by McKinsey & Co in July 2017.
[vii] Source from the “Agile Landscape Version 3 Diagram” made by Christopher Webb from Deloitte in 2016.
[viii] Quote extracted from this article entitled “Microservices Are the Key to Flexible Architecture & Development” written by Pardeep Tatla and published in the Architecture & Governance Magazine in December 2019.
[ix] Figure 10 is somewhat inspired by a figure from the article entitled “Why Microservices Will Become a Core Business Strategy for Most Organizations” written by Dion Hinchcliffe in September 2018 and published on this website: https://enterpriseirregulars.com/.