Was ist so speziell am Produktmanagement für Software und Internet-Angebote?

Schon bei der Definition des Produkts und insbesondere der Produktfunktionalität hat man bei Software und Internet-Angeboten mehr Freiheiten als bei physischen Produkten. Software ist sehr flexibel und man kann damit fast “alles” machen. Diese große Freiheit stellt eine Herausforderung dar, denn es ist im Gegenzug oft schwer, zu fokussieren oder sinnvolle Kombinationen von Funktionalitäten zu definieren.

Auch beim Geschäftsmodell und bei der Preisfindung gibt es bei digitalen Gütern große Freiheitsgrade: zumeist sind die Grenzkosten sehr gering, d.h. sobald das Angebot einmal verfügbar ist, kostet es fast nichts, es einem weiteren Kunden zur Verfügung zu stellen. Damit sind z.B. Freemium-Geschäftsmodelle möglich, bei denen die Mehrheit der Kunden eine Grundversion des Angebots umsonst nutzt und nur eine Minderheit für eine erweiterte Funktionalität zahlt.

Versuchen Sie so ein Geschäftsmodell mal mit einem physischen Gut, zum Beispiel als Automobilhersteller: das Basis-Modell gibt es umsonst, und anspruchsvollere Kunden können dann optional zum schnelleren Modell oder zum Cabrio wechseln und nur dann müssen sie etwas bezahlen. Würde sicher helfen, Marktanteile zu gewinnen, aber es ist klar, warum das nicht geht.

Aber auch hier gilt: der höhere Freiheitsgrad macht die Aufgabe des Produktmanagers schwieriger, denn z.B. bei der Preisfindung ist einer der klassischen Einflussfaktoren, nämlich die Stückkosten, wenig hilfreich.

Einerseits stehen Produktmanager für Software und Internet-Angebote also vor speziellen Herausforderungen, andererseits hat die Branche spezifische Techniken entwickelt, um mit diesen Herausforderungen besser fertig werden zu können. So unterstützt beispielsweise das Instrumentarium des Requirements Engineering die Produktplanung und Qualitätssicherung und hilft damit den Produktmanagern, die Herausforderungen bei der Produktdefinition zu meistern.

What’s so Special about Product Management for Software and Internet Offerings?

When defining a software or internet offering and its functionality, one enjoys a much higher degree of freedom compared to physical products. Software is extremely malleable and one can implement nearly “everything” in software. The high degree of freedom creates challenges, though, as it makes it difficult to focus and to determine meaningful combinations of features and functionalities.

Same with the business model and pricing for digital goods: usually, marginal cost is very low, which means once the offering is available, it usually costs next to nothing to serve one more customer. This enables for example the “freemium” business model, where the majority of customers uses a base-level offering free of charge, while only a minority pays for advanced functionality.

Try using this business model with physical goods, for example with cars: customers get the base model free of charge, and only the more demanding customers that need a faster car or a convertible pay for their car. Well, while this would certainly boost market share of the car manufacturer, it’s pretty obvious why this is not a viable business model and price structure.

Here again, the higher degree of freedom increases complexity for the product manager. For example in setting prices, one of the classic influencing factors is unit cost – which doesn’t provide much guidance for goods with very low marginal costs.

So, product managers for software and internet offerings do face specific challenges – but on the other hand, the industry has developed specific techniques to address these challenges. For example, the discipline of requirements engineering that supports product planning and quality assurance, helping product managers to better deal with the challenges of defining the product offering.

Was ist eigentlich Produktmanagement?

Selbst innerhalb der Software-Branche verstehen viele die Rolle des Produktmanagers nicht ganz. Vielleicht kommt hier in Deutschland noch erschwerend hinzu, dass in der Umgangssprache Marketing hauptsächlich mit Werbung und PR assoziiert wird. Dann gibt es ja auch noch die Rolle des Produktmarketing-Managers, die oft nicht klar getrennt ist vom Produktmanager – und schwupps wird vermutet, dass der Produktmanager das Werbegenie hinter einem Produkt ist.

Natürlich sind Werbung und PR für den Verkaufserfolg wichtig – das Produktmanagement setzt da jedoch noch viel grundsätzlicher an, denn Produktmanager sind verantwortlich für ein Produkt vom Markteintritt bis zur Abkündigung. Das Ziel jedes Produktmanagers ist es, mit dem Produkt über den gesamten Lebenszyklus den größtmöglichen Wert – dies bedeutet in der Regel die größtmöglichen Gewinne – für das Unternehmen zu erzeugen.

Dafür entscheidend ist die richtige Produktstrategie, von der Bestimmung der Zielgruppe bis zur Entwicklung eines Business Case, sowie die Produktplanung über Produktgenerationen hinweg. Neben diesen Strategie- und Planungsarbeiten verfolgen Produktmanager regelmäßig die zuvor definierten Meilensteine der Umsetzung sowie Erfolgsmetriken und passen falls notwendig, die Vorgehensweise an.

What is Product Management, Really?

Even within the software industry, many professionals misunderstand the role of the product manager. Perhaps this problem is compounded by the fact that in German colloquial language, marketing is often treated as a synonym for advertizing and PR. On top of that, we also find the role of product marketing manager which is not always cleanly separated from the product manager. That way, people quickly end up suspecting the product manager to be the wizard behind product-specific advertizing.

Of course, advertizing and PR are important for driving product sales – yet, product management determines product success on a much more fundamental level: product managers are in charge of a product from market entry to obsolescence. The objective of the product manager is to maximize the value generated from a product – usually measured in the profits generated – over the entire life cycle of the product.

Key to product success is a suitable product strategy, from target segment definition to development of a business case, as well as product planning across product generations. In addition to these strategy and planning initiatives, product managers continuously track previously defined implementation milestones and success metrics and take corrective action as required.

Who Owns the Requirements

When it comes to the question of who owns the requirements the answer is sometimes surprising.

Depending on the titles used in an organization we may hear requirements analyst, business analyst or product manager. Others might name development manager, solution manager or system analyst. While all these people have to say a lot about requirements the product manager should have overall responsibility for the requirements.

Why that? Well, it is the product manager who is ultimately responsible for the business success of the product. He provides product direction and sets the goals for product releases. Through his direct connection to customers and the market he knows best what customer problems are and understands current offerings of competitors. Therefore he is optimally equipped to guide the business team.

Unfortunately, in most organizations the product manager is a poorly defined role. Often product managers get many things to work on, typically too many to be effective. A recent study clearly indicates that product managers work too often on tactical tasks, like customer escalations and supporting sales inquiries.

Successful organizations understand that product management must be balanced between tactical and strategic tasks. However due to the lack of a common understanding of all these tasks it is often a time consuming ineffective effort. Tools that provide an overview of all product management activities accelerate this work substantially.

In October 2010 I gave a presentation at the German “Requirements days” in Munich where I presented some of the fundamental activities in software product management.

Interestingly I got quite some feedback from people, who see a need for clarification specifically in organizations who move towards agile. The simple approach that a product manager equates to a product owner in Scrum doesn’t work out well. On the other extreme product managers might position agile product development to effect only the development organization. They continue to work as before not realizing the full potential of agile development.

Independent whether a software organization works agile or traditional a framework of software product management activities will enable them to improve its effectiveness. That’s why the International Software Product Management Association (ISPMA) pushes towards a certification of software product management.

If this topic is of interest to you, then get in contact with me and/or download the presentation.