Document Your Cloud Strategy

Get ready for the cloudy future with a consistent, proven strategy.

Analyst perspective

Any approach is better than no approach

Moving to the cloud is a big, scary transition, like moving from gas-powered to electric cars, or from cable to streaming, or even from the office to working from home. There are some undeniable benefits, but we must reorient our lives a bit to accommodate those changes, and the results aren’t always one-for-one. A strategy helps you make decisions about your future direction and how you should respond to changes and challenges. In Document Your Cloud Strategy we hope to help you accomplish just that: clarifying your overall mission and vision (as it relates to the cloud) and helping you develop an approach to changes in technology, people management, and, of course, governance. The cloud is not a panacea. Taken on its own, it will not solve your problems. But it can be an important tool in your IT toolkit, and you should aim to make the best use of it – whatever “best” happens to mean for you.

Jeremy Roberts

Research Director, Infrastructure and Operations

Info-Tech Research Group

Executive Summary

Your Challenge

The cloud is multifaceted. It can be complicated. It can be expensive. Everyone has an opinion on the best way to proceed – and in many cases has already begun the process without bothering to get clearance from IT. The core challenge is creating a coherent strategy to facilitate your overall goals while making the best use of cloud technology, your financial resources, and your people.

Common Obstacles

Despite the universally agreed-upon benefit of formulating a coherent strategy, several obstacles make execution difficult:

• Inconsistent understanding of what the cloud means
• Inability to come to a consensus on key decisions
• Ungoverned decision making
• Unclear understanding of cloud roles and responsibilities

Info-Tech’s Approach

A cloud strategy might seem like a big project, but it’s just a series of smaller conversations. The methodology presented here is designed to facilitate those conversations, using a curated list of topics, prompts, participant lists, and sample outcomes. We have divided the strategy into four key areas:

1. Vision and alignment
2. People
3. Governance
4. Technology

The answers might be different, but the questions are the same

Every organization will approach the cloud differently, but they all need to ask the same questions: When will we use the cloud? What forms will our cloud usage take? How will we manage governance? What will we do about people? How will we incorporate new technology into our environment? The answers to these questions are as numerous as there are people to answer them, but the questions must be asked.

Your challenge

This research is designed to help organizations that are facing these challenges or looking to:

• Ensure that the cloud strategy is complete and accurately reflects organizational goals and priorities.
• Develop a consistent and coherent approach to adopting cloud services.
• Design an approach to mitigate risks and challenges associated with adopting cloud services.
• Create a shared understanding of the expected benefits of cloud services and the steps required to realize those benefits.

Grappling with a cloud strategy is a top initiative: 43% of respondents report progressing on a cloud-first strategy as a top cloud initiative.

Source: Flexera, 2021.

Definition: Cloud strategy

A document providing a systematic overview of cloud services, their appropriate use, and the steps that an organization will take to maximize value and minimize risk.

Common obstacles

These barriers make this challenge difficult to address for many organizations:

• The cloud means different things to different people, and creating a strategy that is comprehensive enough to cover a multitude of use cases while also being written to be consumable by all stakeholders is difficult.
• The incentives to adopt the cloud differ based on the expected benefit for the individual customer. User-led decision making and historically ungoverned deployments can make it difficult to reset expectation and align with a formal strategy.
• Getting all the right people in a room together to agree on the key components of the strategy and the direction undertaken for each one is often difficult.

Info-Tech’s approach

Info-Tech’s approach

Your cloud strategy will comprise the elements listed under “vision and alignment,” “technology,” “governance,” and “people.” The Info-Tech methodology involves breaking the strategy down into subcomponents and going through a three-step process for each one. Start by reviewing a standard set of questions and understanding the goal of the exercise: What do we need to know? What are some common considerations and best practices? Once you’ve had a chance to review, discuss your current state and any gaps: What has been done? What still needs to be done? Finally, outline how you plan to go forward: What are your next steps? Who needs to be involved?

Review

• What questions do we need to answer to complete the discussion of this strategy component? What does the decision look like?
• What are some key terms and best practices we must understand before deciding?

Discuss

• What steps have we already taken to address this component?
• Does anything still need to be done?
• Is there anything we’re not sure about or need further guidance on?

Go forward

• What are the next steps?
• Who needs to be involved?
• What questions still need to be asked/answered?
• What should the document’s wording look like?

Info-Tech’s methodology for documenting your cloud strategy

Insight summary

Separate strategy from tactics

Separate strategy from tactics! A strategy requires building out the framework for ongoing decision making. It is meant to be high level and achieve a large goal. The outcome of a strategy is often a sense of commitment to the goal and better communication on the topic.

The cloud does not exist in a vacuum

Your cloud strategy flows from your cloud vision and should align with the broader IT strategy. It is also part of a pantheon of strategies and should exist harmoniously with other strategies – data, security, etc.

People problems needn’t preponderate

The cloud doesn’t have to be a great disruptor. If you handle the transition well, you can focus your people on doing more valuable work – and this is generally engaging.

Governance is a means to an end

Governing your deployment for its own sake will only frustrate your end users. Articulate the benefits users and the organization can expect to see and you’re more likely to receive the necessary buy-in.

Technology isn’t a panacea

Technology won’t solve all your problems. Technology is a force multiplier, but you will still have to design processes and train your people to fully leverage it.

Key deliverable

Cloud Strategy Document template

Inconsistency and informality are the enemies of efficiency. Capture the results of the cloud strategy generation exercises in the Cloud Strategy Document template.

• Record the results of the exercises undertaken as part of this blueprint in the Cloud Strategy Document template.
• It is important to remember that not every cloud strategy will look exactly the same, but this template represents an amalgamation of best practices and cloud strategy creation honed over several years of advisory service in the space.
• You know your audience better than anyone. If you would prefer a strategy delivered in a different way (e.g. presentation format) feel free to adapt the Cloud Vision Executive Presentation into a longer strategy presentation.
• Emphasis is an area where you should exercise discretion as well. A cost-oriented cloud strategy, or one that prioritizes one type of cloud (e.g. SaaS) at the exclusion of others, may benefit from more focus on some areas than others, or the introduction of relevant subcategories. Include as many of these as you think will be relevant.
• Parsimony is king – if you can distill a concept to its essence, start there. Include additional detail only as needed. You want your cloud strategy document to be read. If it’s too long or overly detailed, you’ll encounter readability issues.

Blueprint benefits

Measure the value of this blueprint

Don’t take our word for it:

• Document Your Cloud Strategy has been available for several years in various forms as both a workshop and as an analyst-led guided implementation.
• After each engagement, we send a survey that asks members how they benefited from the experience. Those who have worked through Info-Tech’s cloud strategy material have given overwhelmingly positive feedback.
• Additionally, members reported saving between 10 and 20 days and an average of $46,499.
• Measure the value by calculating the time saved as a result of using Info-Tech’s framework vs. a home-brewed cloud strategy alternative and by comparing the overall cost of a guided implementation or workshop with the equivalent offering from another firm. We’re confident you’ll come out ahead.

8.8/10 Average reported satisfaction

13 Days Average reported time savings

$46,499 Average cost savings

Executive Brief Case Study

INDUSTRY: Pharmaceuticals

SOURCE: Info-Tech workshop

Pharmaceutical company

The unnamed pharmaceutical company that is the subject of this case study was looking to make the transition to the cloud. In the absence of a coherent strategy, the organization had a few cloud deployments with no easily discernable overall approach. Representatives of several distinct functions (legal, infrastructure, data, etc.) all had opinions on the uses and abuses of cloud services, but it had been difficult to round everyone up and have the necessary conversations. As a result, the strategy exercise had not proceeded in a speedy or well-governed way. This lack of strategic readiness presented a roadblock to moving forward with the cloud strategy and to work with the cloud implementation partner, tasked with execution.

Results

The company engaged Info-Tech for a four-day workshop on cloud strategy documentation. Over the course of four days, participants drawn from across the organization discussed the strategic components and generated consensus statements and next steps. The team was able to formalize the cloud strategy and described the experience as saving 10 days.

Example output: Document your cloud strategy workshop exercise

Anything in green, the team was reasonably sure they had good alignment and next steps. Those yellow flags warranted more discussion and were not ready for documentation.

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

"Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful."

Guided Implementation

"Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track."

Workshop

"We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place."

Consulting

"Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project."

Diagnostics and consistent frameworks are used throughout all four options.

Guided Implementation

What does a typical GI on this topic look like?

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization. A typical GI is 4 to 6 calls over the course of 1 to 3 months

Workshop Overview

Contact your account representative for more information.

workshops@infotech.com 1-888-670-8889

Phase 1

Document Your Vision and Alignment

This phase will walk you through the following activities:

1. Record your cloud mission and vision
2. Document your cloud strategy’s alignment with other strategic plans
3. Record your cloud guiding principles
4. Define success

This phase has the following outcome:

• Documented strategy: vision and alignment

Record your mission and vision

Build on the work you’ve already done

Before formally documenting your cloud strategy, you should ensure that you have a good understanding of your overall cloud vision. How do you plan to leverage the cloud? What goals are you looking to accomplish? How will you distribute your workloads between different cloud service models (SaaS, PaaS, IaaS)? What will your preferred delivery model be (public, private, hybrid)? Will you support your cloud deployment internally or use the services of various consultants or managed service providers?

The answers to these questions will inform the first section of your cloud strategy. If you haven’t put much thought into this or think you could use a deep dive on the fundamentals of your cloud vision and cloud archetypes, consider reviewing Define Your Cloud Vision, the companion blueprint to this one.

Once you understand your cloud vision and what you’re trying to accomplish with your cloud strategy, this phase will walk you through aligning the strategy with other strategic initiatives. What decisions have others made that will impact the cloud strategy (or that the cloud strategy will impact)? Who must be involved/informed? What callouts must be involved at what point? Do users have access to the appropriate strategic documentation (and would they understand it if they did)?

You must also capture some guiding principles. A strategy by its nature provides direction, helping readers understand the decisions they should make and why those decisions align with organizational interests. Creating some top-level principles is a useful exercise because those principles facilitate comprehension and ensure the strategy’s applicability.

Finally, this phase will walk you through the process of measuring success. Once you know where you’d like to go, the principles that underpin your direction, and how your cloud strategy figures into the broader strategic pantheon, you should record what success actually means. If you’re looking to save money, overall cost should be a metric you track. If the cloud is all about productivity, generate appropriate productivity metrics. If you’re looking to expand into new technology or close a datacenter, you will need to track output specific to those overall goals.

Review: mission and vision

The overall organizational mission is a key foundational element of the cloud strategy. If you don’t understand where you’re going, how can you begin the journey to get there? This section of the strategy has four key parts that you should understand and incorporate into the beginning of the strategy document. If you haven’t already, review Define Your Cloud Vision for instructions on how to generate these elements.

Understand key cloud concepts: Archetype

Once you understand the value of the cloud, your workloads’ general suitability for the cloud, and your proposed risks and mitigations, the next step is to define your cloud archetype. Your organization’s cloud archetype is the strategic posture that IT adopts to best support the organization’s goals. Info-Tech’s model recognizes seven archetypes, divided into three high-level archetypes. After consultation with your stakeholders, and based on the results of the suitability and risk assessment activities, define your archetype. The archetype feeds into the overall cloud vision and provides simple insight into the cloud future state for all stakeholders. The cloud vision itself is captured in a “vision statement,” a short summary of the overall approach that includes the overall cloud archetype.

Deliver Digital Products at Scale

Deliver value at the scale of your organization through defining enterprise product families.

Analyst Perspective

Product families align enterprise goals to product changes and value realization.

Our world is changing faster than ever, and the need for business agility continues to grow. Organizations are shifting from long-term project delivery to smaller, iterative product delivery models to be able to embrace change and respond to challenges and opportunities faster.

Unfortunately, many organizations focus on product delivery at the tactical level. Product teams may be individually successful, but how well are their changes aligned to division and enterprise goals and priorities?

Grouping products into operationally aligned families is key to delivering the right value to the right stakeholders at the right time.

Product families translate enterprise goals, constraints, and priorities down to the individual product level so product owners can make better decisions and more effectively manage their roadmaps and backlogs. By scaling products into families and using product family roadmaps to align product roadmaps, product owners can deliver the capabilities that allow organizations to reach their goals.

In this blueprint, we’ll provide the tools and guidance to help you define what “product” means to your organization, use scaling patterns to build product families, align product and product family roadmaps, and identify impacts to your delivery and organizational design models.

Banu Raghuraman, Ari Glaizel, and Hans Eckman

Applications Practice

Info-Tech Research Group

Deliver Digital Products at Scale

Deliver value at the scale of your organization through defining enterprise product families.

EXECUTIVE BRIEF

Executive Summary

Your Challenge

• Products are the lifeblood of an organization. They deliver the capabilities needed to deliver value to customers, internal users, and stakeholders.
• The shift to becoming a product organization is intended to continually increase the value you provide to the broader organization as you grow and evolve.
• You need to clearly convey the direction and strategy of your product portfolio to gain alignment, support, and funding from your organization.

Common Obstacles

• IT organizations are traditionally organized to deliver initiatives in specific periods of time. This conflicts with product delivery, which continuously delivers value over the lifetime of a product.
• Delivering multiple products together creates additional challenges because each product has its own pedigree, history, and goals.
• Product owners struggle to prioritize changes to deliver product value. This creates a gap and conflict between product and enterprise goals.

Info-Tech’s Approach

Info-Tech’s approach will guide you through:

• Understanding the importance of product families in scaling product delivery.
• Defining products in your context and organizing products into operational families.
• Using product family roadmaps to align product roadmaps to enterprise goals and priorities.
• Evaluating the different approaches to improve your product family delivery pipelines and milestones.

Info-Tech Insight

Changes can only be made at the individual product or service level. To achieve enterprise goals and priorities, organizations needed to organize and scale products into operational families. This structure allows product managers to translate goals and constraints to the product level and allows product owners to deliver changes that support enabling capabilities. In this blueprint, we’ll help you define your products, scale them using the best patterns, and align your roadmaps and delivery models to improve throughput and value delivery.

Info-Tech’s approach

Operationally align product delivery to enterprise goals

The Info-Tech difference:

1. Start by piloting product families to determine which approaches work best for your organization.
2. Create a common definition of what a product is and identify products in your inventory.
3. Use scaling patterns to build operationally aligned product families.
4. Develop a roadmap strategy to align families and products to enterprise goals and priorities.
5. Use products and families to evaluate delivery and organizational design improvements.

Deliver Digital Products at Scale via Enterprise Product Families

Product does not mean the same thing to everyone

Do not expect a universal definition of products.

Every organization and industry has a different definition of what a product is. Organizations structure their people, processes, and technologies according to their definition of the products they manage. Conflicting product definitions between teams increase confusion and misalignment of product roadmaps.

“A product [is] something (physical or not) that is created through a process and that provides benefits to a market.”

- Mike Cohn, Founding Member of Agile Alliance and Scrum Alliance

“A product is something ... that is created and then made available to customers, usually with a distinct name or order number.”

- TechTarget

“A product is the physical object ... , software or service from which customer gets direct utility plus a number of other factors, services, and perceptions that make the product useful, desirable [and] convenient.”

- Mark Curphey

Organizations need a common understanding of what a product is and how it pertains to the business. This understanding needs to be accepted across the organization.

“There is not a lot of guidance in the industry on how to define [products]. This is dangerous because what will happen is that product backlogs will be formed in too many areas. All that does is create dependencies and coordination across teams … and backlogs.”

– Chad Beier, "How Do You Define a Product?” Scrum.org

What is a product?

“A tangible solution, tool, or service (physical or digital) that enables the long-term and evolving delivery of value to customers and stakeholders based on business and user requirements.”

Info-Tech Insight

A proper definition of product recognizes three key facts:

