It is of utmost importance for a corporation to have deep insight into trends and developments in the markets it wants to play in, and into the competitive landscape, including competitors’ strategies. The same holds true on the product level, where the product manager needs reliable information. Larger corporations often have specialized market research departments that act as internal service units for product managers. They conduct their own research and/or collect and evaluate information from market research agencies. In smaller companies, the product manager may be required to do this.

A product manager needs, at any time, to be able to know where his/her product stands in order to take action if needed. This is usually done based on measures that are defined as relevant indicators of the business performance of the product (see section 2.9). In some companies, these numbers are provided by central corporate units, e.g. in Finance; in other companies, this is the product manager’s task. In any case, the product manager needs to ensure that reliable numbers are available on a frequent basis. Some companies make a set of well-defined measures mandatory for all products in the portfolio in order to achieve comparability.

Product positioning includes

• Value Proposition: value definition from a customer perspective for the target market segments
• Focus with regard to the target market and segments, the company product portfolio, and the product life cycle phase (e.g. revitalization)
• Channel options
• Partnerships and alliances

The product definition needs to define:

• Functional scope
• Quality scope
• Intended use and users
• User experience (UX) design scope
• Offering architecture
• Business architecture (for application software)

The offering architecture defines separately priced components of the product offering and tailorability options in line with the tailorability strategy. The business architecture is relevant for application software and is domain-specific, i.e. covers logical data model, process model, business object model, etc. This is the responsibility of a business architect. For any architecture considerations, tight cooperation between the product manager and architects is required.

When working on the product definition, the product manager has to take the company’s compliance guidelines into account. The product manager might need to address product-specific compliance issues that are not covered by the company’s guidelines, in particular, the areas of sustainability and ethics. It is good practice to document the complete set of components that determine the offering, although that will typically be separate from the product strategy document.

Based on the product definition, the delivery model needs to address the following items:

• Licensed product vs. service offering (e.g. Software-as-a-Service, SaaS)
• Degree of tailorability, including tailorability strategy
• Mode of delivery (online access, online download, combination with services, etc.)

Tailorability means the enablement of the product for customer- or market-specific adaptations by providing properties that can be changed after system development. The categories of tailorability are:

• Configuration: setting or changing parameters
• Composition: adding or arranging components
• Customization: adding or changing program or descriptive code

The tailorability architecture defines these options in more technical detail as part of architecture management. The service strategy needs to define the services that are part of the total offering and who is supposed to provide these services. If external partners are to provide services this needs to be aligned with the tailorability strategy and ecosystem management.

A software ecosystem is defined as a set of businesses functioning as a unit and interacting with a shared market for software and services while maintaining beneficial relationships. These relationships are frequently underpinned by a common technological platform and operate through the exchange of information, resources, and artifacts.

Organizations can take on different roles in ecosystems, such as:

• Keystone: controlling the ecosystem from the strategic position of platform owner, but leaving space for other actors
• Dominator: controlling the ecosystem from the strategic position of platform owner, striving for complete control
• Niche player: not the platform owner, but benefitting from the ecosystem through specialization and avoiding conflict with keystones or dominators

Product managers are greatly influenced by the role their respective organizations wish to play in a software ecosystem, and the extended network of the organization is of increasing importance for the daily work of the product manager. It is not typically part of the responsibilities of a software product manager to decide upon the strategy and role that his/her company aims to play in an ecosystem, as these decisions are usually made by executive management. However, once these decisions are finalized, they have a significant impact on the work of the product manager.

Sourcing needs to address the following topics

• Sourcing options for human resources. There are a number of motivations for working with external human resources, such as:
  – Need for specialized skills not available internally
  – Need for more capacity, e.g. developers, than available internally
  – Cost savings due to lower labor cost in nearshore or offshore locations.
• Make or buy decisions for software components. There are a number of motivations for not developing a piece of software internally, such as:
  – Focus on time to market
  – High quality and low cost of an externally available software product
  – Restrictions with regard to internal capacity, technology, and skills

The dependency on an external software provider resulting from a buy decision needs to be managed thoroughly from a business perspective.

Pricing needs to address the following items:

• The importance of price with regard to business success and customer value
• Market- and value-based pricing
• Problems of cost-based pricing for software offerings
• Strategic Pricing Pyramid (price strategy, policy, level)
• Typical pricing models for software, including freemium

