Strategic Management

Abstract

Strategic Management is an activity within an organization with the objective to define, plan, agree, implement and evaluate the organization’s strategy. It is part of the responsibility of executive management who can delegate preparatory work to staff functions. Strategic Management includes a number of elements related to software product management (see the ISPMA SPM Framework in Sect. 2.5). Software product managers are typically not responsible for any of these activities, but they either participate in them, e.g. portfolio management, provide inputs, or make use of their outputs, e.g. product analysis.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Strategic Management is an activity within an organization with the objective to define, plan, agree, implement and evaluate the organization’s strategy. It is part of the responsibility of executive management who can delegate preparatory work to staff functions. Strategic Management includes a number of elements related to software product management (see the ISPMA SPM Framework in Sect. 2.5). Software product managers are typically not responsible for any of these activities, but they either participate in them, e.g. portfolio management , provide inputs, or make use of their outputs, e.g. product analysis .

Of course, it is not the objective of this book to provide a handbook on executive management. This is covered by a huge spectrum of publications. However, since a software product manager has the responsibility for his product(s) and thereby a partial responsibility for the success of the whole company, he is very directly involved in some aspects of executive management.

A Software Product Manager usually spends some of his time with the task to represent his product in the internal strategy and planning processes of his company. This includes the market ing and sales plans and the budget and resource planning. The underlying question is which resources will be dedicated to the product in the short, medium, and long term. This decision is based on market and revenue forecasts, the positioning of the product in its life cycle, and the dependencies with other products. From these elements, the product manager puts a “story” together that is used to “sell” the product within the planning processes.

The company’s culture influences how these planning processes work and what is expected from the product manager. Ideally, all involved parties should have the common goal to get to an agreed result that is good for the company. Often, however, these processes degenerate into a competition that the players try to use for their personal advancement. The “winner” is the one who gets most of the resources for his product. Only the executive management can prevent this degeneration. The individual product manager will have to play his role according to the company’s culture, for the good or for the bad.

Typically, the corporate strategy and planning process is a mix of bottom-up and top-down planning. Bottom-up means that each product manager develops a plan from his product perspective. Top-down means that executive management, typically under the lead of finance, looks at the aggregated bottom-up plans and cuts them down to what seems affordable. Since the assigned budget and resources have their consequences on the revenue side, this process is iterated until an agreement is reached. This process serves as a synchronization point at which the plans on all levels and of all products are synchronized. Executive management usually defines the schedule of this process. IBM, for example, goes through two cycles per year, the Spring and the Fall plans.

At this point we want to go into the elements of the corporate strategy and planning process and the role that the product manager plays in them.

5.1 Corporate Strategy

5.1.1 Overview

Corporate strategy is a phenomenon that entered the scene in the sixties of the twentieth century. Since then, many different approaches and tools for strategic management have been developed and are used across industries. These approaches and tools can be traced back to different schools of thought that evolved over time. Some of these tools and approaches are frequently used in modern software organization s. We will focus our discussion on these frequently used tools.

In addition to industry-agnostic approaches to corporate strategy, there are also tools and approaches that have been developed specifically for high-tech markets, including software markets. They have been designed to address the specific strategic challenges of markets that are based on quickly evolving technology, resulting in fast value erosion for products.

Software product managers may have to provide input whenever the corporate strategy is updated or revised, and they need to ensure that product strategies stay consistent with corporate strategy. To achieve this, software product managers need to be aware of the strategy tools and approaches that are used in higher-level strategy processes in their organization. Understanding which key ideas and assumptions are underlying the use of these tools and approaches helps product managers improve their contribution: they can provide more useful input into strategy processes performed at higher levels in their organization and will better understand and use the guidance they receive from these higher-level strategy processes.

5.1.2 Concept

Corporate strategy considers a timeframe that is at least as long as the strategic timeframes of the individual software products. Therefore, the timeframe considered may be up to 5 years, or even longer, depending on the domains covered.

Strategy processes on the corporate level can be triggered or happen on a periodic schedule. A strategy revision may be triggered by major changes in the environment, for example substantial regulatory changes, unexpected major strategic moves by competitors , or technology disruptions. Updates to an existing strategy are typically conducted periodically—tied to the organization’s regular planning and reporting cycle, for example preceding the annual planning cycle.

A corporate strategy process includes activities to develop or update the following strategy elements: corporate vision , mission, values and goals, corporate positioning, business model and financial plan, product portfolio and its evolution, resource and competency evolution, technology trends and innovation strategy, market trends and competitive strategy, policies and governance.

Many of these strategy elements are comparable to corresponding elements on the product strategy level. Figure 5.1 compares the elements from these two different levels of strategy process.

Fig. 5.1

Elements of corporate strategy with their equivalents on the product level

However, there are a few differences beyond the scope of product(s) or businesses being covered. The corporate vision is typically a very short statement, often just one very high-level sentence about a desired future state that the corporation wants to help create. This describes why the company exists. To further substantiate this, it typically is accompanied by a corporate mission that describes on a high level what the company is doing to achieve the vision, plus a statement of the company’s values and goals.

Instead of a product roadmap, the corporate strategy process will look at entire portfolios of products and set goals and boundary conditions for the evolution of these portfolios.

Finally, corporate strategy addresses three areas that do not have a direct equivalent on the product strategy level: Innovation strategy (see Sect. 5.3), resource and competency evolution (see Sect. 5.4), and policies and governance.

5.1.3 Process

Corporate strategy processes are often based on industry-agnostic tools and approaches which can be traced back to different schools of thought that have evolved over time.

In [MinAhlLa08] Mintzberg, Ahlstrand, and Lampel provide an overview on strategic management approaches, identifying ten underlying schools of thought in corporate strategy. They further classify those ten schools into three major groups: prescriptive, descriptive, or integrative schools of thought.

Figure 5.2 provides an overview of all ten schools of thought and their associated tools, based on [MinAhlLa08].

Fig. 5.2

Schools of thought in strategic management—the big 10

The tools and approaches highlighted in the last column of Fig. 5.2 are frequently used in strategic management processes:

• SWOT Matrix: maps internal Strengths and Weaknesses of the organization against the Opportunities and Threats presented by the external environment. This is frequently developed for individual products as well, as part of the market analysis (see Sect. 5.5)

• Scenario Planning: aims to broaden the view of decision makers by developing several alternative long-term scenarios. Each scenario describes a possible future state of the organization’s external environment. For each scenario, the impact on the organization and possible responses are elaborated. This is especially suitable for volatile times and fast-moving markets—that’s why this strategic tool is sometimes used by software organizations. Due to their market understanding, product managers may be asked to contribute to the development of scenarios, or they may contribute to developing the strategic responses in the various scenarios.

• Porter’s 5 Forces: Michael Porter in [Porter79] and [Porter08] identifies five forces that characterize the nature of competition within an industry, also called the industry structure. The five forces are: threat of new entrants, bargaining power of customer s, threat of substitute products or services, bargaining power of suppliers, and rivalry among existing competitors . In [Porter85] he described that only three classes of strategies can be chosen by firms—what he calls generic strategies. These are cost leadership strategy, differentiation strategy, and focus strategy (niche strategy). The 5 Forces model and the generic strategies are routinely taught in management education and are broadly known and used, especially in industries where the costs for manufacturing and delivering products are non-negligible, for example for software-intensive products that include hardware.

• The BCG Growth/ShareMatrix: was introduced by the Boston Consulting Group in 1970 to classify products according to their success in the market vs. attractiveness of the market they participate in. Since it is frequently used in portfolio management as well, see Sect. 5.2 for a more detailed discussion

• Internal Corporate Venturing: where larger organizations encourage employees deeper down in the corporate hierarchy to come up with new product initiatives. These initiatives then compete for corporate funding, similar to startups working to raise venture capital. This is usually part of an organization’s innovation management strategy (see also Sect. 5.3)

• Strategic Alliances and Strategic Sourcing: in today’s markets companies typically act within a complex web of relationships, for example with suppliers, channel partners , and other partners. In that situation, strategy needs to be developed collaboratively with partners. For a deeper discussion of partner relationships, see Sects. 3.11, and 3.8.

5.1.4 Examples and Variations

So far, we have looked at industry-agnostic approaches to strategic management. In addition to those, software organizations may use approaches and tools that have been developed specifically to address challenges of fast-moving high-tech markets:

• Category Maturity Model for high-tech markets: This model described by Moore in [Moore08] helps determine strategic focus areas depending on the maturity stages of the product categories relevant to the organization (see Sects. 4.4 and Sect. 5.3).

• Strong focus on innovation management : Software markets are often moving fast, resulting in fast value erosion—this usually leads to a strong emphasis on innovation management (see Sect. 5.3) and on making sure that the product portfolio stays fresh (see Sect. 5.2).

• Ecosystem strategy: Software organizations often need to maintain a complex web of relationships to other players in the ecosystem(s) they participate in. In that case, determining the role the organization wishes to play in the ecosystem—keystone, dominator , or niche player —is typically part of Corporate Strategy (for more on these roles and the associated strategies, see Sect. 3.11).

• Big data and analytics: in many cases, in particular with SaaS software, software organizations can obtain detailed information on usage patterns and user behavior that helps making strategic decisions.

5.1.5 Outcome and Impacts

The outcome of corporate strategy processes is typically a comprehensive documentation that describes conclusions and next steps, as well as the rationale behind that, i.e. the process used and more detailed information that led to the conclusions. These will be presented in some level of detail to key decision makers of the organization. A simplified subset of the results, focusing on key messages and required changes will typically be circulated further down into the organization.

Software product managers need to understand their organization’s corporate strategy as well as the portfolio strategy so they can ensure their product strategy is aligned with these higher-level strategies.

5.1.6 Summary and Conclusions

Corporate strategy processes consider a time frame of up to 5 years, or even longer, depending on the domains covered. For this timeframe, a wide range of strategy elements are developed or updated: from very high level elements such as corporate vision , mission, values and goals, down to policies and governance. Strategy processes on the corporate level can be triggered by major external events, or happen on a periodic schedule, for example preceding the annual planning cycle.

Software product managers may have to provide input whenever the corporate strategy is updated or revised, and they need to ensure that product strategies stay consistent with corporate strategy.

To achieve this, software product managers need to be aware of the strategy tools and approaches that are used in their organization. Tools and approaches that are frequently used across industries include Porter’s 5 forces, SWOT matrix, BCG growth/share matrix, strategic alliances and strategic sourcing, internal corporate venturing, and scenario planning. In addition, software organizations frequently use tools and approaches developed specifically for fast-moving high-tech markets: Moore’s category maturity model, a strong focus on innovation management , ecosystem strategy, and leveraging big data and analytics to support strategy decisions.

5.2 Portfolio Management

5.2.1 Overview

In any product organization, leaders need to ask themselves regularly: Do we have the right products for future business success? Portfolio management addresses this key question, looking both at the existing product portfolio, and at plans for product evolution and new product development. Software product managers are typically asked to represent their product(s) in the update cycle for the product portfolio .

Portfolio management is a term that is well known in the financial services industry. An investor or fund manager invests the available capital in a diversified way, i.e. in different stocks, securities, real estate etc. The total collection of these investments is called a portfolio. Portfolio management is the management of these investments over time following profit and risk criteria. This same approach can be applied to a set of opportunities to invest in existing and new software products, to decide which products and product development initiatives will receive how much investment over the strategic timeframe.

Since the portfolio management process is concerned with investment allocation, it is typically tied to the regular planning and budgeting cycle of the software organization (periodic activity). In practice, it is often performed on an annual basis.

In the software business, it is especially important to critically evaluate the portfolio on a regular basis, for the following reasons:

• Market needs can change rather quickly: software markets are fast-moving, definitions of market segments can shift over time with new market segments forming, and well-established market segments may become less attractive

• There’s always a danger that new competitors may enter: software markets typically have low barriers to entry and the boundaries between market segments are often fluid, so that vendors in adjacent markets can enter “our” markets, for example by extending one of their products.