1. Products are long-term endeavors that don’t end after the project finishes.
2. Products are not just “apps” but can be software or services that drive the delivery of value.
3. There is more than one stakeholder group that derives value from the product or service.

Products and services share the same foundation and best practices

For the purpose of this blueprint, product/service and product owner/service owner are used interchangeably. Product is used for consistency but would apply to services as well.

Product = Service

“Product” and “service” are terms that each organization needs to define to fit its culture and customers (internal and external). The most important aspect is consistent use and understanding of:

• External products
• Internal products
• External services
• Internal services
• Products as a service (PaaS)
• Productizing services (SaaS)

Recognize the different product owner perspectives

Business:

• Customer facing, revenue generating

Technical:

• IT systems and tools

Operations:

• Keep the lights on processes

Info-Tech Best Practice

Product owners must translate needs and constraints from their perspective into the language of their audience. Kathy Borneman, Digital Product Owner at SunTrust Bank, noted the challenges of finding a common language between lines of business and IT (e.g. what is a unit?).

Info-Tech Insight

Recognize that product owners represent one of three primary perspectives. Although all share the same capabilities, how they approach their responsibilities is influenced by their perspective.

“A Product Owner in its most beneficial form acts like an Entrepreneur, like a 'mini-CEO'. The Product Owner is someone who really 'owns' the product.”

– Robbin Schuurman, “Tips for Starting Product Owners”

Identify the differences between a project-centric and a product-centric organization

Info-Tech Insight

Product delivery requires significant shifts in the way you complete development work and deliver value to your users. Make the changes that support improving end-user value and enterprise alignment.

Projects can be a mechanism for delivering product changes and improvements

Projects within products

Regardless of whether you recognize yourself as a product-based or project-based shop, the same basic principles should apply. The purpose of projects is to deliver the scope of a product release. The shift to product delivery leverages a product roadmap and backlog as the mechanism for defining and managing the scope of the release. Eventually, teams progress to continuous integration/continuous delivery (CI/CD) where they can release on demand or as scheduled, requiring org change management.

Define product value by aligning backlog delivery with roadmap goals

In each product plan, the backlogs show what you will deliver. Roadmaps identify when and in what order you will deliver value, capabilities, and goals.

Product roadmaps guide delivery and communicate your strategy

In Deliver on Your Digital Product Vision, we demonstrate how the product roadmap is core to value realization. The product roadmap is your communicated path, and as a product owner, you use it to align teams and changes to your defined goals while aligning your product to enterprise goals and strategy.

Adapted from: Pichler, "What Is Product Management?""

Info-Tech Insight

The quality of your product backlog – and your ability to realize business value from your delivery pipeline – is directly related to the input, content, and prioritization of items in your product roadmap.

Use Agile DevOps principles to expedite product-centric delivery and management

Delivering products does not necessarily require an Agile DevOps mindset. However, Agile methods facilitate the journey because product thinking is baked into them.

Based on: Ambysoft, 2018

Organizations start with Waterfall to improve the predictable delivery of product features.

Iterative development shifts the focus from delivery of features to delivery of user value.

Agile further shifts delivery to consider ROI. Often, the highest-value backlog items aren’t the ones with the highest ROI.

Lean and DevOps improve your delivery pipeline by providing full integration between product owners, development teams, and operations.

CI/CD reduces time in process by allowing release on demand and simplifying release and support activities.

Although teams will adopt parts of all these stages during their journey, it isn’t until you’ve adopted a fully integrated delivery chain that you’ve become product centric.

Scale products into related families to improve value delivery and alignment

Defining product families builds a network of related products into coordinated value delivery streams.

“As with basic product management, scaling an organization is all about articulating the vision and communicating it effectively. Using a well-defined framework helps you align the growth of your organization with that of the company. In fact, how the product organization is structured is very helpful in driving the vision of what you as a product company are going to do.”

– Rich Mironov, Mironov Consulting

Product families translate enterprise goals into value-enabling capabilities

Info-Tech Insight

Your organizational goals and strategy are achieved through capabilities that deliver value. Your product hierarchy is the mechanism to translate enterprise goals, priorities, and constraints down to the product level where changes can be made.

Arrange product families by operational groups, not solely by your org chart

1. To align product changes with enterprise goals and priorities, you need to organize your products into operational groups based on the capabilities or business functions the product and family support.

2. Product managers translate these goals, priorities, and constraints into their product families, so they are actionable at the next level, whether that level is another product family or products implementing enhancements to meet these goals.

3. The product family manager ensures that the product changes enhance the capabilities that allow you to realize your product family, division, and enterprise goals.

4. Enabling capabilities realize value and help reach your goals, which then drives your next set of enterprise goals and strategy.

Approach alignment from both directions, validating by the opposite way

Defining your product families is not a one-way street. Often, we start from either the top or the bottom depending on our scaling principles. We use multiple patterns to find the best arrangement and grouping of our products and families.

It may be helpful to work partway, then approach your scaling from the opposite direction, meeting in the middle. This way you are taking advantage of the strengths in both approaches.

Once you have your proposed structure, validate the grouping by applying the principles from the opposite direction to ensure each product and family is in the best starting group.

As the needs of your organization change, you may need to realign your product families into your new business architecture and operational structure.

When to use: You have a business architecture defined or clear market/functional grouping of value streams.

When to use: You are starting from an Application Portfolio Management application inventory to build or validate application families.

Leverage patterns for scaling products

Organizing your products and families is easier when leveraging these grouping patterns. Each is explained in greater detail on the following slides

Leverage the product family roadmap for alignment

It’s more than a set of colorful boxes. It’s the map to align everyone to where you are going.

Your product family roadmap

✓ Lays out a strategy for your product family.

✓ Is a statement of intent for your family of products.

✓ Communicates direction for the entire product family and product teams.

✓ Directly connects to the organization’s goals.

However, it is not:

x Representative of a hard commitment.

x A simple combination of your current product roadmaps.

Before connecting your family roadmap to products, think about what each roadmap typically presents

Info-Tech Insight

Your product family roadmap and product roadmap tell different stories. The product family roadmap represents the overall connection of products to the enterprise strategy, while the product roadmap focuses on the fulfillment of the product’s vision.

Product family roadmaps are more strategic by nature

While individual product roadmaps can be different levels of tactical or strategic depending on a variety of market factors, your options are more limited when defining roadmaps for product families.

Product

TACTICAL

A roadmap that is technical, committed, and detailed.

Product Family

STRATEGIC

A roadmap that is strategic, goal based, high level, and flexible.

Info-Tech Insight

Roadmaps for your product family are, by design, less detailed. This does not mean they aren’t actionable! Your product family roadmap should be able to communicate clear intentions around the future delivery of value in both the near and long term.

Consider volatility when structuring product family roadmaps

There is no such thing as a roadmap that never changes.

Your product family roadmap represents a broad statement of intent and high-level tactics to get closer to the organization’s goals.

All good product family roadmaps embrace change!

Your strategic intentions are subject to volatility, especially those planned further in the future. The more costs you incur in planning, the more you leave yourself exposed to inefficiency and waste if those plans change.

Info-Tech Insight

A good product family roadmap is intended to manage and communicate the inevitable changes as a result of market volatility and changes in strategy.

Product delivery realizes value for your product family

While planning and analysis are done at the family level, work and delivery are done at the individual product level.

Typical elements of a product family roadmap

While there are others, these represent what will commonly appear across most family-based roadmaps.

GROUP/CATEGORY: Groups are collections of artifacts. In a product family context, these are usually product family goals, value streams, or products.

ARTIFACT: An artifact is one of many kinds of tangible by-products produced during the delivery of products. For a product family, the artifacts represented are capabilities or value streams.

MILESTONE: Points in the timeline when established sets of artifacts are complete. This is a critical tool in the alignment of products in a given family.

TIME HORIZON: Separated periods within the projected timeline covered by the roadmap.

Connecting your product family roadmaps to product roadmaps

Your product and product family roadmaps should be connected at an artifact level that is common between both. Typically, this is done with capabilities, but it can be done at a more granular level if an understanding of capabilities isn’t available.

Multiple roadmap views can communicate differently, yet tell the same truth

Your communication objectives are linked to your audience; ensure you know your audience and speak their language

Assess the impacts of product-centric delivery on your teams and org design

Product delivery can exist within any org structure or delivery model. However, when making the shift toward product management, consider optimizing your org design and product team structure to match your capacity and throughput needs.

Determine which delivery team structure best fits your product pipeline

Weigh the pros and cons of IT operating models to find the best fit

There are many different operating models. LoB/Product Aligned and Hybrid Functional align themselves most closely with how products and product families are typically delivered.

1. LoB/Product Aligned – Decentralized Model: Line of Business, Geographically, Product, or Functionally Aligned

A decentralized IT operating model that embeds specific functions within LoBs/product teams and provides cross-organizational support for their initiatives.

2. Hybrid Functional: Functional/Product Aligned

A best-of-both-worlds model that balances the benefits of centralized and decentralized approaches to achieve both customer responsiveness and economies of scale.

3. Hybrid Service Model: Product-Aligned Operating Model

A model that supports what is commonly referred to as a matrix organization, organizing by highly related service categories and introducing the role of the service owner.

4. Centralized: Plan-Build-Run

A highly typical IT operating model that focuses on centralized strategic control and oversight in delivering cost-optimized and effective solutions.

5. Centralized: Demand-Develop-Service

A centralized IT operating model that lends well to more mature operating environments. Aimed at leveraging economies of scale in an end-to-end services delivery model.

Consider how investment spending will differ in a product environment

Reward for delivering outcomes, not features

Adapted from Bain, 2019

Info-Tech Insight

Changes to funding require changes to product and Agile practices to ensure product ownership and accountability.

Why is having a common value measure important?

CIO-CEO Alignment Diagnostic

Over 700 Info-Tech members have implemented the Balanced Value Measurement Framework.

“The cynic knows the price of everything and the value of nothing.”

– Oscar Wilde

“Price is what you pay. Value is what you get.”

– Warren Buffett

Understanding where you derive value is critical to building solid roadmaps.

Measure delivery and success

Metrics and measurements are powerful tools to drive behavior change and decision making in your organization. However, metrics are highly prone to creating unexpected outcomes, so use them with great care. Use metrics judiciously to uncover insights but avoid gaming or ambivalent behavior, productivity loss, and unintended consequences.

Build good practices in your selection and use of metrics:

• Choose the metrics that are as close to measuring the desired outcome as possible.
• Select the fewest metrics possible and ensure they are of the highest value to your team, the safest from gaming behaviors and unintended consequences, and the easiest to gather and report.
• Never use metrics for reward or punishment; use them to develop your team.
• Automate as much metrics gathering and reporting as possible.
• Focus on trends rather than precise metrics values.
• Review and change your metrics periodically.

Executive Brief Case Study

INDUSTRY: Public Sector & Financial Services

SOURCE: Info-Tech Interviews

A tale of two product transformations

Two of the organizations we interviewed shared the challenges they experienced defining product families and the impact these challenges had on their digital transformations.

A major financial services organization (2,000+ people in IT) had employed a top-down line of business–focused approach and found itself caught in a vicious circle of moving applications between families to resolve cross-LoB dependencies.

A similarly sized public sector organization suffered from a similar challenge as grouping from the bottom up based on technology areas led to teams fragmented across multiple business units employing different applications built on similar technology foundations.

Results

Both organizations struggled for over a year to structure their product families. This materially delayed key aspects of their product-centric transformation, resulting in additional effort and expenditure delivering solutions piecemeal as opposed to as a part of a holistic product family. It took embracing a hybrid top-down and bottom-up approach and beginning with pilot product families to make progress on their transformation.

Cole Cioran

Practice Lead,

Applications Practice

Info-Tech Research Group

There is no such thing as a perfect product-family structure. There will always be trade-offs when you need to manage shifting demand from stakeholder groups spanning customers, business units, process owners, and technology owners.

Focusing on a single approach to structure your product families inevitably leads to decisions that are readily challenged or are brittle in the face of changing demand.

The key to accelerating a product-centric transformation is to build a hybrid model that embraces top-down and bottom-up perspectives to structure and evolve product families over time. Add a robust pilot to evaluate the structure and you have the key to unlocking the potential of product delivery in your organization.

Info-Tech’s methodology for Deliver Digital Products at Scale

Blueprint deliverables

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:

Deliver Digital Products at Scale Workbook

Use this supporting workbook to document interim results from a number of exercises that will contribute to your overall strategy.

Deliver Digital Products at Scale Readiness Assessment

Your strategy needs to encompass your approaches to delivery. Understand where you need to focus using this simple assessment.

Key deliverable:

Digital Product Family Strategy Playbook

Record the results from the exercises to help you define, detail, and deliver digital products at scale.

Blueprint benefits

Measure the value of this blueprint

Align product family metrics to product delivery and value realization.

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

"Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful."

Guided Implementation

"Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keeps us on track."

Workshop

"We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place."

Consulting

"Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project."

Diagnostics and consistent frameworks are used throughout all four options.

Guided Implementation

What does a typical GI on this topic look like?

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization. A typical GI is between 8 to 12 calls over the course of 4 to 6 months.

Workshop Overview

Contact your account representative for more information.

workshops@infotech.com 1-888-670-8889

Phase 1

Become a Product-Centric Organization

This phase will walk you through the following activities:

1.1.1 Understand your drivers for product-centric delivery

1.1.2 Identify the differences between project and product delivery

1.1.3 Define the goals for your product-centric organization

1.2.1 Define “product” in your context

1.2.2 Identify and establish a pilot list of products

This phase involves the following participants:

• Product owners
• Product managers
• Development team leads
• Portfolio managers’
• Business analysts

Step 1.1

Understand the organizational factors driving product-centric delivery

Activities

1.1.1 Understand your drivers for product-centric delivery

1.1.2 Identify the differences between project and product delivery

1.1.3 Define the goals for your product-centric organization

This phase involves the following participants:

• Product owners
• Product managers
• Development team leads
• Portfolio managers’
• Business analysts

Outcomes of this step

• Organizational drivers to move to product-centric delivery
• List of differences between project and product delivery
• Goals for product-centric delivery

1.1.1 Understand your drivers for product-centric delivery

30-60 minutes

1. Identify your pain points in the current delivery model.
2. What is the root cause of these pain points?
3. How will a product-centric delivery model fix the root cause?
4. Record the results in the Deliver Digital Products at Scale Workbook.

Output

• Organizational drivers to move to product-centric delivery.

Participants

• Product owners
• Product managers
• Development team leads
• Portfolio managers
• Business analysts

Record the results in the Deliver Digital Products at Scale Workbook.

1.1.2 Identify the differences between project and product delivery

30-60 minutes

1. Consider project delivery and product delivery.
2. Discuss what some differences are between the two.

Note: This exercise is not about identifying the advantages and disadvantages of each style of delivery. This is to identify the variation between the two.

3. Record the results in the Deliver Digital Products at Scale Workbook.

Output

• List of differences between project and product delivery

Participants

• Product owners
• Product managers
• Development team leads
• Portfolio managers
• Business analysts

Record the results in the Deliver Digital Products at Scale Workbook.

Identify the differences between a project-centric and a product-centric organization

Info-Tech Insight

Product delivery requires significant shifts in the way you complete development work and deliver value to your users. Make the changes that support improving end-user value and enterprise alignment.

Projects can be a mechanism for funding product changes and improvements

Projects within products

Regardless of whether you recognize yourself as a product-based or project-based shop, the same basic principles should apply.

The purpose of projects is to deliver the scope of a product release. The shift to product delivery leverages a product roadmap and backlog as the mechanism for defining and managing the scope of the release.

Eventually, teams progress to continuous integration/continuous delivery (CI/CD) where they can release on demand or as scheduled, requiring org change management.

