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.
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.
Andreas Birk published the article “Pfade zum Requirements-basierten Testen” in issue 17 of the German SQ Magazin. He elaborated several paths how to achieve requirements-based testing. In summary: Test manager can benefit substantially from an established requirements process. Therefore it’s in their best interest to take action and drive the requirements practice in their organizations.
The SQ Magazin is available from the ASQF website.
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.
Recently, Gerald Heller an I discussed about metrics used in agile development, agile testing metrics in particular. We found quite a number of relevant metrics and sought a way to structure them. Partly inspired by Brian Marick’s testing quadrants (see Lisa Crispin’s presentation), we ended up with a matrix spanned by two dichotomous axes.
The first axis (horizontal axis) distinguishes between coordinative and analytical metrics usage. Coordinative metrics are well-suited to directly support project activities, information needs, and decisions. Examples are tracking of work item status or burndown. Analytical metrics are used as input to investigations and analyses as they are conducted, for instance, in iteration retrospectives. An example is story cycle time, which shall be investigated at the end of a release in order to look for improvement opportunities for subsequent releases.
The second axis (vertical axis) distinguishes between internal and external metrics target groups. Internal target groups are the members of an agile software development team. External target groups are other stakeholders such as development management and product management.
The following figure shows our proposed agile metrics grid along with a number of categorized agile metrics. The grid helps guiding metric definition and clarifying the role that a given metric plays for agile development.
The agile testing grid is described in more detail in issue 4 of Agile Record, a magazine for agile developers and agile testers.