Paradigm shift in software product innovation

We can’t solve problems by using the same kind of thinking we used when we created them
–Albert Einstein

Software businesses are keenly aware of the disruptive forces at play

Over the past year, I interacted with many software companies in my customer ecosystem, and had numerous conversations about the challenges they are facing in terms of software product innovation. I noticed that these businesses have a good understanding of the nature of challenges they are facing with their product stack and the continuous pressure to keep up with technology disruption and changing market dynamics.

These companies usually started with developing a generic product that can be used by multiple customers. However, each customer is unique with specific requirements, and to meet these requirements the product is made highly configurable, and customized (here and there hard-coded) to meet needs of a specific customer. Enabling this flexibility in the product has been a popular and successful approach to become an established and independent software vendor.

As a matter of fact, most of the software companies we work with have been really good at this, and point out that this approach enabled them to grow and become a substantial player in their business. And not just that – the flexibility in the product supports different scenarios of usage, generating new business in adjacent market segments.

Customization trap in software product innovation

Unfortunately, there is a drawback to this approach. Serving different customer needs is a proven approach to good business. However, meeting these needs through a highly configurable and customized product has led to enormous complexity within the product, strangling and choking further innovation. Too many tables, too many parameters (I am talking thousands here), too little layering and modularization, and hardly any automated test coverage. Over a period of time, the behavior of these customized versions becomes unpredictable, difficult to track, and support. The products are also difficult to integrate with, and have long implementation cycles. Very few people know all the intricacies of the system, making them bottlenecks in support, change management and customer implementations.

I call this the “know everything to change something ” trap. Due to the complexity and spaghetti-like dependencies of the system it is difficult to oversee the impact of change. One has to know the whole system inside out, to change something without the system blowing up in your face. As stated before, the companies we work with understand this situation well. And that’s a good start.

Paradigms of the past cannot create solutions of the future

I see a lot of companies trying to overcome legacy challenges by developing new software products from scratch, and making them flexible and adaptable. There is a good rationale behind this approach: if we enable flexibility from deep within and rebuild our core functionality on top of that flexible layer, then we will be in a much better shape to meet customer-specific demand.

But in spite of this sound rationale, these companies are committing a fundamental mistake. Apart from the cost aspect to rebuild the entire software stack, and the challenges of migrating the existing customer base, at its core very little has changed in terms of approach to software product innovation – how the product is conceptualized, designed, and developed. Very often, similar architectural paradigms (to those that were used to build the original product) are applied to build the new product also, perhaps with newer technologies. As a result, even though the product appears new and may solve some of the legacy issues initially, it is bound to end up sooner than later with a similar complexity and lack of cohesiveness as the original product.

By designing products to be extremely configurable, in reality, software companies are forcing their customers to build everything on their product platform. In one way, what they are attempting to do is become low-code platforms within their specific domains or functions. This is not the essence of openness, that a collaborative ecosystem demands.

My advice would be: stop doing that. There are so many commercial and open source (I prefer the latter, see my previous blog) low-code platforms out there. It is an entirely wrong assumption to think that having your own low-code platform will differentiate you from your competitors.

Autonomous, self-adaptive systems of the future demand a paradigm shift

The real solution direction is to abandon those antiquated technologies and architectural patterns of software product innovation. Autonomous and self-adaptive systems of the future demand a fundamental shift by adopting modern architectural, organizational, and deployment paradigms that will help develop and sustain open, loosely-coupled, connected, and participative software products that live in their customer ecosystems. To understand this shift and what it entails, the following topics must be on your radar:

• User centricity

• Data-driven design

• Platform thinking

• SaaS

• Designed for change: event sourcing

• Organizational design patterns need to follow architectural design patterns

It is easy to list these topics, but all the more difficult to make the switch, and understand the implications for your specific situation.

That is why I have asked our CTO Thijs Petter to publish a series of blogs, and host a set of webinars on these topics, and how they fit into building state-of-the-art, software products. Thijs has spent a lifetime in building software development platforms, before making a career shift and help businesses use this knowledge to overcome the know-how do-how gap.

Stay tuned as we will shortly come out with the first blog in Software Product Innovation series.