Use Agile DevOps principles to expedite product-centric delivery and management

Delivering products does not necessarily require an Agile DevOps mindset. However, Agile methods facilitate the journey because product thinking is baked into them.

Based on: Ambysoft, 2018

Organizations start with Waterfall to improve the predictable delivery of product features.

Iterative development shifts the focus from delivery of features to delivery of user value.

Agile further shifts delivery to consider ROI. Often, the highest-value backlog items aren’t the ones with the highest ROI.

Lean and DevOps improve your delivery pipeline by providing full integration between product owners, development teams, and operations.

CI/CD reduces time in process by allowing release on demand and simplifying release and support activities.

Although teams will adopt parts of all these stages during their journey, it isn’t until you’ve adopted a fully integrated delivery chain that you’ve become product centric.

1.1.3 Define the goals for your product-centric organization

30 minutes

1. Review your list of drivers from exercise 1.1.1 and the differences between project and product delivery from exercise 1.1.2.
2. Define your goals for achieving a product-centric organization.

Note: Your drivers may have already covered the goals. If so, review if you would like to change the drivers based on your renewed understanding of the differences between project and product delivery.

Output

• Goals for product-centric delivery

Participants

• Product owners
• Product managers
• Development team leads
• Portfolio managers’
• Business analysts

Record the results in the Deliver Digital Products at Scale Workbook.

Step 1.2

Establish your organization’s product inventory

Activities

1.2.1 Define “product” in your context

1.2.2 Identify and establish a pilot list of products

This step involves the following participants:

• Product owners
• Product managers
• Development team leads
• Portfolio managers’
• Business analysts

Outcomes of this step

• Your organizational definition of products and services
• A pilot list of active products

Product does not mean the same thing to everyone

Do not expect a universal definition of products.

Every organization and industry has a different definition of what a product is. Organizations structure their people, processes, and technologies according to their definition of the products they manage. Conflicting product definitions between teams increase confusion and misalignment of product roadmaps.

“A product [is] something (physical or not) that is created through a process and that provides benefits to a market.”

- Mike Cohn, Founding Member of Agile Alliance and Scrum Alliance

“A product is something ... that is created and then made available to customers, usually with a distinct name or order number.”

- TechTarget

“A product is the physical object ... , software or service from which customer gets direct utility plus a number of other factors, services, and perceptions that make the product useful, desirable [and] convenient.”

- Mark Curphey

Organizations need a common understanding of what a product is and how it pertains to the business. This understanding needs to be accepted across the organization.

“There is not a lot of guidance in the industry on how to define [products]. This is dangerous because what will happen is that product backlogs will be formed in too many areas. All that does is create dependencies and coordination across teams … and backlogs.”

– Chad Beier, "How Do You Define a Product?” Scrum.org

Products and services share the same foundation and best practices

For the purpose of this blueprint, product/service and product owner/service owner are used interchangeably. Product is used for consistency but would apply to services as well.

Product = Service

“Product” and “service” are terms that each organization needs to define to fit its culture and customers (internal and external). The most important aspect is consistent use and understanding of:

• External products
• Internal products
• External services
• Internal services
• Products as a service (PaaS)
• Productizing services (SaaS)

Recognize the different product owner perspectives

Business:

• Customer facing, revenue generating

Technical:

• IT systems and tools

Operations

• Keep the lights on processes

Info-Tech Best Practice

Product owners must translate needs and constraints from their perspective into the language of their audience. Kathy Borneman, Digital Product Owner at SunTrust Bank, noted the challenges of finding a common language between lines of business and IT (e.g. what is a unit?).

Info-Tech Insight

Recognize that product owners represent one of three primary perspectives. Although all share the same capabilities, how they approach their responsibilities is influenced by their perspective.

“A Product Owner in its most beneficial form acts like an Entrepreneur, like a 'mini-CEO'. The Product Owner is someone who really 'owns' the product.”

– Robbin Schuurman, “Tips for Starting Product Owners”

Your product definition should include everything required to support it, not just what users see.

Establish where product management would be beneficial in the organization

What does not need product ownership?

• Individual features
• Transactions
• Unstructured data
• One-time solutions
• Non-repeatable processes
• Solutions that have no users or consumers
• People or teams

Characteristics of a discrete product

• Has end users or consumers
• Delivers quantifiable value
• Evolves or changes over time
• Has predictable delivery
• Has definable boundaries
• Has a cost to produce and operate

Product capabilities deliver value!

These are the various facets of a product. As a product owner, you are responsible for managing these facets through your capabilities and activities.

It is easy to lose sight of what matters when we look at a product from a single point of view. Despite what The Agile Manifesto says, working software is not valuable without the knowledge and support that people need in order to adopt, use, and maintain it. If you build it, they will not come. Product leaders must consider the needs of all stakeholders when designing and building products.

Define product value by aligning backlog delivery with roadmap goals

In each product plan, the backlogs show what you will deliver. Roadmaps identify when and in what order you will deliver value, capabilities, and goals.

Product roadmaps guide delivery and communicate your strategy

In Deliver on Your Digital Product Vision, we demonstrate how the product roadmap is core to value realization. The product roadmap is your communicated path, and as a product owner, you use it to align teams and changes to your defined goals while aligning your product to enterprise goals and strategy.

Info-Tech Insight

The quality of your product backlog – and your ability to realize business value from your delivery pipeline – is directly related to the input, content, and prioritization of items in your product roadmap.

What is a product?

Not all organizations will define products in the same way. Take this as a general example:

“A tangible solution, tool, or service (physical or digital) that enables the long-term and evolving delivery of value to customers and stakeholders based on business and user requirements.”

Info-Tech Insight

A proper definition of product recognizes three key facts:

1. Products are long-term endeavors that don’t end after the project finishes.
2. Products are not just “apps” but can be software or services that drive the delivery of value.

There is more than one stakeholder group that derives value from the product or service.

1.2.1 Define “product” in your context

30-60 minutes

1. Discuss what “product” means in your organization.
2. Create a common, enterprise-wide definition for “product.”
3. Record the results in the Deliver Digital Products at Scale Workbook.

For example:

• An application, platform, or application family.
• Discrete items that deliver value to a user/customer.

Output

• Your enterprise/organizational definition of products and services

Participants

• Product owners
• Product managers
• Development team leads
• Portfolio managers’
• Business analysts

Record the results in the Deliver Digital Products at Scale Workbook.

1.2.2 Identify and establish a pilot list of products

1-2 hours

1. Review any current documented application inventory. If you have these details in an existing document, share it with the team. Select the group of applications for your family scaling pilot.
2. List your initial application inventory on the Product List tab of the Deliver Digital Products at Scale Workbook.

• If you previously completed an application inventory using one of our application portfolio management (APM) resources, you can paste values here. Do not paste cells, as Excel may create a cell reference or replace the current conditional formatting.
• Application Portfolio Snapshot service – Fast alignment of applications to capabilities/departments
• Application Portfolio Management for Small Enterprises – Simplified APM journey in one blueprint
• Discover Your Applications – First step in our three-step approach to managing applications in use
• Implement Software Asset Management – Go beyond tracking licenses to proactively managing software throughout its lifecycle

Output

• A pilot list of active products

Participants

• Product owners
• Product managers
• Development team leads
• Portfolio managers’
• Business analysts

Record the results in the Deliver Digital Products at Scale Workbook.

Phase 2

Organize Products Into Product Families

This phase will walk you through the following activities:

2.1.1 Define your scaling principles and goals

2.1.2 Define your pilot product family areas and direction

2.2.1 Arrange your applications and services into product families

2.2.2 Define enabling and supporting applications

2.2.3 Build your product family canvas

This phase involves the following participants:

• Product owners
• Product managers
• Development team leads
• Portfolio managers’
• Business analysts

Step 2.1

Determine your approach to scale product families

Activities

2.1.1 Define your scaling principles and goals

2.1.2 Define your pilot product family areas and direction

This step involves the following participants:

• Product owners
• Product managers
• Development team leads
• Portfolio managers’
• Business analysts

Outcomes of this step

• List of product scaling principles
• Scope of product scaling pilot and target areas
• Scaling approach and direction

Use consistent terminology for product and service families

In this blueprint, we refer to any grouping of products or services as a “family.” Your organization may prefer other terms, such as product/service line, portfolio, group, etc. The underlying principles for grouping and managing product families are the same, so define the terminology that fits best with your culture. The same is true for “products” and “services,” which may also be referred to in different terms.

A product family is a logical and operational grouping of related products or services. The grouping provides a scaled hierarchy to translate goals, priorities, strategy, and constraints down the grouping while aligning value realization upwards.

Group product families by related purpose to improve business value

Families should be scaled by how the products operationally relate to each other, with clear boundaries and common purpose.

A product family contains...

• Vision
• Goals
• Cumulative roadmap of the products within the family

A product family can be grouped by...

• Function
• Value stream and capability
• Customer segments or end-user group
• Strategic purpose
• Underlying architecture
• Common technology or support structures
• And many more

Scale products into related families to improve value delivery and alignment

Defining product families builds a network of related products into coordinated value delivery streams.

“As with basic product management, scaling an organization is all about articulating the vision and communicating it effectively. Using a well-defined framework helps you align the growth of your organization with that of the company. In fact, how the product organization is structured is very helpful in driving the vision of what you as a product company are going to do.”

– Rich Mironov, Mironov Consulting

Product families translate enterprise goals into value-enabling capabilities

Info-Tech Insight

Your organizational goals and strategy are achieved through capabilities that deliver value. Your product hierarchy is the mechanism to translate enterprise goals, priorities, and constraints down to the product level where changes can be made.

Arrange product families by operational groups, not solely by your org chart

1. To align product changes with enterprise goals and priorities, you need to organize your products into operational groups based on the capabilities or business functions the product and family support.

2. Product managers translate these goals, priorities, and constraints into their product families, so they are actionable at the next level, whether that level is another product family or products implementing enhancements to meet these goals.

3. The product family manager ensures that the product changes enhance the capabilities that allow you to realize your product family, division, and enterprise goals.

4. Enabling capabilities realize value and help reach your goals, which then drives your next set of enterprise goals and strategy.

Product families need owners with a more strategic focus

Product Owner

(More tactical product delivery focus)

• Backlog management and prioritization
• Product vision and product roadmap
• Epic/story definition, refinement in conjunction with business stakeholders
• Sprint planning with Scrum Master and delivery team
• Working with Scrum Master to minimize disruption to team velocity
• Ensuring alignment between business and Scrum teams during sprints
• Profit and loss (P&L) product analysis and monitoring

Product Manager

(More strategic product family focus)

• Product strategy, positioning, and messaging
• Product family vision and product roadmap
• Competitive analysis and positioning
• New product innovation/definition
• Release timing and focus (release themes)
• Ongoing optimization of product-related marketing and sales activities
• P&L product analysis and monitoring

Info-Tech Insight

“Product owner” and “product manager” are terms that should be adapted to fit your culture and product hierarchy. These are not management relationships but rather a way to structure related products and services that touch the same end users. Use the terms that work best in your culture.

Download Build a Better Product Owner for role support.

2.1.1 Define your scaling principles and goals

30-60 minutes

1. Discuss the guiding principles for your product scaling model. Your guiding principles should consider key business priorities, organizational culture, and division/team objectives, such as improving:

• Business agility and ability to respond to changes and needs.
• Alignment of product roadmaps to enterprise goals and priorities.
• Collaboration between stakeholders and product delivery teams.
• Resource utilization and productivity.
• The quality and value of products.
• Coordination between related products and services.

Output

• List of product scaling principles

Participants

• Product owners
• Product managers
• Development team leads
• Portfolio managers’
• Business analysts

Record the results in the Deliver Digital Products at Scale Workbook.

Start scaling with a pilot

You will likely use a combination of patterns that work best for each product area. Pilot your product scaling with a domain, team, or functional area before organizing your entire portfolio.

Learn more about each pattern.

Discuss the pros and cons of each.

Select a pilot product area.

Select a pattern.

Approach alignment from both directions, validating by the opposite way

Defining your product families is not a one-way street. Often, we start from either the top or the bottom depending on our scaling principles. We use multiple patterns to find the best arrangement and grouping of our products and families.

It may be helpful to work partway, then approach your scaling from the opposite direction, meeting in the middle. This way you are taking advantage of the strengths in both approaches.

Once you have your proposed structure, validate the grouping by applying the principles from the opposite direction to ensure each product and family is in the best starting group.

As the needs of your organization change, you may need to realign your product families into your new business architecture and operational structure.

When to use: You have a business architecture defined or clear market/functional grouping of value streams.

When to use: You are starting from an Application Portfolio Management application inventory to build or validate application families.

Top-down examples: Start with your enterprise structure or market grouping

Examples:

Bottom-up examples: Start with your inventory

Based on your current inventory, start organizing products and services into related groups using one of the five scaling models discussed in the next step.

Examples:

2.1.2 Define your pilot product family areas and direction

30-60 minutes

1. Using your inventory of products for your pilot, consider the top-down and bottom-up approaches.
2. Identify areas where you will begin arranging your product into families.
3. Prioritize these pilot areas into waves:
1. First pilot areas
2. Second pilot areas
3. Third pilot areas
4. Discuss and decide whether a top-down or bottom-up approach is the best place to start for each pilot group.
5. Prioritize your pilot families in the order in which you want to organize them. This is a guide to help you get started, and you may change the order during the scaling pattern exercise.

Output

• Scope of product scaling pilot and target areas

Participants

• Product owners
• Product managers
• Development team leads
• Portfolio managers’
• Business analysts

Record the results in the Deliver Digital Products at Scale Workbook.

Step 2.2

Define your product families

Activities

2.2.1 Arrange your applications and services into product families

2.2.2 Define enabling and supporting applications

2.2.3 Build your product family canvas

This step involves the following participants:

• Product owners
• Product managers
• Development team leads
• Portfolio managers’
• Business analysts

Outcomes of this step

• Product family mapping
• Product families
• Enabling applications
• Dependent applications
• Product family canvas

Use three perspectives to guide scaling pattern selection

Leverage patterns for scaling products

Organizing your products and families is easier when leveraging these grouping patterns. Each is explained in greater detail on the following slides

Select the best family pattern to improve alignment

Use scenarios to help select patterns

Pattern: Value Stream – Capability

Grouping products into capabilities defined in your business architecture is recommended because it aligns people/processes (services) and products (tools) into their value stream and delivery grouping. This requires an accurate capability map to implement.

Example:

• Healthcare is delivered through a series of distinct value streams (top chevrons) and shared services supporting all streams.
• Diagnosing Health Needs is executed through the Admissions, Testing, Imaging, and Triage capabilities.
• Products and services are needed to deliver each capability.
• Shared capabilities can also be grouped into families to better align capability delivery and maturity to ensure that the enterprise goals and needs are being met in each value stream the capabilities support.

Sample business architecture/ capability map for healthcare

Your business architecture maps your value streams (value delivered to your customer or user personas) to the capabilities that deliver that value. A capability is the people, processes, and/or tools needed to deliver each value function.

Defining capabilities are specific to a value stream. Shared capabilities support multiple value streams. Enabling capabilities are core “keep the lights on” capabilities and enterprise functions needed to run your organization.

See Info-Tech’s industry coverage and reference architectures.

Download Document Your Business Architecture

Pattern: Value Stream – Market

Market/Customer Segment Alignment focuses products into the channels, verticals, or market segments in the same way customers and users view the organization.

Example:

• Customers want one stop to solve all their issues, needs, and transactions.
• Banking includes consumer, small business, and enterprise.
• Consumer banking can be grouped by type of financial service: deposit accounts (checking, savings, money market), revolving credit (credit cards, lines of credit), term lending (mortgage, auto, installment).
• Each group of services has a unique set of applications and services that support the consumer product, with some core systems supporting the entire relationship.