• Software is malleable, so even existing products can evolve in many different directions—which can easily lead to uncontrolled growth and lack of alignment between portfolio products, which may create portfolio gaps or unintended overlaps between products that result in positioning and sales problems within the portfolio.

• Software organizations need to make sure they have a balanced portfolio with products in different life cycle stages—in particular, they need to ensure that there is always sufficient investment in new products.

The last bullet is related to the unique economics of software products. Software is characterized by relatively low variable costs (cost of goods sold) and high fixed costs. It typically takes several years for new software products to become operationally profitable, i.e. before product revenue covers ongoing product-related expenses, unless customers are willing to pay for part of the development cost (see also Chap. 2).

Therefore, software organizations need to make sure they invest some of the revenue surplus of more mature, successful products into new product initiatives. They need to make these investments early enough—so that the new products become mature as revenue from the older products stagnates or declines. On the other hand, a successful mature software product is usually highly profitable: it will have high profit margins (profit as % of revenue) and due to its high overall revenue will be an indispensable source of profits for the organization. Therefore, the organization needs to allocate sufficient investment to mature products to keep them competitive, so that the associated revenue and profit opportunity can be exploited as long as possible.

5.2.2 Concept

The portfolio management process reviews the product portfolio whether it still meets corporate objectives and guidelines, covering both existing products and proposed new product initiatives.

The review evaluates the product portfolio from several angles, asking the following questions:

• Do portfolio products meet their respective measures of business success, such as profitability, market share , number of active user s?

• Is the portfolio innovative enough: do we “keep up” the existing products and do we have enough new products in the pipeline?

• How do we want to evolve the portfolio: are there new opportunities that we’d like to take advantage of—with new products or major extensions of existing products? Do we have gaps in our portfolio, for example due to a new market segment that is emerging?

As input into that process, software product managers typically are required to provide the following product-specific information:

• Product roadmaps

• Forecasts of relevant business metrics, for example a multi-year revenue forecast

• And the investment requested for the product.

In addition, product managers are typically asked to provide a summary of the product-specific market analysis, covering market sizing, trends, and competition (see Sect. 5.5), as well as a summary of the product analysis , describing where their product stands against plan (see Sect. 5.6). These inputs may be used by the portfolio management team to complement and extend the market and product analysis they create on the portfolio level.

5.2.3 Process

Portfolio Management for software products follows the same basic methods and processes as any portfolio management. Based on a structured and transparent process, it balances limited resources in order to maximize benefits.

We emphasized already that due to the fast-moving nature of software markets, innovation is a key concern in software portfolio management. To ensure a focus on innovation, software portfolio management often uses the concept of three time horizons that Moore applied specifically to fast-moving high-tech and software markets [Moore14].

According to Moore, “Horizon 1 corresponds to managing the current fiscal-reporting period, with all its short-term concerns, Horizon 2 to onboarding the next generation of high-growth opportunities in the pipeline, and Horizon 3 to incubating the germs of new businesses that will sustain the franchise far into the future.”

To ensure long-term success of the organization, the portfolio should be balanced in the sense of having all three time horizons adequately covered.

Moore contends that Horizon 2 initiatives are the most challenging ones: Horizon 1 covers the existing products which are usually sufficiently equipped resource-wise across the organization, from development to sales. Horizon 1 investments typically deliver a return on investment in the same reporting period they are incurred in. Horizon 3 initiatives are usually conducted in separate lab or research organizations that have their own, separate funding.

In contrast, Horizon 2 initiatives are somewhat lost in the middle: they still need nurturing and investment to become successful products or new businesses, and this nurturing is not part of the research lab’s agenda, it needs to come out of the established businesses. However, the full benefits from these investments will be reaped in the future, typically several years out, and not in the current reporting period.

Therefore, organizations frequently fail to adequately create and nurture Horizon 2 initiatives. To address this problem, portfolio management processes typically look at investment proposals for each timeframe separately, and with a special focus on Horizon 2 initiatives. It can be helpful to allocate budgets to the three horizons top-down upfront, and then do portfolio management for each separately.

To achieve an adequate balance between timeframes, organizations may start with a top-down split of the total investment budget between these timeframes, see also Sect. 5.4 on Resource Management .

5.2.4 Examples and Variations

A key challenge in portfolio management is the need to look at many different products at once, to put them in context, and finally, to prioritize them. To help deal with this complexity, matrixes are commonly used to classify the products and get an overview on the portfolio. These matrixes are typically based on two attributes that are relevant to decision making in the portfolio process.

A popular example is the Growth Share matrix. It was introduced for corporate portfolio management by the Boston Consulting Group in 1970 [Hender70] and is still widely used today. It classifies products according to their success in the market vs. attractiveness of the market they participate in. As indicator for market success, relative market share is used, i.e. market share relative to the number three player in the market. As indicator for market attractiveness, market growth is used (High/Low).

The result is a two by two matrix. According to Henderson [Hender70], the four quadrants of the matrix carry the following meaning:

• “Products with high market share and slow growth are cash cows. Characteristically, they generate large amounts of cash, in excess of the reinvestment required to maintain share.

• Products with low market share and slow growth are pets. They may show an accounting profit, but the profit must be reinvested to maintain share, leaving no cash throwoff. The product is essentially worthless, …”

  Today, these are often called dogs.

• Low market share, high growth products are the question marks. They almost always require far more cash than they can generate.

• The high share, high growth product is the star. “… If it stays a leader, … it will become a large cash generator … The star eventually becomes the cash cow, providing high volume, high margin, high stability, security, and cash throwoff for reinvestment elsewhere.”

The resulting matrix may look like shown in Fig. 5.3. In this example, the matrix represents the entire software portfolio, the color indicates different product families, and the size of the circles represents investment planned for the current year.

Fig. 5.3

Growth Share Matrix for existing product portfolio

In fast-growing and fast-changing markets, portfolio management needs to ensure the portfolio always has cash cows and stars, it needs to critically evaluate the potential of the question marks, and to aggressively exit the pets or dogs.

