Site icon akquinet AG – Blog

Agile Roadmaps in Software Development

Artikel in deutsch ⤴︎

In general, every software solution requires a roadmap, as the basis for targeted further development and so it can be adapted to users’ needs in the coming years. No matter which niche the software serves, it always represents a form of reliable standard for its users. As a result, features are rarely removed, since this is perceived as a loss and impacts user acceptance.

Normally, the product manager is responsible for planning and marketing software. This person is the product-market expert for his or her specific area. The product manager develops a product strategy, known as the roadmap. Software releases are generally implemented in the form of a project, with the help of a project manager. Project and product managers provide each other with significant support by sharing their experiences.

Product lifespan

Thus every software business plan includes a roadmap that makes it possible to market the product over the coming years. One important aspect needs to be taken into account: the product lifespan. Regardless of the ideas and customer requirements associated with a product, every product reaches its limits at some point in the further development process. In our experience, a limit is reached after about seven years, when the cost-benefit ratio no longer allows for economical further development. The reasons for this:

The user’s perspective

Users want the best possible support for their current problems. In addition, they want to be courted with new features, and ideally should feel like they have chosen the best product.

Users have a limited understanding of the aspects that influence a product’s lifespan. They notice the end only gradually, as the software feels more and more staid and old-fashioned. Looking around, they may discover better alternatives, which they will eventually try out if the product manager does not work actively to improve the product’s lifespan. New features are gratefully accepted, but users are reluctant to pay for them. The market is relentless.

The Kano model

This model, named for Noriaki Kano, makes it possible to record customer requests and their effects on users. It includes three important classes of features:

It is clear that a product cannot be exclusively based on one class of features. The right combination is important.

Software development practice

The product manager’s strategy takes the product lifecycle into account along with the users’ needs.

Let us assume that approximately two new releases are put on the market every year. In order to sell them in a targeted way, each release needs to tell a story. Ideally, this story is a healthy mixture of all three feature types.

In particular, the ease of maintenance for more complex and distributed applications is all too often forgotten or even eliminated, since its benefits are a hard sell both internally and externally. In the process, people often forget or underestimate the additional costs that will result from seven years without upgrades to the application, and the subsequent dangerous drop in user acceptance. If the software no longer appropriately supports day-to-day work, it results in additional, hard-to-calculate costs for the user due to inefficiency and a lack of productivity. In the worst case, users will decide not to stay with the application, and will change providers.

Constant upgrades to the application lay the foundation for a gentler, more cost-effective transition to a new version of the software. That prevents the “maintenance grab” that can occur when old software is not canceled and when support becomes more and more expensive as a result.

The basis for the roadmap

In our experience, the contents of a roadmap should always be based on the Kano model, and should be distributed as follows:

The specific distribution chosen depends on many different aspects, and naturally it varies from one release to the next. Still, no one area should be heavily underrepresented, in other words no less than 20%.

How does a roadmap gain flexibility?

In the course of a product’s lifespan, the software constantly faces new challenges from the market. In addition to the strategic content of a roadmap, there is a need to respond flexibly to these challenges at all times.

The foundation for the roadmap’s flexibility comes from an agile approach to software development. That is the only way for the product manager to benefit from the following advantages:

Thanks to these options, customers can respond quickly to changing market demands with a new roadmap, and can gain an advantage over the competition: “time to market.” The project manager must be able to respond appropriately to these changes during the course of the project.


The product manager can only create an agile roadmap in collaboration with the project manager. The product manager relies on advice from the project manager, who lays the groundwork for possible solutions by using the entire project team’s technical expertise and an open, transparent analysis of the technical implementation requirements. Consistent reviewing and categorizing of the individual features as required, desired or optional makes it possible to break down each feature into its own roadmap.

The project management must remain focused on these useful change options for agile software development. Long-term project plans need to be flexible but controllable, without losing their focus on the required performance, deadline and cost standards. Using this approach, our project managers have had many good experiences with our customers’ product managers when it comes to setting an agile fixed price.

Tassilo Kubitz

akquinet tech@spree

Exit mobile version