Software Product Management for Startups - The ISPMA-Compliant Study Guide and Handbook

1.  Introduction

Startup – the term sparkles and is associated with adventure, freedom, innovation, entrepreneurship, and also big money in case of success. It is a subject of fascination for both the entrepreneurs as well as other readers of business literature alike. Scores of books are published every year on various aspects of this subject covering the perspectives of both academia and practitioners. Product Management is critical for the success of a startup, but often goes under the radar while other aspects of entrepreneurship take the spotlight. The purpose of this book is to serve as a study guide and handbook for practitioners in startups, i.e. newly formed companies, and also corporate ventures, i.e. new product development units that work in a startup mode in established companies. For better readability, we are going to use the term startup for both variants. The book accompanies the training course SPM for Startups of ISPMA (International Software Product Management Association). It also enables a critical appreciation of the art and science of software product management in the context of startups for readers in academia and the industries.

Product management is a discipline, which many industries have utilized for decades, above all the consumer goods industry. The invention of product management as an explicit management concept is attributed to Procter and Gamble. In 1931, the company assigned one product manager to each of two competing soap products (see [Gorche11]). Since then, this basic idea has become widespread. In fact, it makes sense for any company to manage explicitly the products that generate its revenue and that, as assets, represent the company’s sustainable value. But what does product management mean? Unfortunately, only parts of this question have a general answer. The activities of the product manager depend largely on the type of product involved, the culture, history, and company organization, and the target and reward systems. Product management means planning and coordinating all relevant areas of a product inside and outside the company with the aim of ensuring and sustainably optimizing product success.

The focus of this book is to describe the purpose and tasks of software product management in startups and how to perform them well. We follow a best-practice approach and make use of any techniques that help founders and product managers, from whichever methodology they come, be it Lean, Agile, Kanban etc. In our experience, while methodologies come and go over time, tasks remain the same. Therefore, we do not use temporarily marketable terms like Agile Product Management or Lean Product Management. The prime objective of a product manager is not to follow any particular fashionable methodology, but to take care of his tasks in the best possible way, and thereby make his product successful over its life cycle.

Software has become highly pervasive. There is hardly any industry that is not increasingly dependent on software, be it as part of their products or as the backbone of their business operations. A good example of that phenomenon is the automobile industry. The software contents of cars have increased significantly over the last 10 years. In more and more industries, software is turning into the number one value driver.

Software has also become important in our private spheres. Many use software to manage their private lives and to communicate with others. Software has started to be critical for addressing the big challenges of our societies. For example in the healthcare area, internet-based apps empower patients and their caregivers to make decisions for themselves. This empowerment allows expert healthcare staff to serve more patients for less cost per patient. Another example are Smart Homes.

In several decades of experience in the software industry, the authors have come to realize that knowledge and experience acquired in other business areas and with other types of products are only partially transferable to software. We believe that software is the most complex product of human invention that we know of. That complexity implies that the management of software products is unique and puts unique demands on the persons responsible for this task.

A software product manager’s job is special because software is special, i.e. the characteristics of software are different from most other products and have a strong influence on what a software product manager does. The most conspicuous differences are:

•  High complexity,

•  High frequency of change over the life cycle of the software with the resulting great importance of requirements management,

•  Ability to interact with customers through the product,

•  Flexibility of re-configuring the product and adapting it to new purposes and usage contexts,

•  Culture of searching for lightweight approaches to building and evolving software,

•  No or little need for physical manufacturing and distribution.

•  Special financial picture due to high initial development costs followed by relatively low marginal cost,

•  Increasing returns through network effects

A software product manager’s job in a startup is even more special and challenging compared to that in a mature product company. The most prominent differences are:

•  Startups, especially those in the early stage, need a critical mass of customers to shape the customer and user insights. Hence the choice of the early customers as well as the level of dependence on them can largely predicate the future of the product,

•  Startups have a significant amount of freedom to shape the roadmap as well as the priorities for the releases,

•  Startup organizations are usually small and may not have all the functions well-staffed and hence are dependent on the ecosystem partners. This may not be the case for new products in large and mature companies, but they too may have their share of challenges in prioritizing the specific needs of the new products,

•  The business priorities and hence the business metrics of a startup product are different from those of mature products.