Many different attributes can be used to build portfolio matrices. In [Cooper00], the following attribute pairs are suggested:

• Risk vs. reward

• Technical vs. market newness

• Technical feasibility vs. market attractiveness

• Competitive position vs. attractiveness

• Cost vs. reward

• Cost vs. time to implement.

Another example that may be used to compare new product initiatives only (Horizon 2) is the Oyster/Pearls matrix that classifies new initiatives by their probability of success vs. expected profit. It may look like this (Fig. 5.4):

Fig. 5.4

Oyster-Pearls Matrix for new product initiatives

Based on this representation of new product initiatives, the portfolio management process needs to make sure investment in the white elephants is curbed: these are new product initiatives that are not likely to succeed, and even if they were to succeed, they are not likely to generate significant profits.

In project-oriented organizations, portfolio management is often applied to the project portfolio. For product organizations, we do not recommend to do that. When you have applied portfolio management to the product portfolio, there is no need to do portfolio management for the projects in which new releases and versions of these products are developed.

5.2.5 Outcome and Impacts

On a portfolio level, one of the desired outcomes is an investment strategy that minimizes risks on the portfolio level and balances the need for short-term profit maximization with the requirement to invest for future success. Another desired outcome is alignment between portfolio products so that synergies can be exploited, for example by optimizing products for upsell and cross-sell opportunities between adjacent products.

Overlaps between portfolio products—in terms of multiple products offering similar value propositions to the same customer groups—need to be managed carefully. Again, it’s a matter of careful balancing: while it may make sense for adjacent products to have some overlaps in their value propositions, so that each product is complete and can be successful on its own, portfolio management usually tries to avoid full, direct competition between products within the same portfolio.

The results of the portfolio update cycle define boundary conditions for the products: In addition to the investment level that will be allocated to the product, product managers will also receive key business goals to achieve, along with target numbers for key business measures, for example revenue or growth targets. Finally, the portfolio management process may define portfolio themes that must be factored into release plans and roadmaps for the product. These boundary conditions, as well as the investment level allocated to the product can have significant consequences for the individual product strateg y.

5.2.6 Summary and Conclusions

Portfolio management uses a structured and transparent process to balance limited resources to maximize benefits across existing products and initiatives for new product development.

A key outcome of portfolio management is investment allocation among competing initiatives in the product portfolio. Therefore, portfolio management is typically tied to the regular planning and budgeting cycle (periodic activity, often performed annually).

In the fast-moving software business, it is especially important to critically evaluate the portfolio on a regular basis to ensure the portfolio still is aligned with market developments, meets organizational goals and objectives, and is balanced across the life cycle stages of products.

Software product managers are typically asked to represent their product(s) by providing inputs such as: product roadmaps, forecasts of relevant business metrics, for example a multi-year revenue forecast, and the requested investment. In addition, product managers typically need to provide a summary of the product-specific market and product analysis .

Portfolio management frequently uses matrixes to classify products and to derive appropriate strategies for each class of products. A popular example is the BCG Growth/Share matrix.

One of the outcomes of portfolio management is an investment strategy that minimizes risks on the portfolio level and balances the need for short-term profit maximization with the requirement to invest for future success. Another desired outcome is alignment between portfolio products so that synergies can be exploited, while overlaps between portfolio products are managed carefully.

5.3 Innovation Management

5.3.1 Overview

Software markets tend to be fast-moving with low barriers to entry. Therefore, they are often highly competitive. Differentiators of software products tend to have a short life time, as competitors are quick to catch up.

This results in fast value erosion for software products: delighter features (from the Kano model, see Sect. 4.2) are quickly taken for granted, turning into performance or even must-have features. Competitive advantage of a software product needs to be constantly re-created—and innovation is one way to address that challenge.

That’s why software organizations typically put a strong focus on innovation, and why software product managers need to understand key innovation concepts: so they can ensure their product benefits from innovation initiatives of their organization.

5.3.2 Concept

Innovation can occur in many shapes or forms: There can be innovation in how to market products, how to expand current business models , or how to improve organizations or processes. Product managers often focus on product innovations that result in new features, new quality aspects, or an improved user experience .

Innovations also have a different level of market impact, ranging from incremental improvements of the current product offering up to disruptive innovations that create new product categories and new markets, replacing incumbent products in the process.

With such a wide spectrum of innovation types to consider, it is important for software product managers to focus their energy and the available investments on those innovations that are most effective. In [GoFrPaKu10], an innovation process is described that works in software environments.

The suitability of an innovation depends not only of the lifecycle stage of the product itself, but also on the maturity stage of the product category. Geoffrey Moore in [Moore08] (see also Sect. 4.4) identifies fourteen different types of innovation relevant to product managers of high-tech products—including software. He presents a model which innovation types to use at a given category maturity stage. For example, application innovation—finding and exploiting a new application or use for an existing technology—is necessary for a new technology product category to achieve initial penetration into the mainstream market. Line extension innovation—creating a new sub-category to engage new customers or to re-engage old ones—helps maintain and even grow revenue in a mature product category.

Since software organizations put a strong focus on innovation, we may find innovation initiatives at different levels of the organization. For example, a large organization might fund a corporate research initiative with the charter to work on “horizon 3” innovations (see Sect. 5.2), which require several years to turn into viable products. It might also fund “horizon 2” innovations that can be productized faster, but still require more than 1 year to pan out. These might be funded through the portfolio management process. Finally, on the individual product level, “horizon 1” innovations can be funded that require <1 year to be productized.

Even with adequate funding of innovation initiatives for the different time horizons, software organizations often find it a challenge to actually benefit from these initiatives. A famous historic example is the failure of XEROX to benefit from the groundbreaking innovations of its horizon 3 research lab XEROX PARC: these innovations included the windows-based graphical user interface (GUI) and desktop paradigm and the computer mouse.

Therefore, it is critical to align innovation management with the corresponding elements of the corporate strategy on a continuous basis. Alignment is required in both directions: When innovation management leads to significant results these need to be incorporated into the relevant corporate, portfolio, and product strategies to transform them into competitive advantage. On the other hand, changes of the corporate strategy need to be reflected in innovation management to align agendas and resources with the new direction.