Pattern: Value Stream – Line of Business (LoB)

Line of Business Alignment uses the operational structure as the basis for organizing products and services into families that support each area.

Example:

• LoB alignment favors continuity of services, tools, and skills based on internal operations over unified customer services.
• A hospital requires care and services from many different operational teams.
• Emergency services may be internally organized by the type of care and emergency to allow specialized equipment and resources to diagnose and treat the patients, relying on support teams for imaging and diagnostics to support care.
• This model may be efficient and logical from an internal viewpoint but can cause gaps in customer services without careful coordination between product teams.

Pattern: Enterprise Applications

A division or group delivers enabling capabilities, and the team’s operational alignment maps directly to the modules/components of an enterprise application and other applications that support the specific business function.

Example:

• Human resources is one corporate function. Within HR, however, there are subfunctions that operate independently.
• Each operational team is supported by one or more applications or modules within a primary HR system.
• Even though the teams work independently, the information they manage is shared with or ties into processes used by other teams. Coordination of efforts helps provide a higher level of service and consistency.

For additional information about HRMS, please download Get the Most Out of Your HRMS.

Pattern: Shared Services

Grouping by service type, knowledge area, or technology allows for specialization while families align service delivery to shared business capabilities.

Example:

• Recommended for governance, risk, and compliance; infrastructure; security; end-user support; and shared platforms (workflow, collaboration, imaging/record retention). Direct hierarchies do not necessarily exist within the shared service family.
• Service groupings are common for service owners (also known as support managers, operations managers, etc.).
• End-user ticketing comes through a common request system, is routed to the team responsible for triage, and then is routed to a team for resolution.
• Collaboration tools and workflow tools are enablers of other applications, and product families might support multiple apps or platforms delivering that shared capability.

Pattern: Technical

Technical grouping is used in Shared Services or as a family grouping method within a Value Stream Alignment (Capability, Market, LoB) product family.

Example:

• Within Shared Services, Technical product grouping focuses on domains requiring specific experience and knowledge not common to typical product teams. This can also support insourcing so other product teams do not have to build their own capacity.
• Within a Market or LoB team, these same technical groups support specific tools and services within that product family only while also specializing in the business domain.
• Alignment into tool, platform, or skill areas improves delivery capabilities and resource scalability.

Pattern: Organizational Alignment

Eventually in your product hierarchy, the management structure functions as the product management team.

• When planning your product families, be careful determining when to merge product families into the management team structure.
• Since the goal of scaling products into families is to align product delivery roadmaps to enterprise goals and enable value realization, the primary focus of scaling must be operational.
• Alignment to the organizational chart should only occur when the product families report into an HR manager who has ownership for the delivery and value realization for all product and services within that family.

Download Build a Better Product Owner for role support.

2.2.1 Arrange your applications and services into product families

1-4 hours

1. (Optional but recommended) Define your value streams and capabilities on the App Capability List tab in the Deliver Digital Products at Scale Workbook.
2. On the Product Families tab, build your product family hierarchy using the following structure:

• Value Stream > Capability > Family 3 > Family 2 > Family 1 > Product/Service.
• If you are not using a Value Stream > Capability grouping, you can leave these blank for now.

• Application Portfolio Snapshot service – Fast alignment of applications to capabilities/departments
• Application Portfolio Management for Small Enterprises – Simplified APM journey in one blueprint
• Discover Your Applications – First step in our three-step approach to manage applications in use
• Implement Software Asset Management – Go beyond tracking licenses to proactively managing software throughout its lifecycle

Output

• Product family mapping

Participants

• Product owners
• Product managers
• Development team leads
• Portfolio managers
• Business analysts

Record the results in the Deliver Digital Products at Scale Workbook.

2.2.2 Define enabling and supporting applications

1-4 hours

1. Review your grouping from the reverse direction or with different patterns to validate the grouping. Consider each grouping.

• Does it operationally align the products and families to best cascade enterprise goals and priorities while validating enabling capabilities?
• In the next phase, when defining your roadmap strategy, you may wish to revisit this phase and adjust as needed.

Output

• Product families
• Enabling applications
• Dependent applications

Participants

• Product owners
• Product managers
• Development team leads
• Portfolio managers
• Business analysts

Record the results in the Deliver Digital Products at Scale Workbook.

Use a product canvas to define key elements of your product family

A product canvas is an excellent tool for quickly providing important information about a product family.

Product owners/managers

Provide target state to align child product and product family roadmaps.

Stakeholders

Communicate high-level concepts and key metrics with leadership teams and stakeholders.

Strategy teams

Use the canvas as a tool for brainstorming, scoping, and ideation.

Operations teams

Share background overview to align operational team with end-user value.

Impacted users

Refine communication strategy and support based on user impacts and value realization.

Download Deliver on Your Digital Product Vision.

Product Family Canvas: Define your core information

Problem Statement: The problem or need the product family is addressing

Business Goals: List of business objectives or goals for the product

Personas/Customers/Users: List of groups who consume the product/service

Vision: Vision, unique value proposition, elevator pitch, or positioning statement

Child Product Families or Products: List of product families or products within this family

Stakeholders: List of key resources, stakeholders, and teams needed to support the product or service

Download Deliver on Your Digital Product Vision.

2.2.3 Build your product family canvas

30-60 minutes

1. Complete the following fields to build your product family canvas in your Digital Product Family Strategy Playbook:
1. Product family name
2. Product family owner
3. Parent product family name
4. Problem that the family is intending to solve (For additional help articulating your problem statement, refer to Deliver on Your Digital Product Vision.)
5. Product family vision/goals (For additional help writing your vision, refer to Deliver on Your Digital Product Vision..)
6. Child product or product family name(s)
7. Primary customers/users (For additional help with your product personas, download and complete Deliver on Your Digital Product Vision..)
8. Stakeholders (If you aren’t sure who your stakeholders are, fill this in after completing the stakeholder management exercises in phase 3.)

Output

• Product family canvas

Participants

• Product owners
• Product managers
• Development team leads
• Portfolio managers
• Business analysts

Record the results in the Digital Product Family Strategy Playbook.

Phase 3

Ensure Alignment Between Products and Families

This phase will walk you through the following activities:

• 3.1.1 Evaluate your current approach to product family communication
• 3.2.1 Visualize interrelationships among stakeholders to identify key influencers
• 3.2.2 Group stakeholders into categories
• 3.2.3 Prioritize your stakeholders
• 3.3.1 Define the communication objectives and audience of your product family roadmaps
• 3.3.2 Identify the level of detail that you want your product family roadmap artifacts to represent
• 3.4.1 Validate business value alignment between products and their product families

This phase involves the following participants:

• Product owners
• Product managers
• Portfolio managers
• Business analysts

Step 3.1

Leverage product family roadmaps

Activities

3.1.1 Evaluate your current approach to product family communication

This step involves the following participants:

• Product owners
• Product managers
• Portfolio managers
• Business analysts

Outcomes of this step

• Understanding of what a product family roadmap is
• Comparison of Info-Tech’s position on product families to how you currently communicate about product families

Aligning products’ goals with families

Without alignment between product family goals and their underlying products, you aren’t seeing the full picture.

Adapted from: Pichler," What Is Product Management?"

• Aligning product strategy to enterprise goals needs to happen through the product family.
• A product roadmap has traditionally been used to express the overall intent and visualization of the product strategy.
• Connecting the strategy of your products with your enterprise goals can be done through the product family roadmap.

Leveraging product family roadmaps

It’s more than a set of colorful boxes.

✓ Lays out a strategy for your product family.

✓ Is a statement of intent for your family of products.

✓ Communicates direction for the entire product family and product teams.

✓ Directly connects to the organization’s goals.

However, it is not:

x Representative of a hard commitment.

x A simple combination of your current product roadmaps.

x A technical implementation plan.

Product family roadmaps

There is no such thing as a roadmap that never changes.

Your product family roadmap represents a broad statement of intent and high-level tactics to get closer to the organization’s goals.

All good product family roadmaps embrace change!

Your strategic intentions are subject to volatility, especially those planned further in the future. The more costs you incur in planning, the more you leave yourself exposed to inefficiency and waste if those plans change.

Info-Tech Insight

A good product family roadmap is intended to manage and communicate the inevitable changes as a result of market volatility and changes in strategy.

Product family roadmaps are more strategic by nature

While individual product roadmaps can be different levels of tactical or strategic depending on a variety of market factors, your options are more limited when defining roadmaps for product families.

Info-Tech Insight

Roadmaps for your product family are, by design, less detailed. This does not mean they aren’t actionable! Your product family roadmap should be able to communicate clear intentions around the future delivery of value in both the near and long term.

Reminder: Your enterprise vision provides alignment for your product family roadmaps

Not knowing the difference between enterprise vision and goals will prevent you from both dreaming big and achieving your dream.

Your enterprise vision represents your “north star” – where you want to go. It represents what you want to do.

• Your enterprise goals represent what you need to achieve in order to reach your enterprise vision.
• A key element of operationalizing your vision.
• Your strategy, initiatives, and features will align with one or more goals.

Download Deliver on Your Digital Product Vision for support.

Multiple roadmap views can communicate differently, yet tell the same truth

Typical elements of a product family roadmap

While there are others, these represent what will commonly appear across most family-based roadmaps.

GROUP/CATEGORY: Groups are collections of artifacts. In a product family context, these are usually product family goals, value streams, or products.

ARTIFACT: An artifact is one of many kinds of tangible by-products produced during the delivery of products. For a product family, the artifacts represented are capabilities or value streams.

MILESTONE: Points in the timeline when established sets of artifacts are complete. This is a critical tool in the alignment of products in a given family.

TIME HORIZON: Separated periods within the projected timeline covered by the roadmap.

3.1.1 Evaluate your current approach to product family communication

1-2 hours

1. Write down how you currently communicate your intentions for your products and family of products.
2. Compare and contrast this to how this blueprint defines product families and product family roadmaps.
3. Consider the similarities and the key gaps between your current approach and Info-Tech’s definition of product family roadmaps.

Output

• Your documented approach to product family communication

Participants

• Product owners
• Stakeholders

Record the results in the Deliver Digital Products at Scale Workbook.

Step 3.2

Use stakeholder management to improve roadmap communication

Activities

3.2.1 Visualize interrelationships among stakeholders to identify key influencers

3.2.2 Group stakeholders into categories

3.2.3 Prioritize your stakeholders

Info-Tech Note

If you have done the stakeholder exercises in Deliver on Your Digital Product Vision or Build a Better Product Owner u don’t need to repeat the exercises from scratch.

You can bring the results forward and update them based on your prior work.

This step involves the following participants:

• Product owners
• Product managers
• Portfolio managers
• Business analysts

Outcomes of this step

• Relationships among stakeholders and influencers
• Categorization of stakeholders and influencers
• Stakeholder and influencer prioritization

Reminder: Not everyone is a user!

USERS

Individuals who directly obtain value from usage of the product.

STAKEHOLDERS

Represent individuals who provide the context, alignment, and constraints that influence or control what you will be able to accomplish.

FUNDERS

Individuals both external and internal that fund the product initiative. Sometimes they are lumped in as stakeholders. However, motivations can be different.

For more information, see Deliver on Your Digital Product Vision.

A stakeholder strategy is a key part of product family attainment

A roadmap is only “good” when it effectively communicates to stakeholders. Understanding your stakeholders is the first step in delivering great product family roadmaps.

Create a stakeholder network map for product roadmaps and prioritization

Follow the trail of breadcrumbs from your direct stakeholders to their influencers to uncover hidden stakeholders.

Legend

Black arrows: indicate the direction of professional influence

Dashed green arrows: indicate bidirectional, informal influence relationships

Info-Tech Insight

Your stakeholder map defines the influence landscape your product family operates in. It is every bit as important as the teams who enhance, support, and operate your product directly.

Use connectors to determine who may be influencing your direct stakeholders. They may not have any formal authority within the organization, but they may have informal yet substantial relationships with your stakeholders.

3.2.1 Visualize interrelationships among stakeholders to identify key influencers

60 minutes

1. List direct stakeholders for your product.
2. Determine the stakeholders of your stakeholders and consider adding each of them to the stakeholder list.
3. Assess who has either formal or informal influence over your stakeholders; add these influencers to your stakeholder list.
4. Construct a diagram linking stakeholders and their influencers together.

• Use black arrows to indicate the direction of professional influence.
• Use dashed green arrows to indicate bidirectional, informal influence relationships.

Output

• Relationships among stakeholders and influencers

Participants

• Product owners
• Stakeholders

Record the results in the Deliver Digital Products at Scale Workbook.

Categorize your stakeholders with a prioritization map

A stakeholder prioritization map helps product leaders categorize their stakeholders by their level of influence and ownership in the product and/or teams.

There are four areas in the map, and the stakeholders within each area should be treated differently.

Players – players have a high interest in the initiative and the influence to effect change over the initiative. Their support is critical, and a lack of support can cause significant impediment to the objectives.

Mediators – mediators have a low interest but significant influence over the initiative. They can help to provide balance and objective opinions to issues that arise.

Noisemakers – noisemakers have low influence but high interest. They tend to be very vocal and engaged, either positively or negatively, but have little ability to enact their wishes.

Spectators – generally, spectators are apathetic and have little influence over or interest in the initiative.

3.2.2 Group stakeholders into categories

30-60 minutes

1. Identify your stakeholders’ interest in and influence on your product as high, medium, or low by rating the attributes below.
2. Map your results to the model below to determine each stakeholder’s category.

Output

• Categorization of stakeholders and influencers

Participants

• Product owners
• Stakeholders

Record the results in the Deliver Digital Products at Scale Workbook.

Prioritize your stakeholders

There may be too many stakeholders to be able to manage them all. Focus your attention on the stakeholders that matter most.

Consider the three dimensions for stakeholder prioritization: influence, interest, and support. Support can be determined by answering the following question: How likely is it that this stakeholder would recommend your product?

These parameters are used to prioritize which stakeholders are most important and should receive your focused attention.

3.2.3 Prioritize your stakeholders

30 minutes

1. Identify the level of support of each stakeholder by answering the following question: How likely is it that this stakeholder would endorse your product?
2. Prioritize your stakeholders using the prioritization scheme on the previous slide.

Output

• Stakeholder and influencer prioritization

Participants

• Product owners
• Stakeholders

Record the results in the Deliver Digital Products at Scale Workbook.

Define strategies for engaging stakeholders by type

Info-Tech Insight

Each group of stakeholders draws attention and resources away from critical tasks. By properly identifying your stakeholder groups, the product owner can develop corresponding actions to manage stakeholders in each group. This can dramatically reduce wasted effort trying to satisfy Spectators and Noisemakers, while ensuring the needs of Mediators and Players are met.

Step 3.3

Configure your product family roadmaps

Activities

3.3.1 Define the communication objectives and audience of your product family roadmaps

3.3.2 Identify the level of detail that you want your product family roadmap artifacts to represent

Info-Tech Note

If you are unfamiliar with product roadmaps, Deliver on Your Digital Product Vision contains more detailed exercises we recommend you review before focusing on product family roadmaps.

This step involves the following participants:

• Product owners
• Product managers
• Portfolio managers
• Business analysts

Outcomes of this step

• An understanding of the key communication objectives and target stakeholder audience for your product family roadmaps
• A position on the level of detail you want your product family roadmap to operate at

Your communication objectives are linked to your audience; ensure you know your audience and speak their language

3.3.1 Define the communication objectives and audience of your product family roadmaps

30-60 minutes

1. Explicitly state the communication objectives and audience of your roadmap.

• Think of finishing this sentence: This roadmap is designed for … in order to …

Output

• Roadmap list with communication objectives and audience

Participants

• Product owners and product managers
• Application leaders
• Stakeholders

Record the results in the Deliver Digital Products at Scale Workbook.

