Crowded backlog? A product is more than the sum of its features

We often find businesses in a stage of growth where they are experiencing problems caused by an increasing number of customer requests and requirements. They missed the moment when their success created the need for a different approach to their requirements and customers. The consequences? The backlog is out of control and no one can keep track of it. Promised delivery dates are not kept, and there are increasing complaints from customers that their requested features have not been implemented. Their developers can’t keep up and it’s unclear how to prioritize the requirements. They expect to be able to cope with the massive workload by using standardized documents and clearly defined processes.

When customer requests get out of hand

The requirements in these companies emerge from the departments, customers or sales and are seldom overseen by product management. The developers’ to-do list grows with the promised customer requirements to an almost unmanageable level. Most of the time, the solution is predetermined and contractually agreed, sometimes even before a technical expert is called in. The sales strategy is based on specific configurations and extensions for the customer. They want as many customers as possible irrespective of industry or market and therefore easily lose sight of their core business.

Due to the lack of a central management of requirements, ambiguities arise even before they reach development. The result is uncertainty in everything that follows. One of the many negative consequences is that the development team can no longer keep up and compromises on quality in order to finish on time. Releases fail and more and more bugs are produced. The delivery is delayed and with it the subsequent deliveries for all other customers. Stable planning is no longer possible. It’s a vicious circle that’s hard to escape.

Back to the core through requirements management

In order to get the situation under control, a fundamentally new way of dealing with requirements is needed. A central product management team aligns related requests for different customers and ensures an implementation that satisfies everyone. By not explicitly specifying solutions in a contract, they gain flexibility in finding the best solution and don’t run into a ping pong game with the customer due to not delivering exactly what was requested and written in the contract.

Furthermore, the maintenance of these systems becomes easier again and adjustments to the core of the software require less effort. Without this change, it is only a matter of time before the system collapses. Customers might turn away due to the poor quality. Employee satisfaction drops because they want their work to be stress-free. And, at some point, the software itself can no longer be maintained.

The product has to be more than the sum of its features. These companies need a plan, a goal, a strategy. They have to find the way back to their core business and develop a strategy and vision for their product. This results in software architecture requirements and a roadmap that gives the entire company structure and direction. Awareness of make-or-buy decisions also helps to focus on what actually defines the product and not to clutter the software.

When these companies implement a solution specified by the customer, they cannot ensure that it is really what the customer needs. Interviewing the customer about the reason for the requirement, which problem it solves for him, and the impact he wants, clarifies the context of the requirement. It makes it possible to find implementations that solve these problems much better than the formulated implementation of the customer. This results in a better understanding of the use of one’s own product. When the producer knows how and for what purpose the customer is using the product, he is again an expert on his own product. He has a better understanding of what is still missing in the product and uses the customer’s input as feedback and a request to find a suitable solution.

Constant communication with the customer is all the more important in order to understand how they use the product and which functionalities are more important than others. Have they found a workaround to solve their problem? Are there any quick-wins to make the customer happy?

Implementing what customers really need

In order to offer the customer the greatest possible added value, we as coaches recommend an iterative and agile approach. Requirements are divided into standalone, end-to-end features and implemented incrementally. The features with the greatest benefit are prioritized. User stories and acceptance criteria replace standardized and rigid requirement documents. This fosters the creation of a common understanding of what is really needed. Development teams and product managers learn to work together to find a solution to the requirements. Changes and features are delivered more frequently, but in a smaller form. In this way, the customer can give direct feedback and product management can better understand what makes the customer happy.

The more advanced the product, the more important it is to have a functioning product management that can maintain the focus on the big picture and has an overview and, above all, an understanding of, the requirements. In this way, the company as a whole cannot avoid adapting to this new way of dealing with requirements and its customers and the resulting change in the system. The software architecture needs to be reviewed and may require major changes, and the development teams have to be prepared for the new approach. In addition, the management has to revisit the sales strategy if it will no longer accept all customer requests.

A team of coaches supports the change

Such an extensive change is a great challenge for a company. In order to support this change in the best possible way, it is best to work with a team of coaches with different focuses. Product coaches help with topics in the area of ​​requirements and strategy. They can coordinate their work with agile coaches and technical coaches and thus achieve a holistic effect across the areas.

Product coaches support with alignment of the product and the handling of requirements.
Agile coaches support the establishment of conditions for an agile framework and self-organized teams.
Technical coaches help the teams with the practical implementation of agile software development and architecture.

Together, the coach team maintains an overview and supports the management in pursuing their strategy in the change process. With this wide range of support and advice, we help our customers to scale in all areas of their company.