5.3.3 Process

Creating innovation is a process of understanding problems, available technologies and creating the right ideas to bring them together. It is extremely difficult to order or formalize the innovation processes.

However, an environment can be created to foster innovation. An important element of that is the organization’s culture: an innovation-friendly culture needs to be established and popularized from the top down, where employees are encouraged to come up with ideas, where it is acceptable for innovative attempts to fail without punishing or critiquing the employees, but rather learn from the failure. Processes must be established that allow for the testing and tweaking of innovation ideas.

While it is important to create an environment that fosters innovation, it is also important to have some gates within the company to select the most promising ideas and put some focus on them or reject ideas for which the company may not have the right competencies to implement and is not willing to invest in building up the missing competencies. Overall, this is a challenging task within a company. On one hand, it is necessary to generate many ideas and give them a chance; on the other hand it is important to focus on a few to bring them to success. After all an idea only generates value to a company if it is implemented or sold to someone else.

A great idea is normally never perfect at the beginning and requires many improvement and testing iterations before it matures. This refinement and testing process involves iterations of discussions with customers and the R&D team, creating incremental improvements that are best applied in prototypes, re-testing the concepts and challenging the value. This process can be supported by combining agile development process with customer collaboration.

While creating the innovative environment as well as the decisions which ideas to realize is the responsibility of management, software product managers have the obligation to take advantage of such an environment, spend time for their research in terms of opportunities, come up with ideas together with the team and prepare them well to increase the chances of receiving funding and support for a project. This includes drawing the big picture about the result once the idea has been implemented. Furthermore, it also requires preparing an initial business case for a first overview of the potential financial impact. Other benefits may need to be mentioned and accounted for as well such as user experience , customer satisfaction or customer retention. A good selection methodology is the software value map , as it incorporates many different value aspects for a structured decision.

Gathering this information supports management in making decisions, validating also that a proposed initiative fits into the overall corporate strategy . Once a project is approved or proceeds to the next gate, it is the product management ’s responsibility to select the right users/customers to collaborate with. This is necessary to drive development teams to iteratively work on the project and get quick feedback from real users. These many validation steps ensure quick learnings and corrections before significant investments are made and costs are encountered. It is also important that at every stage gate the progress is being presented and the predictions are being updated. The further a project is, the more reliable the predictions of business impact will become. This is to ensure that should something go wrong or deviate from the corporate strategy, a decision can be made to either stop the project, align the project with the corporate strategy or even to expedite the project.

5.3.4 Examples and Variations

5.3.4.1 Lean Startup

We already emphasized the importance of refining ideas through an iterative process that relies on fast feedback loops with customers. This is especially important for innovations that seek to establish a new product category. An approach to address this special situation has been developed in the Silicon Valley—and the term Lean Startup was coined in 2011 to describe how this approach (see [Ries11, BlanDorf12, Blank13c]). Despite its name, this approach applies not only to startups, but to corporate innovation projects as well.

Driving the iterations is clearly the role of product manager s. They act as facilitators to bring the customer demands together with the developer’s solution and refine them until the value and user experience are optimal. Requirements triage (see Sect. 4.2) is a simple yet efficient tool for understanding which of the suggested ideas are the most suitable and promising. In this phase, it may also turn out that the chosen strategy to achieve the vision is not appropriate. This leads to pivoting, which means the vision remains but a completely different strategy to get there is required.

5.3.4.2 Idea Generation

There are many methods that support idea generation. Among them, Cooper and Edgett in [CooEdg09] have done research on the effectiveness of different idea generation methods.

Figure 5.5 visualizes their findings, mapping idea generation methods by effectivenss vs. frequency of use. The method that is rated most effective is ethnography, which basically means in this context that a product manager or a group of people visit users of a product or performing a job and observe, study and systematically record without interfering the behavior of users, their challenges and possible improvements in their tasks.

Fig. 5.5

The effectiveness vs. popularity of ideation techniques [CooEdg09]. Used with permission

In general, the most effective methods involve customers for example through interviews. On the other hand, the most practiced method is internal idea creation. This is the easiest to execute as someone only has to think of an idea without putting in an effort to visit customers. However, as the result also shows, it is not the most effective idea generation method.

5.3.5 Outcome and Impacts

We already discussed that innovation initiatives can typically be classified based on the time horizon they look at. Horizon 3 initiatives are often driven in some type of corporate research lab, while horizon 2 initiatives may be executed within a business unit and funded through the portfolio process. Horizon 1 initiatives are often driven on the individual product level—although they may affect multiple products and may get “imposed” on the individual product as part of portfolio themes (see Sect. 5.2).

As a result, innovation management impacts the organization on all levels—and it is most closely related to strategy at multiple levels of the organization: corporate strategy, portfolio strategy, and product strategy .

On the product level, the responsibility for aligning with innovation efforts falls on software product managers—they need to ensure that their products benefit from innovation initiatives. Again, this is a bi-directional process: on one hand, software product managers need to understand their organization’s innovation initiatives to determine whether results can be used to benefit their products. On the other hand, they may seek to influence the agenda of innovation initiatives so that they address actual use cases and customer problems: Corporate innovation initiatives are often quite interested in leveraging the deep market insight and customer understanding of product managers to help inform their agenda.

5.3.6 Summary and Conclusions

Since software markets are fast-moving, software organizations typically put a strong focus on innovation so their products and product portfolios stay competitive.

Larger software organizations often establish different types of innovation initiatives that work on different time horizons: from corporate research initiatives with the charter to work on “horizon 3” innovations, to “horizon 2” innovations that can be productized faster, and “horizon 1” innovations which typically are driven on the individual product level.

Software product managers are responsible to ensure that their product benefits from the innovation initiatives in their organization. To do that effectively, they need to understand key innovation concepts, such as

• The 3 horizons framework .

• The category maturity model that suggests which types of innovations are most critical depending on the maturity stage of the market.

• Approaches for iteratively improving innovations through iterative processes that relies on fast feedback loops with customers, combining agile development process with customer collaboration and using Lean Startup techniques.