A product manager may have different roles with regard to pricing:

• Be the pricing manager, or
• Cooperate tightly with the pricing manager and define requirements regarding price structures and price policies
• Guide Sales regarding price structures, price policies and price levels for the product
• Support marketing regarding price and value communication for the product

The primary objective of software product management is to achieve sustainable success over the life cycle of the product (or platform or family). This generally refers to economic success, which is ultimately reflected by the profits generated. Since profits lag behind investments, i.e., an investment phase involving losses will be followed by an extended profitable phase, a longer-term perspective is appropriate. Therefore, the product manager has to plan and track financial aspects both from a short- and long-term perspective. This is called financial management and is tightly linked to pricing. It includes the representation of the product on the corporate level.

There are a number of concepts and models relevant to the financial evaluation and product investment decisions:

• Investment evaluation models – such as NPV, ROI, Pay Back Time
• The concept of Opportunity Cost and the necessity of identifying the alternative to an investment
• The concept of Cost of Delay and how time affects the business case for a proposed investment
• Different financial management objectives during different Product Life Cycle Stages (PLC)

Software product managers need to consider several legal aspects specifically related to software products. Details are typically handled by legal experts (e.g. counsels), but product managers need to have an overview of the legal risks they bear in their role responsible for the sustainable success of the product. First, there are contractual issues between the software vendor and the customer. Then, there is the protection of intellectual property. Third, there are specific risks such as governance, finance, supply chain, delivery commitments, product liability, data protection (especially for SaaS, in Europe, in particular, the General Data Protection Regulation (GDPR)), open source license conditions, laws on general terms and conditions, blacklisting of countries for specific software components, etc. which are increasingly relevant (see, for instance, the growing impact of governance rules and transparency laws).

The contract by which software is “acquired”, maybe individually negotiated or, particularly in the mass market, based on so-called “terms and conditions,” which are subject to regulations, in particular, if the customer is a consumer. Be it in a contract or in standard terms and conditions, the required legal terms, include:

• Scope of the license or service
• Guarantee and Warranty / SLA
• Transferability
• Type of charges
• Liability
• Maintenance provisions (a separate maintenance agreement may be concluded)
• Miscellaneous legal provisions (e.g. set-off, default, dispute resolution, governing law, severability clause)

Performance management involves continuous tracking and analysis of selected relevant measures and taking timely action if needed.
Relevant measures can cover different functions, such as development, support, etc. Especially important from a product management point of view is business measures. Product managers need to establish clarity over which business measures are really important: Which measures are actually used by important stakeholders to determine the success of the software product? These measures are ultimately used to assess the performance of the product manager. Here are the candidates:

• Financial performance:
  • Revenue metrics such as monthly recurring revenue (MRR), average revenue per user (ARPU), and customer lifetime value (CLTV)
  • Profit and loss (P&L) metrics such as gross margin and EBIT
• Market performance:
  • Market share, the share of (market) growth, the share of (customer) wallet
  • Customer acquisition costs (CAC), the share of market spend
• Customer performance:
  • Customer satisfaction score (CSAT) and net promoter score(NPS)
  • Customerretentionrateandchurnrate
• Organizational performance:
  • Speedmetricssuchastime-to-market,time-to-revenue, customer time-to-value(TTV)
  • Cost metrics such as cost of quality (COQ) and customer onboarding cost

Risk management requires continuous tracking and analysis of risks identified in connection with the development, sales, distribution, delivery, and customer use of the software product, and taking timely action if needed.

Creating and evolving products that meet the ever-changing needs of customers requires an excellent understanding of the problems and the environment in which customers operate. Product managers must therefore work towards such an understanding. In this context, the term “customer” is used for all types of customer-side stakeholders, like users, buyers, IT managers, owners, operators, etc.

Two complementary approaches for gathering accurate customer data are available: Direct contact with customers and indirect through the use of data analytics methods.
Typical direct contact activities are:

• Customer visits
• Meeting customers at conferences, workshops, and events
• Organizing customer round tables (focus groups)
• Design sprints with customer participation
• Supporting selected pre-sales activities
• Participating in support escalations
• Participating in online forums

