Skip to main content

The roadmap explained

Software development is characterized by more uncertainty than other industries. The dependencies on other software packages, the surrounding services and their quality and reliability, as well as the complexity of the tasks to be solved vary greatly and can sometimes only be recognized in full depth during the implementation of a solution. This often leads to unexpected hurdles, which in turn can cause delays. There is hardly an engineering discipline where the gap between what would be possible at a certain point in time and what is actually possible is so wide.

Development in small steps

We deal with this by developing iteratively, typically in short, rapidly consecutive development steps. At the end of each step, we can learn from our experiences and then adjust the solution and - less frequently - our goals if necessary. We therefore take small steps, abandon unsuccessful attempts and look for alternative solutions, or continue on the path that was successful.

We also define our primary development goals in relation to the roadmap as follows:

  1. when we announce a release date for a product version, we want to stick to it. Delays are expensive, for us and for our customers.
  2. in terms of content, we primarily stick to the content defined for each half-year period.

In concrete terms, this means

  • We only tackle features and improvements that are not defined for the respective development period if we have sufficient time and resources to do so.
  • Features and improvements that turn out to be too complex are only delivered in an initial version or their development is stopped as early as possible.

How well we succeed in meeting these targets depends on how well or poorly we can assess a particular task. With our new products, this is relatively easy because they are new. In the case of our tried-and-tested products, which are more complex and already in use in many places in various sectors, this is much more diffcult.

Information at three levels

We provide information at three different levels so that you can follow what we are working on.

  • The Products Roadmap on our website only lists the important topics we want to work on. It is high-level and thus offers a less detailed view of our development planning. It is aimed at new customers as well as customers with a predominantly professional interest in our products.
  • The technical roadmap is aimed at specialists who require additional, more technical details and need to know roughly when they can expect which feature or improvement.
  • The Release Notes provide details about new features and improvements in the current and previous versions of a product. They are part of the respective product documentation (e.g. here for the release notes of docuteam box).

Two stages of development and implementation

We divide our development plan into two stages of implementation.

In progress: high to medium certainty

For work packages that we mark as "in progress", we are confident that we can deliver the features and improvements announced with them.

Outlook: less certainty

Outlook names features and topics for the next development period. They still need preparation and sometimes a better understanding of the requirement or issue on our part. This is an intention. The decision as to whether and how exactly such features and topics will be implemented has usually not yet been made, which is why changes can be made at any time.