• Idea generation methods, in particular voice-of-customer methods, such as ethnography.

5.4 Resource Management

On the corporate level, resource management needs to ensure that resources are available in the required quantities and qualities and at the required points in time so that the company is enabled to implement the corporate strategy and the aligned product strategies. This applies to human resources, physical resources as well as information resources. For software, human resources are the most important ones, both in terms of numbers and skills. A software product manager, usually in close cooperation with the responsible line managers, needs to ensure that the resource requirements that result from the product strategy and plan can be fulfilled, i.e. are aligned with corporate resource management .

A product manager’s life would be easier if he could make any sourcing decisions by himself based on the product strategy and the annual budget allocated to the product (see Sect. 3.8). However, that is not the way it works in most companies. Decisions on hiring new employees or making investments in IT equipment or real estate or renting space in different locations are considered as long-term commitments that cannot be made solely based on short-term resource needs. So companies usually establish corporate decision processes for these resource aspects in which the individual product manager is a requestor, but not the decision maker. When there are corporate guidelines for sourcing, a product manager may be a bit more empowered within those guidelines. When external human resources are needed for capacity or skill reasons (see Sect. 3.8), additional corporate rules may apply, e.g. procurement processes that are optimized to keep external spending as low as possible. The efficiency of all these processes can differ significantly from company to company. In other words, it can eat up a lot of a product manager’s time and energy to “fight the system”.

If portfolio management does not only allocate budgets, but also assigns human resources to product teams, that can help the efficiency. For strategic and/or successful products, the core product team should stay quite stable over longer periods of time in order to keep productivity high and reduce or avoid resource managem ent overhead. Human resources are not only a question of numbers, but also of skills. When the product manager can foresee that certain skills will be needed to implement the product strategy , these skills can be temporarily sourced externally, or can be hired as new internal employees, or existing employees can be educated and trained.

If a software product has a very long life people retire or leave the organization for other reasons. It is part of the product manager’s life cycle responsibility to keep an eye on the continuous availability of skills needed to keep the product viable even if the direct management responsibility for this is with other units, e.g. the development manager.

5.5 Market Analysis

5.5.1 Overview

The goal of market analysis is to determine the characteristics of both current and future markets, researching customers, competitors , relevant technologies and economic developments.

Organizations evaluate the attractiveness of a future market by gaining an understanding of evolving opportunities and threats as they relate to that organization’s own strengths and weaknesses.

5.5.2 Concept

It is of utmost importance for a software organization to have deep insight into trends and developments in relevant markets: the markets it plays in, markets the organization wants to enter, other markets where new competitors might come from, and newly emerging markets or market segments .

Market analysis is typically performed on all three levels we discuss in this section: on the corporate level, the portfolio level, and the individual product level. Unless the company has a dedicated market analysis unit, software product managers are responsible for the product-level analysis and provide their results as input into portfolio or corporate strategy .

To conduct a market analysis, software product managers or market research specialists will typically look into the following research areas:

• Market Forces

  • Market issues: Identify key issues driving and transforming your market.

  • Market segments : Identify major market segments, describe their attractiveness and seek to spot new segments.

  • Needs and demands: Outline market needs and describe how well they are served.

  • Willingness to pay: Identify and describe for which features customers are willing to pay.

  • Switching cost: Describe the cost factors customers are facing when they switch to a competitive product.

• Industry Forces

  • Competitors (Incumbents): Identify incumbent competitors and their relative strengths.

  • New entrants (Insurgents): Identify new, insurgent players and determine whether they compete with a business model different from yours.

  • Pricing : Identify price structures and levels prevalent in the selected market segments.

• Key Trends

  • Technology trends: Identify technology trends that can threaten your business or enable it to evolve and improve.

  • Regulatory trends: Describe regulatory trends that may influence your business.

• Quantitative data about the market to support the qualitative analysis

  • Market size.

  • Competitor’s revenue , profit, market share (analysis of the annual reports, if available).

When collecting the information for market analysis, the following information sources can be used:

Primary Research

A fancy word for doing their own research, using

• Direct contacts inside the organization, for example colleagues from marketing, sales, support, other service s, and from development.

• Direct contacts outside the organization, including ecosystem participants such as partners or media contacts, as well as customers.

  Customers may also provide valuable insights into competition.

• Systematic industry studies, from running a survey to commissioning a custom study with an industry analyst or market research agency.

Secondary Research

This means using research done by others, for example industry analysts or market research agencies.

Industry analysts play an important role in IT markets: they are a valuable source of quantitative information, for example current market (segment) sizes, growth rates, market shares. They also provide qualitative information, for example market segmentation, technology and business trends, and newly emerging opportunities.

Internal Market Research Department

Organizations often have specialized market research departments that act as internal service units, which can and should be leveraged by product managers. These departments conduct their own research and collect, evaluate and aggregate information from industry analysts and market research agencies, and provide regular updates to their internal audiences, in particular to product managers. Often, they also control access to the services of industry analysts. If no such market research department is available, for example in smaller organizations, software product managers may need to perform the market analysis completely on their own.

For competitive analysis we need to go beyond simple feature-by-feature comparisons of existing products. We also need to understand the strategies of competitors , their product and portfolio strategies, and their vision . To obtain this information, all the information sources listed before can be used. In addition, the website, documents, and events of competitors will provide relevant information, for example their annual or quarterly reports, materials for investors, product brochures etc.

5.5.3 Examples and Variations

5.5.3.1 Defining the Addressable Market

Defining the market that is addressed by a product is central for market analysis and helps to better understand customers. Several different segmentation models are available, one of them is the Three Level Model proposed by Weinstein in [Weinst04] (Fig. 5.6).

• Level 1—Relevant Market

  • Define Geographic Trade Area = current market served.

  • Define Product Market = current products offered (myopia).

  • Define Generic Market = mass marketing definition (mass market).

  • Relevant Market = Larger than Product Market/Smaller than Generic Market.

• Level 2—Defined Market

  • Defined Market = Relevant Market segmented into penetrated market (existing customers) and untapped market (non-customers).

