Here in StraightTalk Post No. 24, we’re going back to focusing on that “so what?” question about business architecture. We’ll take a look at the discipline in action for common business scenarios, this time with a focus on product management.

What’s the problem?

There can be a number of challenges related to product management across an organization. Here are a few common ones:

• Impacts to products (e.g. from strategies, capability changes, initiatives, etc.) may be hard to identify, especially when they cross business units or product areas.
• Significant time and money may be spent on product ideas, designs and plans before realizing they should not move forward.
• Common capabilities may not always be leveraged across products, leading to duplicate solutions.
• Business units and product areas may perform product management differently, leading to difficulty sharing best practices and creation of duplicate solutions.
• Product strategies may face common strategy execution challenges (e.g. strategy diffusion, conflicting initiative scopes, etc.).
• People across business units and product areas may not have a consistent understanding of the product ecosystem, leading to ineffective communication and solutions.

How does business architecture help with all of that?

Business architecture can help to make product management work just a “l-i-i-i-tle” better in a number of ways. We’re encouraged to see business architects working with product managers and bringing the product perspective into the conversation more and more.

Here’s a few specifics on the benefits business architecture can provide for product management:

• Enable a broad set of bidirectional impact analysis related to products – Think quickly identifying business and IT impacts (e.g. capabilities, value streams, system applications) when products are introduced or changed, or identifying the impacts of various strategies and initiatives on products, or identifying which products are involved if we need to make some improvements to customer experience or process.
• Quickly narrow product investment decisions – How much time and money could be saved if we were able to make more informed decisions about product ideas early on before we spend a lot of time validating, designing and planning for them?
• Enable analysis and decision-making for product performance improvement – For example, we can identify where capabilities may be reused to support multiple products, instead of duplicating them.
• Provide a focal point for streamlining product management across the organization – Using a shared enterprise view of product management—through the Develop Product value stream (internal) and related Product Management capabilities, which most organizations have—organizations can align across business units and product areas on common best practices, vocabulary, roles and solutions for creating, delivering and managing products.
• Translate product strategies into a coordinated set of actionable initiatives – Like any strategy, business architecture translates product strategies into initiatives which are uniquely scoped and harmonized with other strategies and initiatives across the organization.
• Create a shared mental model of the product ecosystem – Business architecture gives everyone a common vocabulary and mental model for describing and categorizing the organization’s products—which in its absence can be surprisingly different depending on each person’s role and the area in which they work.

Got it. So how do we actually do this?

For the most part, we use the business architecture knowledgebase to help us analyze, organize and present information to help us deliver on those great benefits described above. Here’s a quick rundown on how we do that.

• Step 1: Identify Scope and Goals for Product-Related Analysis – Clarify what you are trying to achieve and the scope of products and other domains that should be included within your analysis. For example, you may be looking to determine the full scope of impact from introducing a new product to capabilities, value streams, business units, other strategies and initiatives, and operating model aspects like processes and system applications.
• Step 2: Create or Leverage the Minimum Business Architecture Baseline Content – If it does not already exist, create the following baseline content in the business architecture knowledgebase at a minimum:
  • Capability map (one that encompasses the whole enterprise scope).
  • Value streams (a core set of value streams, typically customer-facing, created at the enterprise level without business unit or product specificity).
  • Capabilities cross-mapped to value stream stages.
• Step 3: Capture Additional Content Needed For Analysis – Capture additional content in the knowledgebase for your analysis including:
  • Products Within Scope (this includes capturing product names and potentially categorizing them into families and / or lines) Cross-Mapped to Capabilities and Value Stream Stages.
  • Other Necessary Content in Scope (e.g. business units, objectives, initiatives, etc.) Cross-Mapped to Products.

P.S. Team up with your friends as needed to figure out this information (e.g. product managers for product information, application architects or owners for system application information).

• Step 4: Perform Your Analysis – Assess the information you have collected in support of your original goals (e.g. to perform impact analysis, identify areas for improvement, etc.).
• Step 5: Visualize the Results, Share Insights and Take Action – Finalize visuals, summarize insights and recommendations, and share with product managers, leaders and other team members as applicable. Work with the leaders and their teams to take action on the results.

One more thing. In order to “translate product strategies into a coordinate set of actionable initiatives,” we need to use business architecture more comprehensively as part of the strategy execution life cycle. More on how we do that way back in Post No. 3.

P.S. In the BIZBOK® Guide the definition / domain of “product” = products + services.

What’s the fine print?

Big one. The definition of “product” in business architecture must be for an external customer (or constituent or whatever you call the people who your organization serves). Products are not internal solutions or deliverables that are provided among people that work within the organization. Just like a “customer” in business architecture must be external, not another internal role within the organization. There are many aspects of business architecture that are flexible, but this is not one of them or our ability to have a common language and enterprise perspective falls apart.

As described in Step 2 above, you do need a minimum baseline of capabilities and value streams before your product mapping will be useful. However, there are ways to accelerate this, as described in Post No. 22.

And finally, good news, depending on the intent of your analysis, you may capture varying levels of detail in your product mapping. For example, you can just capture product family if that’s as much detail as you need for now versus all of the individual product names.

And, as always, here’s a handy summary of all of that for you.

Business Architecture in Action: Product Management At-A-Glance

Common Challenges

• Impacts to products (e.g. from strategies, capability changes, initiatives, etc.) may be hard to identify, especially across business units or product areas.
• Significant time and money may be spent on product ideas, designs and plans before realizing not to move forward.
• Common capabilities may not always be leveraged across products, leading to duplicate solutions.
• Business units and product areas may perform product management differently, leading to difficulty sharing best practices and creation of duplicate solutions.
• Product strategies may face common strategy execution challenges (e.g. diffusion, conflicting initiative scopes, etc.).
• People across business units and product areas may not have a consistent understanding of the product ecosystem, leading to ineffective communication and solutions.

Opportunities with Business Architecture

• Enable a broad set of bidirectional impact analysis related to products.
• Quickly narrow product investment decisions.
• Enable analysis and decision-making for product performance improvement.
• Provide a focal point for streamlining product management across the organization.
• Translate product strategies into a coordinated set of actionable initiatives.
• Create a shared mental model of the product ecosystem.

How We Do It

1. Identify Scope and Goals for Product-Related Analysis.
2. Create or Leverage the Minimum Business Architecture Baseline Content (capabilities, value streams and cross-mapping).
3. Capture Additional Content Needed For Analysis—

• Products Within Scope Cross-Mapped to Capabilities and Value Stream Stages
• Other Necessary Content in Scope (e.g. business units, objectives, initiatives) Cross-Mapped to Products.

4. Perform Your Analysis (e.g. to perform impact analysis, identify areas for improvement, etc.).
5. Visualize the Results, Share Insights and Take Action.

Considerations

• The definition of “product” in business architecture must be for an external customer.
• A baseline of capabilities and value streams are a pre-requisite before product mapping.
• Varying levels of detail may be captured for product mapping depending on the intended use.

Download Summary >

More Good Stuff…