When Hans-Bernd Kittlaus published his first book on software product management ([KiRaSch04]) and his second book on Software Product Management and Pricing ([KittClou09]), there were not too many publications on this subject available. When Software Product Management – The ISPMA-Compliant Study Guide and Handbook ([KittFric17]) came out, the situation had changed significantly. Since then, the number of SPM-related publications has further increased, there is more focused research in academia, and there is an increasing number of commercial SPM training offerings available. Hans-Bernd’s latest book is  Software Product Management – The ISPMA-Compliant Study Guide and Handbook, 2nd Edition ([Kittlaus22]) which covers software product management in more mature organizations.

These changes are to some degree due to the establishment of International Software Product Management Association (ISPMA, www.ispma.org). First convened in 2009, ISPMA is a non-profit organization with SPM experts from the industry and academia as Fellows. Various types of membership are open to interested companies and individuals. ISPMA’s goal is to foster software product management excellence across industries (for more information see sect. 7.4). ISPMA’s fellows have developed a curriculum and a Certifiable Body of Knowledge (SPMBoK) that have become the basis for a high number of commercial training offerings and university courses. Hans-Bernd Kittlaus is one of the founders of ISPMA, and its current chairman. Haragopal Mangipudi is a member of ISPMA’s Board, current Chairman of ISPMA’s North American Chapter and former Chairman of ISPMA’s Indian Chapter.

1.1 About this Book

This book provides an integrated view of software product management for startups. While there are many common aspects between the product management practices of mature products and startups, the emphasis of this book is on helping the founders and the product managers in the early stage startups to appreciate the differences and prepare to address them. 

The target group of this book is everyone involved or interested in software product management in startups – founders and product managers in startups, investors, incubators, accelerators as well as academia and students.

With this book, the authors intend to provide an in-depth coverage that is compliant with ISPMA’s Body of Knowledge(as of August 2023) documented in ISPMA SPM for Startups Syllabus V1.1.

The reader can use this book in a supporting role to prepare for the ISPMA certification exam SPM for Startups. However, the primary source for preparation is always the current release of the corresponding syllabus and the corresponding training.

We introduce the ISPMA Software Product Management (SPM) Framework for Startups in chap. 3. The remaining chapters will follow that structure.

The scope of this book is limited to software product management in startups. To understand software product management in a wider context, in particular in more mature product organizations, readers are advised to refer to Software Product Management – The ISPMA-Compliant Study Guide and Handbook, 2nd Edition [Kittlaus22] that is compliant with ISPMA’s Body of Knowledge (as of August 2023) documented in these syllabi:

•  ISPMA SPM – The Foundation V.2.1

•  ISPMA SPM Excellence in Product Strategy V.2.1

•  ISPMA SPM Excellence in Product Planning V.2.0

•  ISPMA SPM Excellence in Strategic Management V.2.0

•  ISPMA SPM Excellence in Orchestration V.2.0.

This book makes use of parts of [Kittlaus22] which are directly relevant in a startup context with the intention to provide all information relevant for startups in one place. [Kittlaus22] does the same for all information relevant in more mature product organizations.

This book’s structure is as follows. Chapter 2 discusses the business of software in broader terms with special focus on business models. Chapter 3 gives an introduction to software product startups – their meaning and purpose, their priorities at various stages and criticality of software product management in startups. We define relevant terms and introduce the ISPMA SPM Startup Framework. Chapter 4 describes the tasks and activities related to product strategy in startups – we discuss the importance of product-market fit and how startups go about in achieving and sustaining it. Chapter 5 focuses on product planning. Chapter 6 covers strategic management from a founder’s perspective. Chapter 7 looks at the aspects the founders and product management function in a startup should keep in mind as the product evolves into a mature business. It also presents some information on ISPMA.

1.2 Conventions

Before we begin our in-depth discussion of SPM, we need to clarify several conventions used throughout this book. Terms such as manager or director are meant to be gender-neutral, that is they refer equally to persons of all genders. While women increasingly participate in IT management, we have chosen a convention of referring to such positions using the male pronoun. This is not intended to be in any way discriminatory and was chosen simply for the purposes of easier readability. We use terms like development or marketing with small characters when we mean the activity, with capital characters when we mean the organizational unit.

