Agile product management – Follow the road of smart innovations

Creating a successful product step by step

Where customer, technology and business meet, it’s all about agile product management, as we describe it here. To maintain a balance within this triangle, you should define a framework that supports you in this endeavor:

1. SELF-ANALYSIS: Take an in-depth look at your specific market segment, get to know your competitors and define your niche.
2. CUSTOMER ANALYSIS: Get to know your customers. What challenges and problems do they face and what solutions would they like to see?
3. PROBLEM ANALYSIS: This involves taking a closer look at the challenges faced by your customers and validating them. Various criteria can be evaluated for this purpose:
   • Root cause research: Ask questions, for example follow the 5 Why questions, to get to the source of a problem so that you can do more than just treat the symptoms.
   • Frequency: Find out the frequency with which your customers experience the problem in question.
   • Extent: Determine the proportion of your target market that regularly experiences the problem and is limited by it.
   • Measurability: Provide a sample calculation to quantify costs & benefits for your customers.
   • Actuality: Check your specific market segment for new developments and predicted trends.
4. SOLUTION FINDING: To do this, develop your implementation plan and proceed using measurable criteria.
   • Ranking: Prioritize which problem needs to be solved most urgently and whose solution consequently has the greatest benefit. You make the decision by evaluating the customer benefits, the implementation effort, the profit opportunities as well as the required work effort/skills, etc.
   • Scheduling: Define milestones, a target date and create a detailed plan including estimated duration of the different steps for the implementation – this helps at the same time to further qualify the ideas and possibly adjust the scope.
   • Communication: Create a story for your customers and visualize it. To do this, define the end user, highlight his or her problem, describe the benefits of using your product, and know the requirements for high market acceptance.
5. REALIZATION: Stick to your schedule and get active.
   • Most Viable Product: Create the MVP and validate its key features. Also collect user feedback to measure prediction accuracy and impact. Duration is about 1 – 2 months according to the Think Big – Start Small approach.
   • Marketing: Plan and set-up the different tools for customer interaction (sales, support, customer targeting). Duration is about 2 – 4 months.
   • (Re-)Launch: Write announcements, identify key customers, identify support bottlenecks. How are customers using your product?
   • Statistics: Even with the first stage of the launch, it is important to collect data. What feedback do you get from your customers? Compile criteria for Key Performance Indicators (KPIs) to adjust functional requirements, make improvements and react flexibly to potential changes in the market.
6. REVISION: Review progress regularly against measurable data to make improvements.
   • Checkpoints: Track KPIs to review previously established measurable indicators based on data. Record and visualize results.
   • Deficiencies: Plan improvements based on forecast accuracy, data on user engagement and feedback, and the number of critical defects.

Agile product management in practice

The design of agile product management in large companies is always a challenge, especially if the planning and cost aspects are mainly based on a standard approach. For example, when mean value, portfolio and project evaluations are evaluated about once a year and assigned to the respective clusters.

For a product that only serves a specific area or function, agile product management is somewhat easier than for products that define the organization on a global level, where product ownership is not on the business but on the IT side. This makes sense, as these services are referred to as platforms and infrastructure and are intended to create synergies of a cross-divisional nature, which does not necessarily make planning easier with a divisional top-down planning process.

On the other hand, if the impact is so significant that more or less your entire team needs to be involved, changes that impact actual end-users will be difficult to reconcile with your platform alignment. The effort involves the challenging balancing of your stakeholders who are already using your platform, their new requirements and on top of that, potential new customers who want to be served at the same time.

1. Example: Agile product management for enterprise-wide services

Depending on the service design, agile product management can be influenced by various factors that need to be considered for planning. As a rule, services combine a large number of products and technologies, all of which are subject to their own lifecycle. If, in addition, there is a general change of architecture for one of the core components, the question of cost and benefit arises, as this may also entail massive migration efforts.

Here it makes sense for you to consider whether a general platform change could possibly be more cost-effective and also more innovative. In this case, you need to arrange an early information of the provider about these major implications and a good cooperation in order to allocate the necessary budget and to proactively address its impact on the overall project and portfolio planning as well. Take this time to generate stakeholder awareness. Once the budget is allocated to the service owner, the project for this change can begin.

Big bang approaches may not be effective here; an agile approach to rolling out the new architecture in this case should take the approach of moving forward process by process if the service is connected to multiple E2E processes that impact B2C satisfaction. The platform itself and the preparation of the backend then follow a rather classic rollout approach. This results in an “agile waterfall approach” – hybrid approaches are often the better concepts for lifecycle management of critical enterprise services.

2. Example: Agile product management E2E for an external IT provider with overarching cloud philosophy

Agile product management from the developer’s point of view should meet some requirements:

• Pursue a “DevOps” philosophy, or ensure that at least some self-managed services are in place from the product owner’s perspective.
• Sufficient free resources should be available in the infrastructure and it should be scaled horizontally so that innovations are not slowed down by shortages from the start.
• An effect-based allocation at the application level makes system owners responsible for costs in order to act conscientiously with the resources made available.
• Medium resource pools should be available with established housekeeping services.

Once these basic pillars are established, the basis for agile development is created. Another point is the awareness of responsibility and acceptance that errors are possible and that an internal service culture with service responsibility should be established. Reviews by internal auditors and security should add value rather than create fear when a problem is found. A service catalog within the organization can help.

It is worthwhile to have a central architecture team to take care of the strategy, assisting with product portfolio management through appropriate processes. Avoid a hero attitude of (full-stack) developers because in complex organizations nobody can know everything and besides that, it is harmful for the team spirit – at least to our thinking.

Make sure that communication and collaboration platforms are in place to support the agile product management. This gives customers the opportunity to make requests and product management is able to communicate the new features. The entire organization should operate as a team with clearly defined responsibilities. It might also be worth thinking about the Lean approach here, as learning is also important in this approach. Regarding this, we have another interesting article: This is how you succeed in the CUCA World.

3. Example: Product management in an IT consulting company for tech-savvy startups (first step into product ownership)

Guiding IT consultants into a product owner mindset is a challenging task. Often they know the philosophy of agile product development, but they don’t fully understand project management (what needs to be done by when). This is because the majority of IT consultants are used to receiving instructions from the outside. They are hired to perform the implementation according to standards that may have already been set by the client. During the testing and release of the product, they are usually no longer involved and will ultimately not come into contact with the customers.

This problem has nothing to do with their personal attitude, but is rather in the nature of the business. Consultants look for the solution that seems best for them, possibly without thinking about maintenance and cost effects as well as skill and knowledge transfer. Therefore, the essential attitude of taking full responsibility from the product owner’s point of view might not yet be fully present. It is completely logical that this will not happen overnight. Therefore, it is quite possible that management will have to make a decision. However, such issues are usually not part of the agile product development approach, even though this is a parameter to manage a product from a 360-degree perspective.

It might be sensible to follow the lean approach here, where failure is allowed and understood as a learning opportunity rather than a defeat. The entire organization, including management and leadership style, should be adapted to this and seek support if the change from a pure IT consulting company to a company with product ownership is to be made.