Regular participation and engagement help to keep abreast of issues and trends facing existing customers. Direct contact with customers not only supports an analytical understanding of their problems but may also create empathy. Collecting relevant customer data is only the first step to creating insights. Software product managers need to feed this data into discussions with stakeholders and use it for requirements analysis, as well as business modeling.

Product management is responsible for a product along its entire life cycle. Each life cycle phase has its individual characteristics and focus areas. In the first three phases, investments are necessary to develop the product. During the maturity and decline phases, the product serves as a cash cow, i.e. it generates significant revenue with rather little investment. The resulting profit can be used to finance other products in the portfolio.

Product management must have a solid understanding of the various phases in order to develop strategies and activities that optimally support a product in a specific phase. This requires tight cooperation with the involved functional units within the company. The life cycle responsibility encompasses product-related knowledge management, i.e. the product manager needs to ensure that the knowledge required for the viability of the product continues to be accessible and available to the company during the product life cycle.

Continuous measurement of a product’s performance is a prerequisite to drive corrective actions if needed. Therefore, a product manager must monitor and analyze how well the product is performing. This includes product profitability, actual versus planned revenue, customer satisfaction, and market share.

Product roadmapping translates the long-term product strategy into a series of releases that satisfy the business goals of the company and cover the strategic time frame, i.e. between one and five years. A product roadmap usually contains the following basic elements:

• Timescale
• Releases and versions
• Release themes and main features
• Target markets
• Product dependencies
• Technology impacts

Product roadmaps are constructed for internal and external audiences. Internal roadmaps set the scope for specific product releases. They provide the basis for forecasting, budgeting, and the instantiation of projects for the development of specific product releases. They also help with the alignment of product strategies within a company’s portfolio. External roadmaps are used for communication with customers, market research analysts, or investors. They are a means to communicate strategy, receive feedback on it, and build trust in the commitment of the company to long-term continuous investment in the product. High-level release themes from the roadmap are key elements in guiding the release planning process.

Release planning is concerned with defining the detailed contents of a forthcoming product release in order to maximize the value of the release in relation to the product’s success over its life cycle. It needs to be tightly linked to the product requirements engineering process.

The release planning decisions balance opposing forces. On the one hand, the selected product requirements need to satisfy business objectives and real customer needs, while leading to a recognizable advantage over competition. There needs to be a balance between technology push and market pull, i.e., innovative features and customer requirements. On the other hand, the selected requirements need to account for the capabilities and capacity of the product organization, while being compliant with time and budget constraints and architectural considerations. Other influencing factors can be customer commitments and sales and marketing activities such as fairs. Release planning involves negotiations and setting priorities to resolve conflicts between stakeholders about release contents and interests that are pursued with the evolving product. The release planning decisions ought to be based on strategic guidelines, e.g. to what degree the company is reactive to its markets by giving priority to customer needs or pursuing a proactive innovation strategy by pushing new technologies to the markets. Results are documented in a release plan that all stakeholders finally have to agree to. Typically, this is an iterative decision-making process involving the stakeholders in requirements engineering and release planning. The software development approach can also have an impact since agile development requires the software product manager’s ongoing involvement in decisions about release contents and synchronization with release planning.

Requirements engineering in a software product management context covers typical requirements engineering activities such as elicitation, analysis, specification, validation, and management, adapted to a market-driven situation with many customers, competitors, and suppliers. Three requirement types can be distinguished and must be managed separately: functional requirements, quality requirements, and constraints.

Requirements can be raised from different sources:

• Stakeholders e.g. customers, users, user groups, business experts, executive management, partners
• Data sources e.g. literature, social media, market analysis, product strategy, company guidelines, analytics, standards, and regulations
• Systems in operation e.g. other existing software products, competitive analysis

A product organization needs a dedicated process to deal with requirements in a systematic way.
Traceability is used to understand the origins and implications of requirements. It allows following the path from the original requirement to the software implementation and back. Traceability is sometimes required for legal reasons.

As requirements evolve throughout their life cycle, they are often specified in standardized documents or in the form of sorted lists called “backlog”. For each requirement, standard attributes are used. To minimize misunderstandings, language templates can be used to specify functional requirements in natural language. To further increase the precision of a specification, the semi-formal graphical specification can be employed, e.g. use case diagrams to summarize the services of a system provided to its direct context. Quality requirements can be specified qualitatively, by example, operationally, or quantitatively.