We use the term startup for both newly formed companies and corporate ventures, i.e. new product development units that work in a startup mode in established companies. We use the term software vendor to mean companies whose primary business is the development and provision of software for commercial purposes for a relatively large number of consumer and business customers. Examples are Microsoft, SAP, Oracle, IBM, Google, Samsung and Huawei. We use the term corporate IT organization for organizational units that are part of companies in all industries and whose primary mission is to provide software or IT support for the parent company or corporation, which we call corporate customer. In that sense, software vendors are corporate customers of their internal IT.

The term service has many different meanings (see Webster’s Dictionary). The following three meanings are relevant to this book:

•  Useful labor that does not produce a tangible commodity (as in professional services)

•  A provision for maintenance and repair (as in software maintenance service)

•  The technical provision of a function through a software component that can be accessed by another software component. Such access often occurs over a network and executed on a remote server (as in web services, Software-as-a-Service, or Service-Oriented Architecture)

Whenever we use the term service in this book, we try to make it clear which meaning we intend. When we use the term controlling we mean performing the functions of a (business or financial) controller.

All references to the role of  Software Product Manager in this syllabus should be read as applicable to the Product Manager in a startup organization or for a new product in a mature business.

ISPMA® is a registered trademark of the International Software Product Management Association e.V.. For better readability, we use ISPMA without the trademark sign.

And now, we can jump right into the secrets of software product management.

2.  All Products Are Becoming Software Products

Marc Andreessen, the Netscape founder, said it already in 2011 ([Andrees11]): Software is eating the world. Since then we could see it happening live. At the World Economic Forum 2019, the CEO of Volkswagen, Herbert Diess, said publicly Volkswagen is turning into a software company. Organizationally, he separated the development of software from hardware development. In the banking industry, we have been witnessing the more and more important role of software and the decline of traditional physical branch offices.

The statement All Products Are Becoming Software Products may still sound like an exaggeration. What about potatoes? What the statement really means is The business models behind all products are becoming software-driven, and software is becoming the major value-driving component of most products. Even with potatoes, in developed countries, the supply chain as part of the business model is already software-driven today, e.g. with blockchain technology.

Product management has become an established discipline in many industries since Procter and Gamble introduced it in 1931. During recent decades, most software product companies—like Microsoft, IBM, and Google—implemented software product management (SPM). So did some corporate information technology organizations across essentially all industries, as well as some companies that produce software embedded in software-intensive products and services. The role of software product manager has emerged during this time as being of strategic value since it is crucial to the economic success of a product.

This chapter puts software product management into the context of software as a major business component. It defines relevant terms and characteristics and looks at software from a business perspective. The business context, definitions, and scenarios will help the reader to understand how to implement the many practices that a software product manager has available to him to ensure the success of his product in a startup environment.

2.1 Product Management for Software: Terms and Characteristics

What is a software product and what is it not—or not yet? What role does the price play? How should we classify services offered on the basis of software?

In this chapter, we attempt to define the terms software product and embedded software, and to discuss certain features of software and their relevance to products and product management.

Marketing defines the term product as follows: a product is anything that can be offered to a market for attention, acquisition, or consumption that might satisfy a want or need. (see [KotArm15, p. 256]).

While products typically address bigger markets, if not mass markets, we want to include internal customer-supplier relationships as well. Therefore we consider the relationship between two parties at the core of our definition.

Product = A combination of material or intangible goods and services, which one party (called vendor) combines and evolves in support of their commercial interests, with the intention to transfer defined rights to one or more second parties (called customers).

Software product = Product whose primary component is software.

The phrase in support of their commercial interests should make clear that it refers to business but does not necessarily lead to payment. There is also a commercial interest behind Open Source. Even a product free of charge (e.g. Adobe’s Acrobat Reader) has a commercial goal—to increase market penetration of another product from the same software vendor that is subject to a fee. The phrase defined rights expresses that there is some room for variation here, e.g. right of use (possibly with restrictions), property right, and right of resale. Details are typically defined in the software vendor’s licensing terms or an individual contract between the parties concerned.

This product definition should also be construed as to be meaning that an item may already be a product before it has actually been purchased by a customer. Software does not become product through the process of being purchased but through the intention to make it available as a useful entity to third parties, either inside or outside one’s corporation, for monetary consideration or otherwise.

In establishing the boundaries of what a software product is and is not, we have knowingly chosen a flexible phrase: the word primary should make it clear that there is room for discretion.