• Level 3—Target Markets

  • Apply Segmentation Dimensions to Defined Market.

  • Identify Multiple Segments within Defined Market.

  • Select Attractive Segments within Defined Market.

    Fig. 5.6

    

    Example for definition of level 1—relevant market: achieving balance between going too narrow nor too broad

A key benefit of this model is the balance that can be achieved between myopia (too narrow segment definitions) and mass market (too broad definition).

5.5.3.2 Industry Analysts

Industry analysts are a valuable source not only for quantitative market information, such as size of market segments and market share of players within the segment, they also provide qualitative information, for example technology and business trends, changes in market segmentation, and newly emerging opportunities.

There are a lot of smaller boutique analysts that specialize in certain geographic or functional segments. The worldwide leaders conduct qualitative and quantitative analyses on a larger scale, such as IDC (www.idc.com), Gartner (www.gartner.com), and Forrester Research (www.forrester.com). Analysts have different strengths that need to be considered when selecting.

What they all have in common is the relatively high prices that they charge for the use of their research results. Their primary target group are usually corporate IT organizations who use the research results as input for investment decisions. Industry analysts stress their independence, although, in fact, they are forced to cooperate with the software vendors to obtain the information they need. In addition, over time, analysts expanded their business models to include consulting, a service regularly used by vendors and corporate IT organizations alike which can easily lead to a conflict of interests. They also sell research results to vendors who want to use them for marketing purposes.

The results provided by the market research companies are nevertheless a useful source of information, even if one should not rely on them unquestioningly. It should always be remembered that market research companies do not consider it their job to merely penetrate the vendors’ marketing hype and conduct serious analyses, but that they also like to produce their own hype to promote their business. In the end, product managers need to use their own sense of judgment and make business assessments and decisions in consultation with colleagues and superiors and their company-internal market research department (if available).

The fact that market research results are not only input for product management, but can be useful for marketing too, was shown by CRM software producer Siebel (in the meantime acquired by Oracle) in the spring of 2003 when it published the results of a CRM market analysis conducted by Gartner in full-page advertisements worldwide. The advertisement displayed, among other things, the “Magic Quadrant ,” a Gartner evaluation of companies and their products based on a system of coordinates with a “completeness of vision” axis and an “ability to execute” axis. There is no better advertisement for a vendor than to be located in the leaders quadrant, as Siebel was in the majority of the analyzed CRM segments in the above example. In the meantime, IT industry analysts impose very strict limitations on which kind of information can be used in which context: for example, they may allow a software company to use approved quotes in their marketing materials or refer to their position in the magic quadrant. But using the full magic quadrant in ads is usually no longer permitted by Gartner.

Figure 5.7 shows the Magic Quadrant’s skeleton, in which companies are positioned. Gartner describes in [Hawkins08] how a magic quadrant is to be read. The axis “Ability to Execute” summarizes factors such as the vendor’s financial viability, market responsiveness, product development, sales channels and customer base. The axis “Completeness of Vision ” reflects the vendor’s innovation, whether the vendor drives or follows the market, and if the vendor’s view of how the market will develop matches Gartner’s perspective. Figure 5.7 also shows how the individual quadrants should be interpreted (Fig. 5.8).

Fig. 5.7

Gartner magic quadrant (© Gartner, Inc. 2008)

Fig. 5.8

Gartner Hype cycle (© Gartner, Inc. 2008)

Gartner also regularly publishes the Gartner Hype Cycle s, another qualitative market analysis tool that is quite influential in the IT industry. A Gartner Hype Cycle describes the response to new technologies. Gartner defines the terms used as follows (see [FennRask08]):

• Technology trigger: A breakthrough, a public demonstration, a product launch or some other event generates significant press or industry interest.

• Peak of inflated expectations: During this phase of overenthusiasm and unrealistic projections, a flurry of well-publicized activity by technology leaders results in some successes, but more failures, as the technology is pushed to its limits. The only companies making money are conference organizers and magazine publishers.

• Trough of Disillusionment: Because the technology does not live up to its overinflated expectations, it rapidly becomes unfashionable. Media interest wanes, except for a few cautionary tales.

• Slope of Enlightenment: Focused experimentation and solid hard work by an increasingly diverse range of organizations lead to a true understanding of the technology’s applicability, risks and benefits. Commercial off-the-shelf methodologies and tools ease the development process.

• Plateau of Productivity: The real-world benefits of the technology are demonstrated and accepted. Growing numbers of organizations feel comfortable with the reduced levels of risk, and the rapid growth phase of adoption begins.

New technologies positioned on the Hype Cycle do not move at a uniform speed through the cycle. When discussing a new technology, Gartner also provides their estimate how long it will take the technology to reach the plateau of productivity. This is important information that product managers need to consider in their planning activities.

5.5.4 Outcome and Inputs

A large part of market analysis results are graphics, such as market size and market share diagrams, visualization of trends and their impact on markets and on the competitive landscape. Therefore, market analysis if often documented in slide decks, accompanied by spreadsheets providing more detailed numbers and the foundation for charts.

Market analysis results are used in a number of activities of software product management , in particular product positioning, business aspects, ecosystem management, and roadmapping.

5.5.5 Summary and Conclusions

The goal of market analysis is to determine the characteristics of both current and future markets, researching customers, competitors , relevant technologies and economic developments.

Sources for market research can be classified into primary research, secondary research, and the company-internal market research department (if available).

Market analysis also includes competitive analysis . Here, it is important to go beyond simple feature-by-feature comparisons of existing products and to understand the strategies of competitors , their product and portfolio strategies, and their vision .

Industry analysts play a very important role in the IT industry, providing both quantitative market research data, as well as competitor information and qualitative insights into market and technology trends.

5.6 Product Analysis

5.6.1 Overview

Across all industries, businesses tend to become more and more data-driven. In Product Analysis, the data relevant for the management of a product is defined, located or generated, reliably and regularly accessed, aggregated based on agreed-upon definitions, and made available in an appropriate way to everybody who has a need to know. It is typically used by product managers for performance management (see Sect. 3.13) and product life cycle management (see Sect. 4.4), also by executive management as input to portfolio management (see Sect. 5.2) and for operational business management.