The length of time horizons on your roadmap depend on the needs of the underlying products or families

Info-Tech Insight

Given the relationship between product and product family roadmaps, the product family roadmap needs to serve the time horizons of its respective products.

This translates into product family roadmaps with timelines that, at a minimum, cover the full scope of the respective product roadmaps.

Based on your communication objectives, consider different ways to visualize your product family roadmap

Swimlane/Stream-Based – Understanding when groups of items intend to be delivered.

Now, Next, Later – Communicate an overall plan with rough intentions around delivery without specific date ranges.

Sunrise Roadmap – Articulate the journey toward a given target state across multiple streams.

Before connecting your family roadmap to products, think about what each roadmap typically presents

Info-Tech Insight

Your product family roadmap and product roadmap tell different stories. The product family roadmap represents the overall connection of products to the enterprise strategy, while the product roadmap focuses on the fulfillment of the product’s vision.

Example: Connecting your product family roadmaps to product roadmaps

Your roadmaps should be connected at an artifact level that is common between both. Typically, this is done with capabilities, but you can do it at a more granular level if an understanding of capabilities isn’t available.

3.3.2 Identify the level of detail that you want your product family roadmap artifacts to represent

30-60 minutes

1. Consider the different available artifacts for a product family (goals, value stream, capabilities).
2. List the roadmaps that you wish to represent.
3. Based on how you currently articulate details on your product families, consider:

• What do you want to use as the level of granularity for the artifact? Consider selecting something that has a direct connection to the product roadmap itself (for example, capabilities).
• For some roadmaps you will want to categorize your artifacts – what would work best in those cases?

Output

• Details on your roadmap granularity

Participants

• Product owners
• Product managers
• Portfolio managers

Record the results in the Deliver Digital Products at Scale Workbook.

Step 3.4

Confirm goal and value alignment of products and their product families

Activities

3.4.1 Validate business value alignment between products and their product families

This step involves the following participants:

• Product owners
• Product managers
• Portfolio managers
• Business analysts

Outcomes of this step

• Validation of the alignment between your product families and products

Confirming product to family value alignment

It isn’t always obvious whether you have the right value delivery alignment between products and product families.

Product-to-family alignment can be validated in two different ways:

1. Initial value alignment

Confirm the perceived business value at a family level is aligned with what is being delivered at a product level.

2. Value measurement during the lifetime of the product

Validate family roadmap attainment through progression toward the specified product goals.

For more detail on calculating business value, see Build a Value Measurement Framework.

To evaluate a product family’s contribution, you need a common definition of value

Why is having a common value measure important?

CIO-CEO Alignment Diagnostic

Over 700 Info-Tech members have implemented the Balanced Value Measurement Framework.

“The cynic knows the price of everything and the value of nothing.”

– Oscar Wilde

“Price is what you pay. Value is what you get.”

– Warren Buffett

Understanding where you derive value is critical to building solid roadmaps.

All value in your product family is not created equal

Business value is the value of the business outcome the application produces and how effective the product is at producing that outcome. Dissecting value by the benefit type and the value source allows you to see the many ways in which a product or service brings value to your organization. Capture the value of your products in short, concise statements, like an elevator pitch.

Increase Revenue

Product or service functions that are specifically related to the impact on your organization’s ability to generate revenue.

Reduce Costs

Reduction of overhead. The ways in which your product limits the operational costs of business functions.

Enhance Services

Functions that enable business capabilities that improve the organization’s ability to perform its internal operations.

Reach Customers

Application functions that enable and improve the interaction with customers or produce market information and insights.

Financial Benefits vs. Improved Capabilities

• Financial Benefit refers to the degree to which the value source can be measured through monetary metrics and is often quite tangible.
• Human Benefit refers to how a product or service can deliver value through a user’s experience.

Inward vs. Outward Orientation

• Inward refers to value sources that have an internal impact and improve your organization’s effectiveness and efficiency in performing its operations.
• Outward refers to value sources that come from your interaction with external factors, such as the market or your customers.

3.4.1 Validate business value alignment between products and their product families

30-60 minutes

1. Draw the 2x2 Business Value Matrix on a flip chart or open the Business Value Matrix tab in the Deliver Digital Products at Scale Workbook to use in this exercise.
2. Brainstorm and record the different types of business value that your product and product family produce on the sticky notes (one item per sticky note).
3. As a team, evaluate how the product value delivered contributes to the product family value delivered. Note any gaps or differences between the two.

Download and complete Build a Value Measurement Framework for full support in focusing product delivery on business value–driven outcomes.

Output

• Confirmation of value alignment between product families and their respective products

Participants

• Product owners
• Product managers

Record the results in the Deliver Digital Products at Scale Workbook.

Example: Validate business value alignment between products and their product families

Measure product value with metrics tied to your business value sources and objectives

Assign metrics to your business value sources

The importance of measuring business value through metrics

The better an organization is at using business value metrics to evaluate IT’s performance, the more satisfied the organization is with IT’s performance as a business partner. In fact, those that say they’re effective at business value metrics have satisfaction scores that are 30% higher than those that believe significant improvements are necessary (Info-Tech’s IT diagnostics).

Assigning metrics to your prioritized values source will allow you to more accurately measure a product’s value to the organization and identify optimization opportunities. See Info-Tech’s Related Research: Value, Delivery Metrics, Estimation blueprint for more information.

Your product delivery pipeline connects your roadmap with business value realization

The effectiveness of your product roadmap needs to be evaluated based on delivery capacity and throughput.

When thinking about product delivery metrics, be careful what you ask for…

As the saying goes “Be careful what you ask for, because you will probably get it.”

Metrics are powerful because they drive behavior.

• Metrics are also dangerous because they often lead to unintended negative outcomes.
• Choose your metrics carefully to avoid getting what you asked for instead of what you intended.

It’s a cautionary tale that also offers a low-risk path through the complexities of metrics use.

For more information on the use (and abuse) of metrics, see Select and Use SDLC Metrics Effectively.

Measure delivery and success

Metrics and measurements are powerful tools to drive behavior change and decision making in your organization. However, metrics are highly prone to creating unexpected outcomes, so use them with great care. Use metrics judiciously to uncover insights but avoid gaming or ambivalent behavior, productivity loss, and unintended consequences.

Build good practices in your selection and use of metrics:

• Choose the metrics that are as close to measuring the desired outcome as possible.
• Select the fewest metrics possible and ensure they are of the highest value to your team, the safest from gaming behaviors and unintended consequences, and the easiest to gather and report.
• Never use metrics for reward or punishment; use them to develop your team.
• Automate as much metrics gathering and reporting as possible.
• Focus on trends rather than precise metrics values.
• Review and change your metrics periodically.

Phase 4

Bridge the Gap Between Product Families and Delivery

This phase will walk you through the following activities:

4.1.1 Assess your organization’s readiness to deliver digital product families

4.2.1 Consider pros and cons for each delivery model relative to how you wish to deliver

4.3.1 Understand the relationships between product management, delivery teams, and stakeholders

4.4.1 Discuss traditional vs. product-centric funding methods

This phase involves the following participants:

• Product owners
• Product managers
• Portfolio managers
• Delivery managers

Assess the impacts of product-centric delivery on your teams and org design

Product delivery can exist within any org structure or delivery model. However, when making the shift toward product management, consider optimizing your org design and product team structure to match your capacity and throughput needs.

Info-Tech Note

Realigning your delivery pipeline and org design takes significant effort and time. Although we won’t solve these questions here, it’s important to identify factors in your current or future models that improve value delivery.

Step 4.1

Assess your organization’s delivery readiness

Activities

4.1.1 Assess your organization’s readiness to deliver digital product families

This step involves the following participants:

• Product owners
• Product managers
• Portfolio managers
• Delivery managers

Outcomes of this step

• An understanding of the group’s maturity level when it comes to product delivery

Maturing product practices enables delivery of product families, not just products or projects

Just like product owners, product family owners are needed to develop long-term product value, strategy, and delivery. Projects can still be used as the source of funding and change management; however, the product family owner must manage product releases and operational support. The focus of this section will be on aligning product families to one or more releases.

4.1.1 Assess your organization’s readiness to deliver digital product families

30-60 minutes

1. For each question in the Deliver Digital Products at Scale Readiness Assessment, ask yourself which of the five associated maturity statements most closely describes your organization.
2. As a group, agree on your organization’s current readiness score for each of the six categories.

Output

• Product delivery readiness score

Participants

• Product managers
• Product owners

Download the Deliver Digital Products at Scale Readiness Assessment.

Value realization is constrained by your product delivery pipeline

Value is realized through changes made at the product level. Your pipeline dictates the rate, quality, and prioritization of your backlog delivery. This pipeline connects your roadmap goals to the value the goals are intended to provide.

Product delivery realizes value for your product family

While planning and analysis are done at the family level, work and delivery are done at the individual product level.

Step 4.2

Understand your delivery options

Activities

4.2.1 Consider pros and cons for each delivery model relative to how you wish to deliver

This step involves the following participants:

• Product owners
• Product managers
• Portfolio managers
• Delivery managers

Outcomes of this step

• An understanding of the different team configuration options when it comes to delivery and their relevance to how you currently work

Define the scope of your product delivery strategy

The goal of your product delivery strategy is to establish streamlined, enforceable, and standardized product management and delivery capabilities that follow industry best practices. You will need to be strategic in how and where you implement your changes because this will set the stage for future adoption. Strategically select the most appropriate products, roles, and areas of your organization to implement your new or enhanced capabilities and establish a foundation for scaling.

Successful product delivery requires people who are knowledgeable about the products they manage and have a broad perspective of the entire delivery process, from intake to delivery, and of the product portfolio. The right people also have influence with other teams and stakeholders who are directly or indirectly impacted by product decisions. Involve team members who have expertise in the development, maintenance, and management of your selected products and stakeholders who can facilitate and promote change.

Learn about different patterns to structure and resource your product delivery teams

The primary goal of any product delivery team is to improve the delivery of value for customers and the business based on your product definition and each product’s demand. Each organization will have different priorities and constraints, so your team structure may take on a combination of patterns or may take on one pattern and then transform into another.

See the flow of work through each delivery team structure pattern

Staffing models for product teams

	Functional Roles	Shared Service and Resource Pools	Product or System	Skills and Competencies
Pros	✓ Specialized resources are easier to staff ✓ Product knowledge is maintained	✓ Flexible demand/capacity management ✓ Supports full utilization of resources	✓ Teams are invested in the full life of the product ✓ Standing teams enable continuous improvement	✓ Teams are invested in the technology ✓ Standing teams enable continuous improvement
Cons	x Demand on specialists can create bottlenecks x Creates barriers to collaboration	x Unavailability of resources can lead to delays x Product knowledge can be lost as resources move	x Changes in demand can lead to downtime x Cross-functional skills make staffing a challenge	x Technology bias can lead to the wrong solution x Resource contention when team supports multiple solutions
Considerations	! Product owners must break requests down into very small components to support Agile delivery as mini-Waterfalls	! Product owners must identify specialist requirements in the roadmap to ensure resources are available	! Product owners must ensure that there is a sufficient backlog of valuable work ready to keep the team utilized	! Product owners must remain independent of technology to ensure the right solution is built
Use Case	When you lack people with cross-functional skills	When you have specialists such as those skilled in security and operations who will not have full-time work on the product	When you have people with cross-functional skills who can self-organize around the request	When you have a significant investment in a specific technology stack

4.2.1 Consider pros and cons for each delivery model relative to how you wish to deliver

1. Document your current staffing model for your product delivery teams.
2. Evaluate the pros and cons of each model, as specified on the previous slide, relative to how you currently work.
3. What would be the ideal target state for your team? If one model does not completely fit, is there a hybrid option worth considering? For example: Product-Based combined with Shared Service/Resource Pools for specific roles.

Output

• An understanding of pros and cons for each delivery model and the ideal target state for your team

Participants

• Product managers
• Product owners

Record the results in the Digital Product Family Strategy Playbook.

Step 4.3

Determine your operating model

Activities

4.3.1 Understand the relationships between product management, delivery teams, and stakeholders

This step involves the following participants:

• Product owners
• Product managers
• Portfolio managers
• Delivery managers

Outcomes of this step

• An understanding of the potential operating models and what will work best for your organization

Reminder: Patterns for scaling products

The alignment of your product families should be considered in your operating model.

Ensure consistency in the application of your design principles with a coherent operating model

What is an operating model?

An operating model is an abstract visualization, used like an architect’s blueprint, that depicts how structures and resources are aligned and integrated to deliver on the organization’s strategy. It ensures consistency of all elements in the organizational structure through a clear and coherent blueprint before embarking on detailed organizational design

The visual should highlight which capabilities are critical to attaining strategic goals and clearly show the flow of work so that key stakeholders can understand where inputs flow in and outputs flow out of the IT organization.

For more information, see Redesign Your IT Organizational Structure.

Weigh the pros and cons of IT operating models to find the best fit

1. LoB/Product Aligned – Decentralized Model: Line of Business, Geographically, Product, or Functionally Aligned

A decentralized IT operating model that embeds specific functions within LoBs/product teams and provides cross-organizational support for their initiatives.

2. Hybrid Functional: Functional/Product Aligned

A best-of-both-worlds model that balances the benefits of centralized and decentralized approaches to achieve both customer responsiveness and economies of scale.

3. Hybrid Service Model: Product-Aligned Operating Model

A model that supports what is commonly referred to as a matrix organization, organizing by highly related service categories and introducing the role of the service owner.

4. Centralized: Plan-Build-Run

A highly typical IT operating model that focuses on centralized strategic control and oversight in delivering cost-optimized and effective solutions.

5. Centralized: Demand-Develop-Service

A centralized IT operating model that lends well to more mature operating environments. Aimed at leveraging economies of scale in an end-to-end services delivery model.

There are many different operating models. LoB/Product Aligned and Hybrid Functional align themselves most closely with how products and product families are typically delivered.

Decentralized Model: Line of Business, Geographically, Product, or Functionally Aligned

For more information, see Redesign your IT Organizational Structure.

Hybrid Model: Functional/Product Aligned

For more information, see Redesign your IT Organizational Structure.

Hybrid Model: Product-Aligned Operating Model

For more information, see Redesign your IT Organizational Structure.

Centralized: Plan-Build-Run

For more information, see Redesign your IT Organizational Structure.

Centralized: Demand-Develop-Service

For more information, see Redesign your IT Organizational Structure.

Assess how your product scaling pattern impacts your resource delivery model

4.3.1 Understand the relationships between product management, delivery teams, and stakeholders

30-60 minutes

1. Discuss the intake sources of product work.
2. Trace the flow of requests down to the functional roles of your delivery team (e.g., developer, QA, operations).
3. Indicate where key deliverables are produced, particularly those that are built in collaboration.
4. Discuss the five operating models relative to your current operating model choice. How aligned are you?
5. Review Info-Tech’s recommendation on the best-aligned operating models for product family delivery. Do you agree or disagree?
6. Evaluate recommendations against how you operate/work.

Output

• Understanding of the relationships between key groups
• A preferred operating model

Participants

• Product owners
• Product managers
• Delivery managers

Record the results in the Digital Product Family Strategy Playbook.

4.3.1 Understand the relationships between product management, delivery teams, and stakeholders

Output

• Understanding of the relationships between key groups
• A preferred operating model

Participants

• Product owners
• Product managers
• Delivery managers

Step 4.4

Identify how to fund product family delivery

Activities

4.4.1 Discuss traditional vs. product-centric funding methods

This step involves the following participants:

• Product owners
• Product managers
• Portfolio managers
• Delivery managers

Outcomes of this step

• An understanding of the differences between product-based and traditional funding methods

Why is funding so problematic?

We often still think about funding products like construction projects.