Still, a mobile phone is not a software product according to our definition (rather a telecommunication product), even if software is an important part and may have absorbed a large proportion of the development costs. In this case, we would be talking about embedded software. Here, embedded software serves most of the functionality and is, therefore, an underlying part of the whole product. The embedded software cannot be bought separately. We define:

Embedded software = Software parts of software-intensive systems that are not marketed, made available, and priced as separate entities.

Embedded software does not manage and operate only a computer or a processor, but rather is included in a technical system that consists of other components. All components together allow the whole thing to become a product. Embedded software can be the software for programming and managing a machine, diagnostic software for finding errors in an automobile, or software for servicing a dialysis machine in medicine. These programs serve highly specialized interfaces, which are typically very closely integrated with hardware.

The requirements and the product management for embedded software are driven by the functionality of the complete system that we call a software-intensive system. Software-intensive systems can be products from many industries like cars, airplanes, and smartphones. Software-intensive services, often delivered as cloud or internet services, can also be products from any industries like financial, insurance, gaming, social software, or personal services based on software support. To facilitate  the reading of this book, we will use the term software products to include  software-intensive products.

Another important term in this context is OEM product. OEM stands for Original Equipment Manufacturer. We define:

OEM software product = software product of software vendor A that is used by company B as an integral undisclosed component of one of B’s products.

The term OEM was originally coined in the hardware business and later transferred into the software world. It means that one manufacturer sells one of his products to another manufacturer who uses it as a component in one of his products without showing its origin openly. We differentiate OEM companies from integrator companies, the former offering products to customers, the latter a system development service to a specific customer.

Notice that B’s product can be, but does not have to be, a software product. A vendor is usually willing to sell his products as OEM products at a significantly reduced price to increase his volume while protecting retail price by not revealing overtly the presence of his product or its OEM price.

Let’s look at some more examples. A games console is also not a software product (rather a games product). The same arguments are valid here as for the mobile phone. A game for this console – purchased separately, separately packaged with its price and own terms of licensing – is by our definition a software product, however.

An online bank account is not a software product in our terminology. Rather, the account is a banking product implemented with the help of software products. The bank’s customer receives online access to his account from his bank, which allows him to carry out bank transactions (bank balance enquiries, transfers, establishment of standing orders, etc.) at home or wherever he happens to be. The software is only useful and usable in connection with the account. So the account is the primary component.

A search offering like Google qualifies as a software product even though that may be contrary to some people’s intuitive understanding. It does fulfill all the criteria of our definition: there is a commercial interest, the customer gets the right to use it, and its primary component is software. This approach builds on the Software as a Service model (SaaS).

The term solution is quite popular from a marketing perspective since it implies that a customer’s problems are addressed and solved. It is used by both product vendors and professional service organizations.

Solution =

(a)  A product that is a combination of other products, human services, and possibly some glue code and customization.

(b)  A combination of products and customer-specific code that is developed and implemented for a specific customer.

Examples for (a) are the Stripe platform and SAP’s solutions for different industries or lines of business. An example for (b) is the result of a customization project in which a professional service provider customizes an SAP system for a specific customer.

Software product management means the management of software products and software parts of software-intensive products (systems or services), i.e.  embedded software, with the objective to achieve sustainable success over the life cycle. This generally refers to economic success, which is ultimately reflected by the profits generated.

The startup situation is special: Based on the given vision the purpose of software product management in a startup is to build and update business model and strategy by devising, conducting and executing experiments and using the learnings from each of such iterations. This is the fundamental difference in the purpose of software product management in startups compared to software product management in a mature business. Therefore, all references to the role of Software Product Manager in this book should be read as applicable to product management function in a startup organization or for a new product in a mature business.

In the software product space there are a number of terms that need clarification. One of them is product platform. McGrath defines ([McGrat01]): A product platform ... is a collection of the common elements, especially the underlying defining technology, implemented across a range of products. A product platform is primarily a definition for planning, decision making, and strategic thinking. The choice of a defining technology in platform strategy is perhaps the most critical strategic decision that a high-technology company makes. So we define:

Product Platform = the technological foundation on which several software products are based.

A product platform is not necessarily an independent product, but rather a combination of technological elements used in various products. Such a product platform often constitutes a valuable asset and serves as a market differentiation factor known as defining technology. Therefore, the product platform requires