Tag: product management

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.

Requirements Prioritization

Beyond the Limits of One-Dimensional Lists

Prioritizing requirements for a software release is an activity which frequently crosses the border between science and psychology. The goal is to determine the right set of things to do for a release. For many IT projects this turns out to be a moving target.

In software product development, requirement priorities are set by the product manager. Typically a product manager focuses exclusively on the market need of a requirement and its selling potential. Excellent software companies look at additional factors as well:

  • Cost
  • Risk
  • Fit to product strategy and architecture
  • Ability to deliver

Creating estimates for these factors cannot be done by a single person. Experts from different domains are needed.

There is a couple of techniques available to cope with this issue. Most of them are based on “cost-value” approaches. In my projects, I have applied a variety of them ranging from simple to complex ones. Often we started with something similar to Karl Wieger’s requirements prioritization approach (see www.processimpact.com).

Ultimately, these techniques yield a list of requirements ordered by their relative priority. Such a list is charming because you can always pick the most important requirement next. It is so charming, that this approach has made it into today’s most prominent development approach: Agile methodologies. In agile projects, the term “product backlog” describes a priority-ordered list of work items, which are addressed from top to bottom.

However, there are some shortcomings with these approaches, which need to be overcome in industrial practice. The key problem is the underlying assumption that requirements can be prioritized independently from each other.

Experience shows that this is seldom the case. Most requirements are interdependent from other requirements.

Across many industry domains including software and IT, the fundamental approach to building a system is always the same: A high-level plan is decomposed until the units of work are manageable. Elements of such units share some characteristics. They belong to the same domain and have similar complexity. Rating such elements in relative order works well. However, if the elements are from different domains, you may run into problems: They might have architectural dependencies which cannot be addressed in isolation. Many times, I saw projects getting stuck, because one team was waiting for something that another team had decided to lower in priority.

This problem of deadlock situations can be addressed by explicit dependency management. In requirements engineering, the concept of traceability is used to manage dependent work-items. Directional links express dependency relationships. These techniques exist and are available in most modern requirements management tools. However, in practice, these solutions can be very hard to accomplish, because they require more discipline than most projects are able to bring up.

So I recommend to deploy lightweight traceability using tagging mechanisms at requirements. Sometimes multiple backlogs are used. Each backlog holds items from the same domain. I have seen such approaches working pretty well in many project situations. So they might be the optimal solutions with the right mix of rigor and flexibility.

And don’t forget the importance of communication: Whatever approach one uses, it will be successful only if it is accompanied by good communication structures in the organization.