These models require increasing accuracy throughout the project lifecycle to manage actuals vs. estimates.

"Most IT funding depends on one-time expenditures or capital-funding mechanisms that are based on building-construction funding models predicated on a life expectancy of 20 years or more. Such models don’t provide the stability or flexibility needed for modern IT investments." – EDUCAUSE

Reminder: Projects don’t go away. The center of the conversation changes.

Projects within products

Regardless of whether you recognize yourself as a product-based or project-based shop, the same basic principles should apply.

The purpose of projects is to deliver the scope of a product release. The shift to product delivery leverages a product roadmap and backlog as the mechanism for defining and managing the scope of the release.

Eventually, teams progress to continuous integration/continuous delivery (CI/CD) where they can release on demand or as scheduled, requiring org change management.

Planning and budgeting for products and families

Reward for delivering outcomes, not features

Info-Tech Insight

Changes to funding require changes to product and Agile practices to ensure product ownership and accountability.

The Lean Enterprise Funding Model is an example of a different approach

From: Implement Agile Practices That Work

A flexible funding pool akin to venture capital models is maintained to support innovative ideas and fund proofs of concept for product and process improvements.

Proofs of concept (POCs) are run by standing innovation teams or a reserve of resources not committed to existing products, projects, or services.

Every product line has funding for all changes and ongoing operations and support.

Teams are funded continuously so that they can learn and improve their practices as much as possible.

Budgeting approaches must evolve as you mature your product operating environment

Info-Tech Insight

As you evolve your approach to product delivery, you will be decoupling the expected benefits, forecast, and budget. Managing them independently will improve your ability to adapt to change and drive the right outcomes!

Your strategy must include the cost to build and operate

Most investment happens after go-live, not in the initial build!

Adapted from: LookFar

Info-Tech Insight

While the exact balance point between development or implementation costs varies from application to application, over 80% of the cost is accrued after go-live.

Traditional accounting leaves software development CapEx on the table

Software development costs have traditionally been capitalized, while research and operations are operational expenditures.

The challenge has always been the myth that operations are only bug fixes, upgrades, and other operational expenditures. Research shows that most post-release work on developed solutions is the development of new features and changes to support material changes in the business. While projects could bundle some of these changes into capital expenditure, much of the business-as-usual work that goes on leaves capital expenses on the table because the work is lumped together as maintenance-related OpEx.

From “How to Stop Leaving Software CapEx on the Table With Agile and DevOps”

4.4.1 Discuss traditional vs. product-centric funding methods

30-60 minutes

1. Discuss how products and product families are currently funded.
2. Review how the Agile/product funding models differ from how you currently operate.
3. What changes do you need to consider in order to support a product delivery model?
4. For each change, identify the key stakeholders and list at least one action to take.
5. Record the results in the Digital Product Family Strategy Playbook.

Output

• Understanding of funding principles and challenges

Participants

• Product owners
• Product managers
• Delivery managers

Record the results in the Digital Product Family Strategy Playbook.

Phase 5

Build Your Transformation Roadmap and Communication Plan

This phase will walk you through the following activities:

5.1.1 Introduce your digital product family strategy

5.2.1 Define your communication cadence for your strategy updates

5.2.2 Define your messaging for each stakeholder

5.3.1 How do we get started?

This phase involves the following participants:

• Product owners
• Product managers
• Application leaders
• Stakeholders

Step 5.1

Introduce your digital product family strategy

Activities

5.1.1 Introduce your digital product family strategy

This step involves the following participants:

• Product owners and product managers
• Application leaders
• Stakeholders

Outcomes of this step

• A completed executive summary presenting your digital product strategy

Product decisions are traditionally made in silos with little to no cross-functional communication and strategic oversight

Software delivery teams and stakeholders traditionally make plans, strategies, and releases within their silos and tailor their decisions based on their own priorities. Interactions are typically limited to hand-offs (such as feature requests) and routing of issues and defects back up the delivery pipeline. These silos likely came about through well-intentioned training, mandates, and processes, but they do not sufficiently support today’s need to rapidly release and change platforms.

Siloed departments often have poor visibility into the activities of other silos, and they may not be aware of the ramifications their decisions have on teams and stakeholders outside of their silo.

• Silos may make choices that are optimal largely for themselves without thinking of the holistic impact on a platform’s structure, strategy, use cases, and delivery.
• The business may approve platform improvements without the consideration of the delivery team’s current capacity or the system’s complexity, resulting in unrealistic commitments.
• Quality standards may be misinterpreted and inconsistently enforced across the entire delivery pipeline.

In some cases, the only way to achieve greater visibility and communication for all roles across a platform’s lifecycle is implementing an overarching role or team.

“The majority of our candid conversations with practitioners and project management offices indicate that the platform ownership role is poorly defined and poorly executed.”

– Barry Cousins

Practice Lead, Applications – Project & Portfolio Management

Info-Tech Research Group

Use stakeholder management and roadmap views to improve communication

Proactive, clear communication with stakeholders, SMEs, and your product delivery team can significantly improve alignment and agreement with your roadmap, strategy, and vision.

When building your communication strategy, revisit the work you completed in phase 3 developing your:

• Roadmap types
• Stakeholder strategy

5.1.1 Introduce your digital product family strategy

30-60 minutes

This exercise is intended to help you lay out the framing of your strategy and the justification for the effort. A lot of these items can be pulled directly from the product canvas you created in phase 2. This is intended to be a single slide to frame your upcoming discussions.

1. Update your vision, goals, and values on your product canvas. Determine which stakeholders may be impacted and what their concerns are. If you have many stakeholders, limit to Players and Influencers.
2. Identify what you need from the stakeholders as a result of this communication.
3. Keeping in mind the information gathered in steps 1 and 2, describe your product family strategy by answering three questions:

1. Why do we need product families?
2. What is in our way?
3. Our first step will be... ?

Output

• An executive summary that introduces your product strategy

Participants

• Product owners and product managers
• Application leaders
• Stakeholders

Record the results in the Digital Product Family Strategy Playbook.

Example: Scaling delivery through product families

Why do we need product families?

• The growth of our product offerings and our company’s movement into new areas of growth mean we need to do a better job scaling our offerings to meet the needs of the organization.

What is in our way?

• Our existing applications and services are so dramatically different we are unsure how to bring them together.

Our first step will be...

• Taking a full inventory of our applications and services.

Step 5.2

Communicate changes on updates to your strategy

Activities

5.2.1 Define your communication cadence for your strategy updates

5.2.2 Define your messaging for each stakeholder

This step involves the following participants:

• Product owners and product managers
• Application leaders
• Stakeholders

Outcomes of this step

• A communication plan for when strategy updates need to be given

5.2.1 Define your communication cadence for your strategy updates

30 minutes

Remember the role of different artifacts when it comes to your strategy. The canvas contributes to the What, and the roadmap addresses the How. Any updates to the strategy are articulated and communicated through your roadmap.

1. Review your currently defined roadmaps, their communication objectives, update frequency, and updates.
2. Consider the impacted stakeholders and the strategies required to communicate with them.
3. Fill in your communication cadence and communication method.

EXAMPLE:

Output

• Clear communication cadence for your roadmaps

Participants

• Product owners and product managers
• Application leaders
• Stakeholders

Record the results in the Digital Product Family Strategy Playbook.

The “what” behind the communication

Leaders of successful change spend considerable time developing a powerful change message, i.e. a compelling narrative that articulates the desired end state and makes the change concrete and meaningful to staff.

The change message should:

• Explain why the change is needed.
• Summarize what will stay the same.
• Highlight what will be left behind.
• Emphasize what is being changed.
• Explain how change will be implemented.
• Address how change will affect various roles in the organization.
• Discuss the staff’s role in making the change successful.

Five elements of communicating change

1. What is the change?
2. Why are we doing it?
3. How are we going to go about it?
4. How long will it take us to do it?
5. What is the role for each department and individual?

Source: Cornelius & Associates

How we engage with the message is just as important as the message itself

Why are we here?

Speak to what matters to them

Sell the improvement

Show real value

Discuss potential fears

Ask for their support

Be gracious

5.2.2 (Optional) Define your messaging for each stakeholder

30 minutes

It’s one thing to communicate the strategy, it’s another thing to send the right message to your stakeholders. Some of this will depend on the kind of news given, but the majority of this is dependent on the stakeholder and the cadence of communication.

1. From exercise 5.2.1, take the information on the specific roadmaps, target audience, and communication cadence.
2. Based on your understanding of the audience’s needs, what would the specific update try to get across?
3. Pick a specific typical example of a change in strategy that you have gone through. (e.g. Product will be delayed by a quarter; key feature is being substituted for another.)

EXAMPLE:

Output

• Messaging plan for each roadmap type

Participants

• Product owners and product managers
• Application leaders
• Stakeholders

Record the results in the Digital Product Family Strategy Playbook.

Step 5.3

Determine your next steps

Activities

5.3.1 How do we get started?

This step involves the following participants:

• Product owners and product managers
• Application leaders
• Stakeholders

Outcomes of this step

• Understanding the steps to get started in your transformation

Make a plan in order to make a plan!

Consider some of the techniques you can use to validate your strategy.

Go to your backlog and prioritize the elements that need to be answered sooner rather than later.

Possible areas of focus:

Regulatory requirements or questions to answer around accessibility, security, privacy.

Stress testing any new processes against situations that may occur.

The “Now, Next, Later” roadmap

Use this when deadlines and delivery dates are not strict. This is best suited for brainstorming a product plan when dependency mapping is not required.

Now: What are you going to do now?

Next: What are you going to do very soon?

Later: What are you going to do in the future?

Source: “Tips for Agile product roadmaps & product roadmap examples,” Scrum.org, 2017

5.3.1 How do we get started?

30-60 minutes

1. Identify what the critical steps are for the organization to embrace product-centric delivery.
2. Group each critical step by how soon you need to address it:

• Now: Let’s do this ASAP.
• Next: Sometime very soon, let’s do these things.
• Later: Much further off in the distance, let’s consider these things.

Source: “Tips for Agile product roadmaps & product roadmap examples,” Scrum.org, 2017

Output

• Product family transformation critical steps and basic roadmap

Participants

• Product owners and product managers
• Application leaders
• Stakeholders

Record the results in the Digital Product Family Strategy Playbook.

Record the results in the Deliver Digital Products at Scale Workbook.

Summary of Accomplishment

Problem Solved

The journey to become a product-centric organization is not short or easy. Like with any improvement or innovation, teams need to continue to evolve and mature with changes in their operations, teams, tools, and user needs.You’ve taken a big step completing your product family alignment. This provides a backbone for aligning all aspects of your organization to your enterprise goals and strategy while empowering product teams to find solutions closer to the problem. Continue to refine your model and operations to improve value realization and your product delivery pipelines to embrace business agility. Organizations that are most responsive to change will continue to outperform command-and-control leadership.

If you would like additional support, have our analysts guide you through other phases as part of an Info-Tech workshop.

Contact your account representative for more information.

workshops@infotech.com

1-888-670-8889

Research Contributors and Experts

Emily Archer

Lead Business Analyst,

Enterprise Consulting, authentic digital agency

Emily Archer is a consultant currently working with Fortune 500 clients to ensure the delivery of successful projects, products, and processes. She helps increase the business value returned for organizations’ investments in designing and implementing enterprise content hubs and content operations, custom web applications, digital marketing, and e-commerce platforms.

Founder & CTO

Strainprint Technologies Inc.

David Berg is a product commercialization expert that has spent the last 20 years of his career delivering product management and business development services across a broad range of industries. Early in his career, David worked with product management and engineering teams to build core network infrastructure products that secure and power the internet we benefit from today. David’s experience also includes working with clean technologies in the area of clean power generation, agritech, and Internet of Things infrastructure. Over the last five years, David has been focused on his latest venture, Strainprint Technologies, a data and analytics company focused on the medical cannabis industry. Strainprint has built the largest longitudinal medical cannabis dataset in the world with the goal to develop an understanding of treatment behavior, interactions, and chemical drivers to guide future product development.

Kathy Borneman

Digital Product Owner, SunTrust Bank

Kathy Borneman is a senior product owner who helps people enjoy their jobs again by engaging others in end-to-end decision making to deliver software and operational solutions that enhance the client experience and allow people to think and act strategically.

Charlie Campbell

Product Owner, Merchant e-Solutions

Charlie Campbell is an experienced problem solver with the ability to quickly dissect situations and recommend immediate actions to achieve resolution, liaise between technical and functional personnel to bridge the technology and communication gap, and work with diverse teams and resources to reach a common goal.

Yarrow Diamond

Sr. Director, Business Architecture

Financial Services

Yarrow Diamond is an experienced professional with expertise in enterprise strategy development, project portfolio management, and business process reengineering across financial services, healthcare and insurance, hospitality, and real estate environments. She has a master’s in Enterprise Architecture from Penn State University, LSSMBB, PMP, CSM, ITILv3.

Cari J. Faanes-Blakey, CBAP, PMI-PBA

Enterprise Business Systems Analyst,

Vertex, Inc.

Cari J. Faanes-Blakey has a history in software development and implementation as a Business Analyst and Project Manager for financial and taxation software vendors. Active in the International Institute of Business Analysis (IIBA), Cari participated on the writing team for the BA Body of Knowledge 3.0 and the certification exam.

Kieran Gobey

Senior Consultant Professional Services

Blueprint Software Systems

Kieran Gobey is an IT professional with 24 years of experience, focused on business, technology, and systems analysis. He has split his career between external and internal customer-facing roles, and this has resulted in a true understanding of what is required to be a Professional Services Consultant. His problem-solving skills and ability to mentor others have resulted in successful software implementations. Kieran’s specialties include deep system troubleshooting and analysis skills, facilitating communications to bring together participants effectively, mentoring, leadership, and organizational skills.

Rupert Kainzbauer

VP Product, Digital Wallets

Paysafe Group

Rupert Kainzbauer is an experienced senior leader with a passion for defining and delivering products that deliver real customer and commercial benefit. Together with a team of highly experienced and motivated product managers, he has successfully led highly complex, multi-stakeholder payments initiatives, from proposition development and solution design through to market delivery. Their domain experience is in building online payment products in high-risk and emerging markets, remittance, prepaid cards, and mobile applications.

Saeed Khan

Founder,

Transformation Labs

Saeed Khan has been working in high tech for 30 years in both Canada and the US and has held a number of leadership roles in Product Management over that time. He speaks regularly at conferences and has been writing publicly about technology product management since 2005. Through Transformation Labs, Saeed helps companies accelerate product success by working with product teams to improve their skills, practices, and processes. He is a cofounder of ProductCamp Toronto and currently runs a Meetup group and global Slack community called Product Leaders; the only global community of senior level product executives.

Hoi Kun Lo

Product Owner

Nielsen

Hoi Kun Lo is an experienced change agent who can be found actively participating within the IIBA and WITI groups in Tampa, FL and a champion for Agile, architecture, diversity, and inclusion programs at Nielsen. She is currently a Product Owner in the Digital Strategy team within Nielsen Global Watch Technology.

Abhishek Mathur

Sr Director, Product Management

Kasisto, Inc.

Abhishek Mathur is a product management leader, an artificial intelligence practitioner, and an educator. He has led product management and engineering teams at Clarifai, IBM, and Kasisto to build a variety of artificial intelligence applications within the space of computer vision, natural language processing, and recommendation systems. Abhishek enjoys having deep conversations about the future of technology and helping aspiring product managers enter and accelerate their careers.

Jeff Meister

Technology Advisor and Product Leader