5.6.2 Concept

With more and more data being available to companies, it is becoming increasingly challenging to ensure that data is provided to decision makers in a way that increases the quality of decisions. For product-related data, this is what product analysis is about. We differentiate hard measures, a.k.a. key performance indicators (KPIs), and softer measures.

KPIs can be defined in four different areas. Here are often used examples:

• Financial KPIs focusing on the history, current state and plan for:

  • Cost of the product (development, maintenance and support or third party license fees, patent license fees). This information usually comes from the finance and controlling organization.

  • Revenue as well as the existing pipeline of potential customers is analyzed (license, subscription , maintenance and support revenue). This information should come from the sales and finance and controlling organizations. It can be provided per time period, per product version, etc.

  • Profitability, for which product-related cost are subtracted from product-related revenue.

Accounting rules apply to all the financial numbers which means that the numbers from the books may not fully reflect the actual situation. So internally, it makes sense to also look at contracted revenue.

• Customer-related KPIs focusing on the history, current state and plan for:

  • The number of licenses ordered, installed, new, total etc. (for a licensed product).

  • The absolute number of active customers and end users including growth rates and market shares (from Market Analysis) (for SaaS, internet platforms etc.). This can also be used for analyzing customer retention in the later stages of the product’s life cycle. The definition of what is an active customer can be highly political.

  • The maintenance situation in terms of total number of customers, number of release s in maintenance und number of customers per release. This information usually comes from the support organization.

  • The quality situation in terms of number of support incidents and customer escalations per release. This information usually comes from the support organization.

  • Customer satisfaction can be evaluated through some metrics or based on qualitative analysis. Often companies conduct customer surveys on a frequent basis. Customer satisfaction is difficult to quantify. It is generally not determined on the basis of a single factor, but rather as a group of up to 20 variables regarding a range of topics, such as reliability , documentation, usability , service quality, sales coverage, etc. [JohGus00, Myers00].

• Development-related KPIs focusing on history, current state and plan for:

  • Quality during the development process and its relationship to customer-perceived quality (see above).

  • Productivity of the development team.

Some development organizations tend to consider this data as internal, but a product manager needs to look at this data at least on a summary level.

• Product-usage-related information and KPIs:

  • For licensed software products where the runtime environment is under the responsibility of the customer, runtime measurement is usually limited and may require the customer’s agreement.

  • In an internet environment like Software-as-a-Service (SaaS) or a (self-developed) e-commerce platform, measurement is easier, since software and runtime environment are both under the same company’s responsibility. This includes web analytics measuring, click rates and analyzing visitors as well as detailed monitoring how users interact with the software [CrolYosk13]. Some internet companies use customer discovery to test the user acceptance of new features.

This data can be helpful for a product manager’s decisions regarding requirements (see Sect. 4.2).

All the numbers need to be considered over longer periods of time, i.e. not only current actuals, but also in comparison to the history, the plan and budget, and possibly the market (with data from market analysis , see Sect. 5.5).

Customer satisfaction can be considered as one of the softer measures. They also include qualitative input like feedback from market analysts, trade press articles, individual customer feedback, information from the sales channels (like win/loss analysis or opportunities), information from the support and service functions and more.

5.6.3 Implementation

When an organization has more than a few products in its portfolio, we recommend to work with common definitions for the selected measures so that numbers are comparable. Then productivity can be optimized by establishing a central data analyst or team of data analysts who collect the relevant data reliably and regularly, aggregate them, and make them available in a way that helps the decision makers, be it product managers or executive managers. Standardized graphical representations can add value here.

When there is no central product analysis , this is part of the responsibility of each product manager or product management team. In that case, the product manager can focus directly on those measures that are selected and relevant for a particular product. This selection can change dependent on the product life cycle phase (Fig. 5.9):

Fig. 5.9

Key Performance Indicators (KPIs) in product life cycle phases

Even if there is a central data analyst responsible for product analysis , it is important for product managers to fully understand how measures are defined, where the data comes from, and how the numbers are aggregated. This may require some deep-diving. When done for the first time, results are often surprising, like product revenue that is accounted as service revenue (from combined product-service deals), or cost accounted against the product that has absolutely no relationship to the product. Those findings require correction.

The product analysis results are used in a number of activities of software product management , in particular business aspects, performance management , life cycle management, roadmapping, release planning , and product requirements engineering.

5.6.4 Summary and Conclusions

For a software product manager, it is of key importance to have reliable product-related data updated frequently as a basis for decision making. Company-wide standards regarding the selection, definition, data sources, aggregations and graphical representations help the understanding and comparability between products significantly.

5.7 Corporate Strategy Processes

On the corporate and/or business unit level, strategy processes are usually governed by a yearly calendar that ensures that business planning is finished in time for a new financial year. The financial year may not be identical to the calendar year, e.g. Apple’s financial year starts on October 1. At the beginning of the financial year, all stakeholder s within the organization need to know what the objectives, allocated resources and budgets are within which they are supposed to work. Corporate business planning needs to be aligned with an updated corporate strategy which in turn needs to be aligned with updated product strategies. So all this update work can be scheduled on the yearly calendar as well (see also Sects. 3.14 and 4.5).

Documentation of a corporate or business unit strategy can differ significantly from company to company. Some companies go through the annual update cycle with great consequence, in particular publicly traded companies. They usually document the results internally, and publish a subset externally. A documented corporate strategy is very helpful for product managers since they can use the corporate strategy for alignment and also for justification of their respective product strategy.

Unfortunately, there is a surprisingly high number of companies that do not update their corporate strategy on a yearly basis. There may be no need for such an update frequency—that is rare for software—, executive management may be hesitant to document a strategy because they are unsure where they want to go, or there are political reasons for not documenting the corporate strategy. The latter happens frequently in companies where owners and customers are partly identical with corresponding conflicts of interest that the executive management does not want to address explicitly. All these situations make life more difficult for a product manager.