Is Product Management slowing Agile down?

We have interviewed researchers, product managers, management, developers about Agile and Product Management. Watch the video for an interview with Carina Alves on Agile Speed in Ecosystems or download the Whitepaper for the full article at the end of this blog. 

The agile methodology promises and delivers increased R&D speed. For the first time in IT history, we have met companies where the R&D is no longer the bottleneck for generating new business.

But will the increased speed directly result in a revenue increase? Just because the development went agile does it mean that the customer contracts went agile? No. Very few clients in the Business to Business (B2B) arena have signed such contracts.

So, we still have a waterfall-sales and an agile R&D. Where is the translation from waterfall to agile being done? In most organizations, this transformation is found in the product management group.

In all too many organization, the speed of Agile is not leveraged, due to the shortcomings of the product management set up.

The new responsibility of the Product Manager

Compare the waterfall way of working with going from London to Rome by riding a moped with taking the new Agile Yamaha VMAX (1679 cc). You as a product manager are the driver. The skills needed to steer and avoid crashes are immensely different between a moped and VMAX. Learning to ride the Yamaha will give you speed and joy. But if you carry on in the same way of making decisions and driving you will crash.

The Product Management must be sized to fit the Agile way of working and also learn new skills to succeed.

To avoid slowing down the Agile speed a change is needed. We have found three low hanging fruit where the process needs drastic improvements

• Go to market – Launch
• Generating the backlog for success – elicitation and idealization
• Building Product Management team

Go To Market

We worked with one company that suddenly realized that R&D was no longer the bottleneck. The customers and the sales complained about the speed of getting new updates and fixing bugs. Due to Agile, the development speed tripled. Now, they just had to be satisfied, right? Well, not so fast…

The sales and marketing weren’t able to handle all the information on the new features and fixes. The customers got confused when continuously finding new functions. The manuals were not updated (not that anybody ever looked up then, but still…). The support organization suddenly got more and more requests.

To solve the situation the sales and marketing were forced to get more training and information on the continuous development. Clients got happier, sales got more skilled, but the CEO was angry. The sales towards new customers decreased. Sales were too busy handling the existing customers. Marketing spent time informing customers, the help desk cost increased.

But worst of all was that many cool new features were introduced without new price plans were introduced.

Nobody had in their wildest dreams thought that an increased speed in development would result in lower profits.

To solve the above situation and similar situation you need to change some key areas:

• Principle 1: Just because it is developed doesn’t mean it should be launched.
  Every launch every change has a cost. Often a hidden cost.
• Principle 2: Separate updates with new valuable functions.
  Functions that go beyond the existing contracts and obligations need pricing. They need to be sold separately. While other functions and bug fixes need no commercial process to be implemented.
• Principle 3: Define target applications or target segments
  Allow some sprints only to focus on new customers and not the existing clients. Sometimes we need to listen to the new revenue stream not just the old.

Generating the backlog for success

As the speed increases, we must also generate more input? We must become faster in generating the RIGHT input. There are three main ways of doing this:

1. Defining and communicating your Strategic Assets, especially target applications and segments. 

This means that we make sure that everyone is knowledgeable about the direction and especially where to look for input.

2. Developing your process 

Develop your process in how to prioritize and allow requirements to be developed. The process of how you are grooming your backlog is of course important. It should stop all requirements that do not generate a great financial impact or that are instrumental in achieving the strategy.

3. Define Opportunity areas

Identifying areas of growth for different applications, segments or geographical areas. We have found the third way with opportunity areas to be successful as a concept. It is an easy way of communicating the strategy. It will make sales start looking for customers in the right arena and automatically you will start getting the relevant requirements of the relevant markets

Building the product management team

The Product management workload increases as we go agile. The risk that the Product management gets blamed for any mistakes can decrease speed.

• You need to enlarge the Product Management organization to fit into an agile environment.
• You need to build skills in an agile product management organization
• You need to build teams.

The workload and stress for a single product manager will be too large. Many agile organizations have seen their critical product managers leave the organizations due to the poor way of working.

Let Product Management enable the Agile speed by adopting an agile way of working.

We have interviewed researchers, product managers, management, developers about Agile and Product Management. Watch the video for an interview with Carina Alves on Agile Speed in Ecosystems or download the Whitepaper for the full article.