Jeff Meister is a technology advisor and product leader. He has more than 20 years of experience building and operating software products and the teams that build them. He has built products across a wide range of industries and has built and led large engineering, design, and product organizations. Jeff most recently served as Senior Director of Product Management at Avanade, where he built and led the product management practice. This involved hiring and leading product managers, defining product management processes, solution shaping and engagement execution, and evangelizing the discipline through pitches, presentations, and speaking engagements. Jeff holds a Bachelor’s of Applied Science (Electrical Engineering) and a Bachelor’s of Arts from the University of Waterloo, an MBA from INSEAD (Strategy), and certifications in product management, project management, and design thinking.

Vincent Mirabelli

Principal,

Global Project Synergy Group

With over 10 years of experience in both the private and public sectors, Vincent Mirabelli possesses an impressive track record of improving, informing, and transforming business strategy and operations through process improvement, design and re-engineering, and the application of quality to business analysis, project management, and process improvement standards.

Oz Nazili

VP, Product & Growth

TWG

Oz Nazili is a product leader with a decade of experience in both building products and product teams. Having spent time at funded startups and large enterprises, he thinks often about the most effective way to deliver value to users. His core areas of interest include Lean MVP development and data-driven product growth.

Mark Pearson

Principal IT Architect, First Data Corporation

Mark Pearson is an executive business leader grounded in the process, data, technology, and operations of software-driven business. He knows the enterprise software landscape and is skilled in product, technology, and operations design and delivery within information technology organizations, outsourcing firms, and software product companies.

Brenda Peshak

Product Owner,

Widget Industries, LLC

Brenda Peshak is skilled in business process, analytical skills, Microsoft Office Suite, communication, and customer relationship management (CRM). She is a strong product management professional with a Master’s focused in Business Leadership (MBL) from William Penn University.

Mike Starkey

Director of Engineering

W.W. Grainger

Mike Starkey is a Director of Engineering at W.W. Grainger, currently focusing on operating model development, digital architecture, and building enterprise software. Prior to joining W.W. Grainger, Mike held a variety of technology consulting roles throughout the system delivery lifecycle spanning multiple industries such as healthcare, retail, manufacturing, and utilities with Fortune 500 companies.

Anant Tailor

Cofounder & Head of Product

Dream Payments Corp.

Anant Tailor is a cofounder at Dream Payments where he currently serves as the COO and Head of Product, having responsibility for Product Strategy & Development, Client Delivery, Compliance, and Operations. He has 20+ years of experience building and operating organizations that deliver software products and solutions for consumers and businesses of varying sizes. Prior to founding Dream Payments, Anant was the COO and Director of Client Services at DonRiver Inc, a technology strategy and software consultancy that he helped to build and scale into a global company with 100+ employees operating in seven countries. Anant is a Professional Engineer with a Bachelor’s degree in Electrical Engineering from McMaster University and a certificate in Product Strategy & Management from the Kellogg School of Management at Northwestern University.

Angela Weller

Scrum Master, Businessolver

Angela Weller is an experienced Agile business analyst who collaborates with key stakeholders to attain their goals and contributes to the achievement of the company’s strategic objectives to ensure a competitive advantage. She excels when mediating or facilitating teams.

Related Info-Tech Research

Product Delivery

Deliver on Your Digital Product Vision

• Build a product vision your organization can take from strategy through execution.

Build a Better Product Owner

• Strengthen the product owner role in your organization by focusing on core capabilities and proper alignment.

Build Your Agile Acceleration Roadmap

• Quickly assess the state of your Agile readiness and plan your path forward to higher value realization.

Implement Agile Practices That Work

• Improve collaboration and transparency with the business to minimize project failure.

Implement DevOps Practices That Work

• Streamline business value delivery through the strategic adoption of DevOps practices.

Extend Agile Practices Beyond IT

• Further the benefits of Agile by extending a scaled Agile framework to the business.

Build Your BizDevOps Playbook

• Embrace a team sport culture built around continuous business-IT collaboration to deliver great products.

Embed Security Into the DevOps Pipeline

• Shift security left to get into DevSecOps.

Spread Best Practices With an Agile Center of Excellence

• Facilitate ongoing alignment between Agile teams and the business with a set of targeted service offerings.

Enable Organization-Wide Collaboration by Scaling Agile

• Execute a disciplined approach to rolling out Agile methods in the organization.

Application Portfolio Management

APM Research Center

• See an overview of the APM journey and how we can support the pieces in this journey.

Application Portfolio Management for Small Enterprises

• There is no one-size-fits-all rationalization. Tailor your framework to meet your goals.

Streamline Application Maintenance

• Effective maintenance ensures the long-term value of your applications.

Build an Application Rationalization Framework

• Manage your application portfolio to minimize risk and maximize value.

Modernize Your Applications

• Justify modernizing your application portfolio from both business and technical perspectives.

Review Your Application Strategy

• Ensure your applications enable your business strategy.

Discover Your Applications

• Most application strategies fail. Arm yourself with the necessary information and team structure for a successful application portfolio strategy.

Streamline Application Management

• Move beyond maintenance to ensuring exceptional value from your apps.

Optimize Applications Release Management

• Facilitate ongoing alignment between Agile teams and the business with a set of targeted service offerings.

Embrace Business-Managed Applications

• Empower the business to implement their own applications with a trusted business-IT relationship.

Value, Delivery Metrics, Estimation

Build a Value Measurement Framework

• Focus product delivery on business value–driven outcomes.

Select and Use SDLC Metrics Effectively

• Be careful what you ask for, because you will probably get it.

Application Portfolio Assessment: End User Feedback

• Develop data-driven insights to help you decide which applications to retire, upgrade, re-train on, or maintain to meet the demands of the business.

Create a Holistic IT Dashboard

• Mature your IT department by measuring what matters.

Refine Your Estimation Practices With Top-Down Allocations

• Don’t let bad estimates ruin good work.

Estimate Software Delivery With Confidence

• Commit to achievable software releases by grounding realistic expectations.

Reduce Time to Consensus With an Accelerated Business Case

• Expand on the financial model to give your initiative momentum.

Optimize Project Intake, Approval, and Prioritization

• Deliver more projects by giving yourself the voice to say “no” or “not yet” to new projects.

Enhance PPM Dashboards and Reports

• Facilitate ongoing alignment between Agile teams and the business with a set of targeted service offerings.

Org Design and Performance

Redesign Your IT Organizational Structure

• Focus product delivery on business value–driven outcomes.

Build a Strategic Workforce Plan

• Have the right people, in the right place, at the right time.

Implement a New Organizational Structure

• Reorganizations are inherently disruptive. Implement your new structure with minimal pain for staff while maintaining IT performance throughout the change.

Improve Employee Engagement to Drive IT Performance

• Don’t just measure engagement, act on it.

Set Meaningful Employee Performance Measures

• Set holistic measures to inspire employee performance.

Master Organizational Change Management Practices

• PMOs, if you don't know who is responsible for org change, it's you.

Bibliography (Product Management)

“12th Annual State of Agile Report.” VersionOne, 9 April 2018. Web.

A, Karen. “20 Mental Models for Product Managers.” Product Management Insider, Medium, 2 Aug. 2018. Web.

Adams, Paul. “Product Teams: How to Build & Structure Product Teams for Growth.” Inside Intercom, 30 Oct. 2019. Web.

Agile Alliance. “Product Owner.” Agile Alliance. n.d. Web.

Ambysoft. “2018 IT Project Success Rates Survey Results.” Ambysoft. 2018. Web.

Banfield, Richard, et al. “On-Demand Webinar: Strategies for Scaling Your (Growing) Enterprise Product Team.” Pluralsight, 31 Jan. 2018. Web.

Berez, Steve, et al. “How to Plan and budget for Agile at Scale.” Bain & Company, 08 Oct 2019. Web

Blueprint. “10 Ways Requirements Can Sabotage Your Projects Right From the Start.” Blueprint. 2012. Web.

Breddels, Dajo, and Paul Kuijten. “Product Owner Value Game.” Agile2015 Conference, Agile Alliance 2015. Web.

Cagan, Martin. “Behind Every Great Product.” Silicon Valley Product Group. 2005. Web.

Cohn, Mike. “What Is a Product?” Mountain Goat Software. 6 Sept. 2016. Web.

Connellan, Thomas K. Inside the Magic Kingdom, Bard Press, 1997.

Curphey, Mark. “Product Definition.” SlideShare, 25 Feb. 2007. Web.

“Delegation Poker Product Image.” Management 3.0, n.d. Web.

Distel, Dominic, et al. “Finding the sweet spot in product-portfolio management.’ McKinsey, 4 Dec. 2020. Web

Eringa, Ron. “Evolution of the Product Owner.” RonEringa.com, 12 June 2016. Web.

Fernandes, Thaisa. “Spotify Squad Framework - Part I.” PM101, Medium, 6 Mar. 2017. Web.

Galen, Robert. “Measuring Product Ownership – What Does ‘Good’ Look Like?” RGalen Consulting, 5 Aug. 2015. Web.

Halisky, Merland, and Luke Lackrone. “The Product Owner’s Universe.” Agile2016 Conference, Agile Alliance, 2016. Web.

Kamer, Jurriaan. “How to Build Your Own ‘Spotify Model’.” The Ready, Medium, 9 Feb. 2018. Web.

Kendis Team. “Exploring Key Elements of Spotify’s Agile Scaling Model.” Scaled Agile Framework, Medium, 23 Jul. 2018. Web.

Lindstrom, Lowell. “7 Skills You Need to Be a Great Product Owner.” Scrum Alliance, n.d. Web.

Lukassen, Chris. “The Five Belts Of The Product Owner.” Xebia.com, 20 Sept. 2016. Web.

McCloskey, Heather. “Scaling Product Management: Secrets to Defeating Common Challenges.” ProductPlan, 12 July 2019. Web.

McCloskey, Heather. “When and How to Scale Your Product Team.” UserVoice, 21 Feb. 2017. Web.

Mironov, Rich. “Scaling Up Product Manager/Owner Teams.” Rich Mironov's Product Bytes, Mironov Consulting, 12 Apr. 2014 . Web.

Overeem, Barry. “A Product Owner Self-Assessment.” Barry Overeem, 6 Mar. 2017. Web.

Overeem, Barry. “Retrospective: Using the Team Radar.” Barry Overeem, 27 Feb. 2017. Web.

Pichler, Roman. “How to Scale the Scrum Product Owner.” Roman Pichler, 28 June 2016 . Web.

Pichler, Roman. “Product Management Framework.” Pichler Consulting Limited, 2014. Web.

Pichler, Roman. “Sprint Planning Tips for Product Owners.” LinkedIn, 4 Sept. 2018. Web.

Pichler, Roman. “What Is Product Management?” Pichler Consulting Limited, 26 Nov. 2014. Web.

Radigan, Dan. “Putting the ‘Flow' Back in Workflow With WIP Limits.” Atlassian, n.d. Web.

Rouse, Margaret. “Definition: product.” TechTarget, Sept. 2005. Web.

Schuurman, Robbin. “10 Tips for Product Owners on (Business) Value.” Scrum.org, 30 Nov. 2017. Web.

Schuurman, Robbin. “10 Tips for Product Owners on Agile Product Management.” Scrum.org, 28 Nov. 2017. Web.

Schuurman, Robbin. “10 Tips for Product Owners on Product Backlog Management.” Scrum.org, 5 Dec. 2017. Web.

Schuurman, Robbin. “10 Tips for Product Owners on the Product Vision.” Scrum.org, 29 Nov. 2017. Web.

Schuurman, Robbin. “Tips for Starting Product Owners.” Scrum.org, 27 Nov. 2017. Web.

Sharma, Rohit. “Scaling Product Teams the Structured Way.” Monetary Musings, 28 Nov. 2016. Web.

Shirazi, Reza. “Betsy Stockdale of Seilevel: Product Managers Are Not Afraid To Be Wrong.” Austin Voice of Product, 2 Oct. 2018. Web.

Steiner, Anne. “Start to Scale Your Product Management: Multiple Teams Working on Single Product.” Cprime, 6 Aug. 2019. Web.

“The Qualities of Leadership: Leading Change.” Cornelius & Associates, 2016. Web.

“The Standish Group 2015 Chaos Report.” The Standish Group. 2015. Web.

Theus, Andre. “When Should You Scale the Product Management Team?” ProductPlan, 7 May 2019. Web.

Tolonen, Arto. “Scaling Product Management in a Single Product Company.” Smartly.io, 26 Apr. 2018. Web.

Ulrich, Catherine. “The 6 Types of Product Managers. Which One Do You Need?” Medium, 19 Dec. 2017. Web.

Verwijs, Christiaan. “Retrospective: Do The Team Radar.” The Liberators, Medium, 10 Feb. 2017. Web.

Vlaanderen, Kevin. “Towards Agile Product and Portfolio Management”. Academia.edu. 2010. Web.

Bibliography (Roadmap)

Bastow, Janna. “Creating Agile Product roadmaps Everyone Understands.” ProdPad, 22 Mar. 2017. Accessed Sept. 2018.

Bastow, Janna. “The Product Tree Game: Our Favorite Way To Prioritize Features.” ProdPad, 21 Feb. 2016. Accessed Sept. 2018.

Chernak, Yuri. “Requirements Reuse: The State of the Practice.” 2012 IEEE International Conference, 12 June 2012, Herzliya, Israel. Web.

Fowler, Martin. “Application Boundary.” MartinFowler.com, 11 Sept. 2003. Accessed 20 Nov. 2017.

Harrin, Elizabeth. “Learn What a Project Milestone Is.” The Balance Careers, 10 May 2018. Accessed Sept. 2018.

“How to create a product roadmap.” Roadmunk, n.d. Accessed Sept. 2018.

Johnson, Steve. “How to Master the 3 Horizons of Product Strategy.” Aha!, 24 Sept. 2015. Accessed Sept. 2018.

Johnson, Steve. “The Product Roadmap vs. the Technology Roadmap.” Aha!, 23 June 2016. Accessed Sept. 2018

Juncal, Shaun. “How Should You Set Your Product Roadmap Timeframes?” ProductPlan, Web. Sept. 2018.

Leffingwell, Dean. “SAFe 4.0.” Scaled Agile, 2017. Web.

Maurya, Ash. “What is a Minimum Viable Product (MVP).” Leanstack, 12 June 2017. Accessed Sept. 2018.

Pichler, Roman. “10 Tips for Creating an Agile Product Roadmap.” Roman Pichler, 20 July 2016. Accessed Sept. 2018.

Pichler, Roman. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age. Pichler Consulting, 2016.

“Product Roadmap Contents: What Should You Include?” ProductPlan, n.d. Accessed 20 Nov. 2017.

Saez, Andrea. “Why Your Roadmap Is Not a Release Plan.” ProdPad, 23 October 2015. Accessed Sept. 2018.

Schuurman, Robbin. “Tips for Agile product roadmaps & product roadmap examples.” Scrum.org, 7 Dec. 2017. Accessed Sept. 2018.

Bibliography (Vision and Canvas)

Adams, Paul. “The Future Product Canvas.” Inside Intercom, 10 Jan. 2014. Web.

“Aligning IT Funding Models to the Pace of Technology Change.” EDUCAUSE, 14 Dec. 2015. Web.

Altman, Igor. “Metrics: Gone Bad.” OpenView, 10 Nov. 2009. Web.

Barry, Richard. “The Product Vision Canvas – a Strategic Tool in Developing a Successful Business.” Polymorph, 2019. Web.

“Business Canvas – Business Models & Value Propositions.” Strategyzer, 2019. Web.

“Business Model Canvas.” Wikipedia: The Free Encyclopedia, 4 Aug. 2019. Web.

Charak, Dinker. “Idea to Product: The Working Model.” ThoughtWorks, 13 July 2017. Web.

Charak, Dinker. “Product Management Canvas - Product in a Snapshot.” Dinker Charak, 29 May 2017. Web.

Chudley, James. “Practical Steps in Determining Your Product Vision (Product Tank Bristol, Oct. 2018).” LinkedIn SlideShare. Uploaded by cxpartners, 2 Nov. 2018. Web.

Cowan, Alex. “The 20 Minute Business Plan: Business Model Canvas Made Easy.” COWAN+, 2019. Web.

Craig, Desiree. “So You've Decided To Become A Product Manager.” Start it up, Medium, 2 June 2019. Web.

Create an Aha! Business Model Canvas Strategic Model.” Aha! Support, 2019. Web.

Eick, Stephen. “Does Code Decay? Assessing the Evidence from Change Management Data.” IEEE Transactions on Software Engineering, vol. 27, no. 1, Jan. 2001, pp. 1-12. Web.

Eriksson, Martin. “The next Product Canvas.” Mind the Product, 22 Nov. 2013. Web.

“Experience Canvas: a Lean Approach: Atlassian Team Playbook.” Atlassian, 2019. Web.

Freeman, James. “How to Make a Product Canvas – Visualize Your Product Plan.” Edraw, 23 Dec. 2019. Web.

Fuchs, Danny. “Measure What Matters: 5 Best Practices from Performance Management Leaders.” OpenGov, 8 Aug. 2018. Web.

Gorisse, Willem. “A Practical Guide to the Product Canvas.” Mendix, 28 Mar. 2017. Web.

Gothelf, Jeff. “The Lean UX Canvas.” Jeff Gothelf, 15 Dec. 2016. Web.

Gottesdiener, Ellen. “Using the Product Canvas to Define Your Product: Getting Started.” EBG Consulting, 15 Jan. 2019. Web.

Gottesdiener, Ellen. “Using the Product Canvas to Define Your Product's Core Requirements.” EBG Consulting, 4 Feb. 2019. Web.

Gray, Mark Krishan. “Should I Use the Business Model Canvas or the Lean Canvas?” Emergn, 2019. Web.

Hanby, Jeff. "Software Maintenance: Understanding and Estimating Costs." LookFar, 21 Oct. 2016. Web.

“How do you define a product?” Scrum.org, 4 Apr 2017, Web

Juncal, Shaun. “How to Build a Product Roadmap Based on a Business Model Canvas.” ProductPlan, 19 June 2019. Web.

“Lean Canvas Intro - Uber Example.” YouTube, uploaded by Railsware Product Academy, 12 Oct. 2018. Web.

“Lesson 6: Product Canvas.” ProdPad Help Center, 2019. Web.

Lucero, Mario. “The Product Canvas.” Agilelucero.com, 22 June 2015. Web.

Maurya, Ash. “Create a New Lean Canvas.” Canvanizer, 2019. Web.

Maurya, Ash. “Don't Write a Business Plan. Create a Lean Canvas Instead.” LEANSTACK, 2019. Web.

Maurya, Ash. “Why Lean Canvas vs Business Model Canvas?” Medium, 27 Feb. 2012. Web.

Mirabelli, Vincent. “The Project Value Canvas.” Vincent Mirabelli, 2019. Web.

Mishra, LN. “Business Analysis Canvas – The Ultimate Enterprise Architecture.” BA Times, 19 June 2019. Web.

Muller. Jerry Z. “Why performance metrics isn’t always the best way to judge performance.” Fast Company, 3 April 2019. Web.

Perri, Melissa. “What Is Good Product Strategy?” Melissa Perri, 14 July 2016. Web.

Pichler, Roman. “A Product Canvas for Agile Product Management, Lean UX, Lean Startup.” Roman Pichler, 16 July 2012. Web.

Pichler, Roman. “Introducing the Product Canvas.” JAXenter, 15 Jan. 2013. Web.

Pichler, Roman. “Roman's Product Canvas: Introduction.” YouTube, uploaded by Roman Pichler, 3 Mar. 2017. Web.

Pichler, Roman. “The Agile Vision Board: Vision and Product Strategy.” Roman Pichler, 10 May 2011. Web.

Pichler, Roman. “The Product Canvas – Template.” Roman Pichler, 11 Oct. 2016. Web.

Pichler, Roman. “The Product Canvas Tutorial V1.0.” LinkedIn SlideShare. Uploaded by Roman Pichler, 14 Feb. 2013. Web.

Pichler, Roman. “The Product Vision Board: Introduction.” YouTube uploaded by Roman Pichler, 3 Mar. 2017. Web.

“Product Canvas PowerPoint Template.” SlideModel, 2019. Web.

Product Canvas.” SketchBubble, 2019, Web.

“Product Canvas.” YouTube, uploaded by Wojciech Szramowski, 18 May 2016. Web.

“Product Roadmap Software to Help You Plan, Visualize, and Share Your Product Roadmap.” Productboard, 2019. Web.

Roggero, Giulio. “Product Canvas Step-by-Step.” LinkedIn SlideShare, uploaded by Giulio Roggero, 18 May 2013. Web.

Royce, Dr. Winston W. “Managing the Development of Large Software Systems.” Scf.usc.edu, 1970. Web.

Ryan, Dustin. “The Product Canvas.” Qdivision, Medium, 20 June 2017. Web.

Snow, Darryl. “Product Vision Board.” Medium, 6 May 2017. Web.

Stanislav, Shymansky. “Lean Canvas – a Tool Your Startup Needs Instead of a Business Plan.” Railsware, 12 Oct. 2018. Web.

Stanislav, Shymansky. “Lean Canvas Examples of Multi-Billion Startups.” Railsware, 20 Feb. 2019. Web.

“The Product Vision Canvas.” YouTube, Uploaded by Tom Miskin, 20 May 2019. Web.

Tranter, Leon. “Agile Metrics: the Ultimate Guide.” Extreme Uncertainty, n.d. Web.

“Using Business Model Canvas to Launch a Technology Startup or Improve Established Operating Model.” AltexSoft, 27 July 2018. Web.

Veyrat, Pierre. “Lean Business Model Canvas: Examples + 3 Pillars + MVP + Agile.” HEFLO BPM, 10 Mar. 2017. Web.

“What Are Software Metrics and How Can You Track Them?” Stackify, 16 Sept. 2017. Web

“What Is a Product Vision?” Aha!, 2019. Web.

Develop the Right Message to Engage Buyers

Drive higher open rates, time-on-site, and click-through rates with buyer-relevant messaging.

Analyst Perspective

Develop the right message to engage buyers.

Marketers only have seven seconds to capture a visitor's attention but often don't realize that the space between competitors and their company is that narrow. They often miss the mark on content and create reams of product and company-focused messaging that result in high bounce rates, low page views, low return visits, low conversions, and low click-through rates.

We wouldn't want to sit in a conversation with someone who only speaks about themselves, so why would it be any different when we buy something? Today's marketers must quickly hook their visitors with content that answers the critical question of "What's in it for me?"

Our research finds that leading content marketers craft messaging that lets their audience ”know they know them,” points out what’s in it for them, and includes proof points of promised value. This simple, yet often missed approach, we call Message Mapping, which helps marketers grab a visitor’s initial attention and when applied throughout the customer journey will turn prospects into customers, lifelong buyers, advocates, and referrals.

Terra Higginson Marketing Research Director SoftwareReviews

Executive Summary

SoftwareReviews Insight

Marketing content that identifies the benefit of the product, along with a deep understanding of the buyer pain points, desired value, and benefit proof-points, is a key driver in delivering value to a prospect, thereby increasing marketing metrics such as open rates, time on site, page views, and click-through rates.

Your Challenge

65% of marketers find it challenging to produce engaging content. Globally, B2B SaaS marketers without the ability to consistently produce and activate quality content will experience: High website bounce rates and low time on site Low page views A low percentage of return visitors Low conversions Low open and click-through rates on email campaigns A staggering 60% of marketers find it hard to produce high-quality content consistently and 62% don’t know how to measure the ROI of their campaigns according to OptinMonster. SaaS marketers have an even more difficult job due to the technical nature of content production. Without an easy content development strategy, marketers have an insurmountable task of continually creating interesting content for an audience they don’t understand.

Over 64% of marketers want to learn how to build a better content (Source: OptinMonster, 2021)

Benchmark your content marketing

GrowRevenue, MarketingSherpa, Google Analytics, FirstPageSage, Google Analytics, HubSpot

Leaders will measure content marketing performance against these industry benchmarks. If your content performance falls below these benchmarks, your content architecture may be missing the mark with prospective buyers.

Common flaws in content messaging

Implications of poor content

Benefits of good content

Email & Social Post Example

Use the message mapping architecture to create other types of content.

Insight Summary

Create Content That Matters

Related SoftwareReviews Research

Create a Buyer Persona and Journey Make it easier to market, sell, and achieve product-market fit with deeper buyer understanding. Reduce time and treasure wasted chasing the wrong prospects. Improve product-market fit. Increase open and click-through rates in your lead gen engine. Perform more effective sales discovery and increase eventual win rates.

Diagnose Brand Health to Improve Business Growth Have a significant and well-targeted impact on business success and growth by knowing how your brand performs, identifying areas of improvement, and making data-driven decisions to fix it. Importance of brand is recognized, endorsed, and prioritized. Support and resources allocated. All relevant data and information collected in one place. Ability to make data-driven recommendations and decisions on how to improve.

Build a More Effective Go-to-Market Strategy Creating a compelling Go-to-Market strategy, and keeping it current, is a critical software company function – as important as financial strategy, sales operations, and even corporate business development – given its huge impact on the many drivers of sustainable growth. Align stakeholders on a common vision and execution plan. Build a foundation of buyer and competitive understanding. Deliver a team-aligned launch plan that enables commercial success.

Bibliography

Arakelyan, Artash. “How SaaS Companies Increase Their ROI With Content Marketing.” Clutch.co, 27 July 2018. Accessed July 2022.

Bailyn, Evan. “Average Session Duration: Industry Benchmarks.” FirstPageSage, 16 March 2022. Accessed July 2022.

Burstein, Daniel. “Marketing Research Chart: Average clickthrough rates by industry.” MarketingSherpa, 1 April 2014. Accessed July 2022.

Cahoon, Sam. “Email Open Rates By Industry (& Other Top Email Benchmarks).” HubSpot, 10 June 2021. Accessed July 2022.

Cialdini, Robert. Influence: Science and Practice. 5th ed. Pearson, 29 July 2008. Print.

Cialdini, Robert. Influence: The Psychology of Persuasion. Revised ed. Harper Business, 26 Dec. 2006. Print.

Content Marketing—Statistics, Evidence and Trends.” 1827 Marketing, 7 Jan. 2022. Accessed July 2022.

Devaney, Erik. “Content Mapping 101: The Template You Need to Personalize Your Marketing.” HubSpot, 21 April 2022. Accessed July 2022.

Hiscox Business Insurance. “Growing Your Business--and Protecting It Every Step of the Way.” Inc.com. 25 April 2022. Accessed July 2022.

Hurley Hall, Sharon. “85 Content Marketing Statistics To Make You A Marketing Genius.” OptinMonster, 14 Jan. 2021. Accessed July 2022.

Patel, Neil. “38 Content Marketing Stats That Every Marketer Needs to Know.” NeilPatel.com, 21 Jan. 2016. Web.

Prater, Meg. “SaaS Sales: 7 Tips on Selling Software from a Top SaaS Company.” HubSpot, 9 June 2021. Web.

Polykoff, Dave. “20 SaaS Content Marketing Statistics That Lead to MRR Growth in 2022.” Zenpost blog, 22 July 2022. Web.

Rayson, Steve. “Content, Shares, and Links: Insights from Analyzing 1 Million Articles.” Moz, 8 Sept. 2015. Accessed July 2022.

“SaaS Content Marketing: How to Measure Your SaaS Content’s Performance.” Ken Moo, 9 June 2022. Accessed July 2022.

Taylor Gregory, Emily. “Content marketing challenges and how to overcome them.” Longitude, 14 June 2022. Accessed July 2022.

Visitors Benchmarking Channels. Google Analytics, 2022. Accessed July 2022.

WBR Insights. “Here's How the Relationship Between B2B Buying, Content, and Sales Reps Has Changed.” Worldwide Business Research, 2022. Accessed July 2022.

“What’s a good bounce rate? (Here’s the average bounce rate for websites).” GrowRevenue.io, 24 Feb. 2020. Accessed July 2022.

Modernize and Transform Your End-User Computing Strategy

Support the workforce of the future.

EXECUTIVE BRIEF

Analyst Perspective

Focus beyond the device

It’s easy to think that if we give end users nice devices, then they will be more engaged and they will be happy with IT. If only it were that easy.

Info-Tech Research Group has surveyed over 119,000 people through its CIO Business Vision diagnostic. The results show that a good device is necessary but not enough for high satisfaction with IT. Once a user has a decent device, the other aspects of the user’s experience has a higher impact on their satisfaction with IT.

After all, if a person is trying to run apps designed in the 1990s, if they are struggling to access resources through an underperforming VPN connection, or if they can’t get help when their devices and apps aren’t working, then it doesn’t matter that you gave them a state-of-the-art MacBook or Microsoft Surface.

As you build out your end-user computing strategy to reflect the new reality of today’s workforce, ensure you focus on shifting user support left, modernizing apps to support how users need to work, and ensuring that your network and collaboration tools can support the increased demands. End-user computing teams need to focus beyond the device.

Ken Weston, ITIL MP, PMP, Cert.APM, SMC

Research Director, Infrastructure and Operations Info-Tech Research Group

Mahmoud Ramin, PhD

Senior Research Analyst, Infrastructure and Operations Info-Tech Research Group

Executive Summary

Your Challenge

IT needs to answer these questions:

• What types of computing devices, provisioning models, and operating systems (OSes) should be offered to end users?
• How will IT support devices?
• What are the policies and governance surrounding how devices are used?
• What actions are we taking and when?
• How do end-user devices support larger corporate priorities and strategies?

Your answers need to balance choice, risk, and cost.

Common Obstacles

Management paradigms have shifted:

• OSes, device management, and IT asset management (ITAM) practices have changed.
• Users expect full capabilities on any personal device.
• Virtual desktops are switching to the cloud.
• Low-code/no-code platforms allow the business to manage their own apps or comanage with IT.
• Work-from-anywhere is the default.
• Users have higher customer service expectations.

Take end-user computing beyond the OS.

Info-Tech's Approach

This blueprint will help you:

• Identify desired benefits that align to IT and corporate priorities and strategies.
• Perform a persona analysis.
• Define a vision for end-user computing.
• Define the standard device and app offerings.
• Improve the supporting services surrounding devices.
• Develop a roadmap for implementing your strategy.

A good device is necessary for satisfaction with IT but it’s not enough.

If a user has a prestigious tablet but the apps aren’t built well, they can’t get support on it, or they can’t connect to the internet, then that device is useless. Focus on supportability, use cases, connection, policy – and device.

Your challenge

This blueprint will help you build a strategy that answers these questions:

• What types of computing devices should be offered to end users?
• What provisioning models will be used?
• What operating systems are supported?
• How will IT support devices?
• What are the policies and governance surrounding how devices are used?
• What actions are we taking and when?
• How do end-user devices support larger corporate priorities and strategies?

Definition: End-User Computing (EUC)

End-user computing (EUC) is the domain of information and technology that deals with the devices used by workers to do their jobs. EUC has five focus areas: devices, user support, use cases, policy & governance, and fitness for use.

A good end-user computing strategy will effectively balance:

User Choice

Cost

Risk

The right balance will be unique for every organization.

Strike the right balance

The discussion is larger than desktop support

If IT is an influencer, then you get to drive this conversation. If IT is not an influencer, then you need to support whatever option the business wants.

Good devices are necessary for overall IT satisfaction

BUT

Good devices are not enough for high satisfaction

A bad device can ruin a person’s satisfaction with IT

Info-Tech’s CIO Business Vision has shown that when someone is dissatisfied with their device, their satisfaction with IT overall is only 40.92% on average.