Category: Blogs

Few technologies create a level of hype, excitement and fear these days as artificial intelligence (AI). The uninitiated believe that general AI is around the corner and worry that Skynet will take over soon. Even among those that understand the technology, there’s amazement and excitement about the things we’re able to do now and lots of prediction about what might happen next.

The reality is, of course, much less pretty as the beliefs we all walk around with. Not because the technology doesn’t work, as it does in several or even many cases, but because rolling out a machine learning (ML) or deep learning (DL) model in production-quality, industry-strength deployments remains a significant engineering challenge. Companies such as Peltarion help address some of these and do a great job at it.

Taking an end-to-end perspective, in our research we’ve developed an agenda that aims to provide a comprehensive overview of the topics that need to be addressed when transitioning from the experimentation and prototyping stage to deployment. This agenda is based on more than 15 case studies we’ve been involved with and over 40 problems and challenges we’ve identified.

The AI Engineering research agenda developed in Software Center

The research agenda follows the typical four-stage data science process of getting the data, creating and evolving the model, training and evaluating and then deployment. For generic AI engineering, we identify, for each of the stages, the primary research challenge related to architecture, development and process. These challenges are mostly concerned with properly managing data, federated solutions, ensuring the various quality attributes, integrating ML/DL models in the rest of the system, monitoring during operations and infrastructure.

In addition to the generic AI engineering challenges, we recognize that different domains have their own unique challenges. We identify the key challenges for cyber-physical, safety-critical and autonomously improving systems. For cyber-physical systems, as one would expect, they’re concerned with managing many instances of a system deployed out in the field at customers. For safety-critical systems, explainability, reproducibility and validation are key concerns. Finally, autonomously improving systems require the ability to monitor and observe their own behavior, generate alternative solutions for experimentation and balance exploration versus exploitation.

Concluding, building and deploying production-quality, industry-strength ML/DL systems require AI engineering as a discipline. I’ve outlined what we, in our research group, believe are the key research challenges that need to be addressed to allow more companies to transition from experimentation and prototyping to real-world deployment. This post is just a high-level summary of the work we’re engaged in in Software Center, but you can watch and read or contact me if you want to learn more.

Recently, I got an e-mail asking me why we should care about Agile if the overall product development process, including mechanics and electronics, is measured in years and is completely waterfall. The question took me by surprise. I’ve been working with Agile practices for the better part of two decades now and for me it’s a given that fast feedback loops are better than slow ones.

However, after more careful reflection, I realized that the question is based on a few assumptions that, in turn, are founded on our beliefs around our ability to predict. The first assumption is concerned with our ability to optimally predict requirements for our products months, quarters or years down the line. In many industries where products contain mechanical and electronic components, the production pipeline requires long lead times. Consequently, the product requirements are formulated long before the start of production. The fallacy is, of course, that requirements change all the time due to new technologies becoming available, changing customer preferences, actions taken by competitors and so on. One rule of thumb in software says that requirements change with 1 percent per month – a very conservative estimate if you ask me.

So, how to respond to constantly changing requirements? There are fundamentally two approaches. Either you adopt agility and continuously respond to changes or you resist requirement changes, reject all that you can and grudgingly accept those that you really can’t ignore. The result of the latter approach is, of course, an inferior product as it’s based on the best insights from years ago.

The second assumption is that we can predict the effect of our requirements. These are defined as we hope to achieve a specific outcome as a consequence of realizing the requirement. We see this most often with usability requirements, but it basically extends to any quality attribute of the system. Online companies use A/B testing of solutions to determine the effects of different realizations of functions and features on users. These companies don’t do that because they’re so poor at requirements engineering, but because the effect of features and functions is fundamentally unknown when it comes to the way humans respond to software functions.

Traditional engineering companies pride themselves on their ability to predict the capabilities of systems before they build them as engineering offers a set of mathematical tools for modeling, simulating and predicting. These models are typically then confirmed by lab tests and in some cases small-scale tests in real-world contexts before fully committing to a specific design. Although this works quite well in many circumstances, it remains the case that measuring in real-world deployments provides much higher validity than mathematical models and lab tests. As I’ve shared in earlier posts, research by us and others shows that at least half of all the functions in a typical system are never used or used so seldomly that the R&D investment is a waste. So, wherever we can use techniques to deploy slices of functionality or features and measure the effect before building more, we should as it allows for a major improvement in the effectiveness of our R&D.

Although many understand that real-world experimentation concerning usability and user behavior is a necessity, the same is true for all quality attributes. Think of all the security fixes that we need to roll out. Often these concern vulnerabilities to threats that were known before the design of the system was finished. It just turned out that the mitigation strategies that engineers designed into the system didn’t suffice. Similarly, do we know for a fact that the current system design gives us the highest performance, the best robustness, the highest energy efficiency? Of course not! Rather than relying on models and lab tests, we need real-world experiments with our products at customers in the field to continuously improve. The models and lab tests are still needed, but mostly to protect us from the downside of less successful experiments before deployment.

Concluding, if you’re able to perfectly predict the optimal set of requirements for a system or product years ahead of the start of production or deployment and if you’re able to accurately predict the effect of each requirement on the user, the customer and the quality attributes of the system, then you don’t need Agile. In all other cases, Agile (both pre-deployment and post-deployment – DevOps) offers the opportunity for a massive improvement in the effectiveness of your R&D (as measured in value created for each unit of R&D). It’s not that we can’t build products using traditional waterfall processes – of course we can as we’ve done so for decades. The challenge is that we’re much less efficient doing so, which increases the risk of disruption for our company.

For all the human suffering and economic impact caused by corona, there’s one thing that has just surprised me over and over again these last weeks: companies and professionals just adjust and adjust quickly. Teams and departments that were stuck in old ways of working suddenly have found that it’s entirely possible to work in a remote setup.

During this week’s Software Center steering committee meeting, all the companies present shared how they kept the business going despite everything. Those developing software, meeting customers or doing administrative work were working from home, but things were progressing. Those that required access to complex machinery or worked in manufacturing were still at the company but had taken measures to protect against infection to the best extent possible.

All these new work setups required everyone to spend time adjusting, required some more infrastructure in some cases and gave IT departments a busy time. But after the first week or so, most people got into the groove and things seem to be moving forward at largely the same rate of progress.

Now, I’m not at all implying that the current situation is ideal. Some companies have shut down or are working at 40-60 percent of capacity. Many experience loneliness due to the lack of human contact. And for all the video conferencing in the world, nothing beats standing together in front of a whiteboard during a brainstorm session. My point is that we’re able to push forward, to conduct R&D, to drive sales and to keep things going to a much larger extent than what I’d initially feared.

And, of course, there’s the notion of digitalization. Changes in working behavior, interactions with customers, activities that were viewed as simply requiring physical presence have now digitalized at a phenomenal pace. Necessity is the mother of invention and it’s clear that things that were considered impossible or at least sub-par are suddenly entirely possible and will soon be the norm.

As a leader, you now have a choice to make. Either you change as little as possible with the intent of changing back to the old ways of doing things as soon as possible. Or you use this opportunity to drive as much change as possible and use this as a springboard for accelerating all kinds of changes in your organization, ranging from the business models, interactions with customers and the way sales is conducted to the way you conduct R&D, what and how you automate processes and where you use humans. As the saying goes: Never waste a good crisis!

With the vast majority of white-collar staff in companies currently working from home, the normal ways of managing people are disrupted quite fundamentally. Working closely with people in such a way that you can tell them what to do is much more difficult when you’re not physically in the same place.

Similarly, many organizations rely on meetings to align and coordinate work that crosses team and function boundaries. Because virtually all meetings take place online, their effectiveness is even lower than usual. I’ve already talked to people who are literally stuck behind their computers for back-to-back online meetings for ten hours in a row.

Rather than complaining about the situation and the inefficiency of working in this way, I’d like to outline an alternative approach: move to cross-functional teams that get tangible, quantitative outcomes as their target and that are otherwise left to their own devices on how to accomplish these outcomes.

Although it’s obvious that in almost all contexts, this is a better approach, few, especially traditional, companies are adopting it. The reasons are many, but some of the primary ones include: a lack of clear quantitative goals for most individuals and teams – in [last week’s post](https://bits-chips.nl/artikel/why-you-dont-define-desired-outcome/), I wrote about the reasons for this; a need for control by management, as in my experience, especially in more traditional companies, the culture tends to lean towards hierarchy; the Taylorian mindset of dividing every end-to-end task into multiple slices and giving each slice to a department, function or team and assuming a waterfall-style handover process; the belief that most work is repetitive and can be optimized by asking individuals and teams to specialize on their narrow slice of the work.

These reasons may have been justifiable at some point in the past, but this is most certainly no longer the case. All work that’s repetitive these days is automated and if it isn’t, you better automate it soon. This means that the only work left for humans is the work that we’re best at: complex, unique tasks that require creativity and a variety of skills to resolve.

Cross-functional teams are uniquely suited for taking on this type of work. By establishing the team around the skills expected to be required for the task, people with different skills can together work on addressing the challenge. As coordination cost within teams is orders of magnitude lower than coordination across teams, functions and departments, the efficiency of work is much higher.

The second aspect of the approach is that rather than telling teams what to do and how to work, they receive tangible outcome targets. It’s then up to them to figure out how to achieve these targets. This may require experimentation with customers and products, prototyping, and so on.

As we describe in our work on value modeling, the outcome targets should be part of a hierarchical value model that links the top-level KPIs for the business with the mid-level and team-level targets. So, all teams have targets on which to focus but also guardrail metrics that they’re not allowed to affect negatively.

With most of the people in industry working from home, perhaps the time has come to reinvent your organization along these principles and instead of suffering through the disruption, you can use it to lift your organization to the next level. Focus on setting outcome targets, not on telling people how to get there.

During multiple meetings this week (online, obviously), the same challenge came up: companies and their customers are extremely poor at precisely defining what the desired outcome is that they’re looking to accomplish. At first blush, every person that I meet claims to know exactly what he or she is looking to achieve, but when push comes to shove and the individual is asked to define this more precisely, the lack of specificity rapidly starts to become apparent.

This is, of course, far from the first time that I’m exposed to this and the interesting thing is that there’s a variety of words that companies will use to cover up the lack of specificity. Words like customer value, quality, speed, reliable and robust are often used as generic terms used to look good but that prove to be void of any real meaning when investigated in more depth.

The challenge is that not being clear on your desired outcome causes all kinds of problems for organizations. One is that prioritization in the company tends to be driven by the loudest customer. Customers tend to create a lot of noise about something that they happen to care about at the moment, especially if it’s not working well. The consequence is that they contact the company with messages of deteriorating quality. If you haven’t defined what you mean with quality and you don’t have metrics to follow up what the current level is, it’s very easy to simply go along with the customer opinion and allocate significant resources to addressing this potential quality problem. The opportunity cost of this is enormous as the proclaimed problem might be a minor thing and it might well be that using the resources elsewhere would have been much better for the company.

A lack of precise definition of desired outcomes creates several issues inside the organization as well. First, it may easily lead to teams whose efforts are mutually conflicting due to different interpretations of what success looks like. For instance, teams looking to improve customer value by developing a simpler, more intuitive user interface will run into conflict with those that seek to improve customer value by developing additional features or more configuration and variants of existing features. The latter will need UI real estate to expose the user to the additional functionality and options that will easily undo the efforts of the first.

Another aspect, which I’ve written about before, is the inefficiency of development that’s not grounded in precisely, or rather quantitatively, defined customer value. For a company allocating 5 percent of its revenue to R&D and an average FTE cost of 120 k€/year, an agile team of 8 people working in 3-week sprints costs around 60 k€ per sprint but has to generate 1.2 M€ (60 k€/0.05) in business value per sprint. Vague statements about quality, speed, reliability and value do not help organizations to accomplish this outcome.

Concluding, many organizations fall short in precisely defining the desired outcome for initiatives, projects, products, and so on. Resources are allocated because of loud customers, historical patterns, ingrained behaviors or internal politics, not because these resources are providing the highest RoI for the company. In our research, we work with companies on value modeling to overcome these challenges and help them get on the way of precisely and quantitatively defining desired outcomes. Contact me if you want to know more.

All of Europe, as well as the rest of the world, is in the throes of the coronavirus and some people I meet are comparing it to the start of one of those apocalyptic movies where the world is going to hell in a handbasket. Of course, nobody can ignore the human suffering that comes from getting sick and potentially even dying from COVID-19. It is terrible and my heart goes out to those that are affected.

The current actions, including avoiding large gatherings, quarantining geographical areas, closing schools and recommendations concerning washing your hands, limiting travel and so on all make sense. However, these actions will only slow the rate of infection in order to decrease the overloading of the healthcare systems (even more) by spreading the cases out over time.

For the companies I work with, the impact has been unprecedented. All travel that’s not absolutely business critical has been suspended. Visitors (and researchers) are no longer welcome. Employees are asked to work from home wherever possible.

The dark COVID-19 clouds can have a silver lining for companies. The disruption of normal work practices offers a great opportunity to review and evaluate all processes and activities in the company and between the company and its ecosystem partners. This allows us to determine which processes that earlier required physical interaction can also be accomplished by virtual means. Similarly, we can review all activities and processes that were performed by humans by virtual means but that can be automated and be achieved without any human involvement. Finally, we may even identify activities that are obsolete and that were only conducted for historical reasons and we can shut those down.

The second benefit that companies can seek to exploit is a step function change in the adoption of digital practices. In many cases, we either figure out how to do things remotely and virtually using digital means or it doesn’t get done at all. This includes holding meetings, managing daily standups for agile teams and running the operations of systems. In fact, I could easily see the efficiency of companies significantly improve due to the forcing function provided by the current situation.

Third, many organizations are built on the principle of aligning all the gears in the machinery as closely as possible in order to optimize operational efficiency. The consequence tends to be very brittle systems that are unable to withstand adverse circumstances. Situations as we’re experiencing now force us to rethink things in terms of risk management and should encourage you and your organization to think in Taleb’s antifragility principle where systems get stronger in the face of detrimental developments.

Fourth, although the short-term economic damage is significant, the removal of business travel and working from home does provide some breathing room in the lives of many professionals. This space can be used to think strategic rather than tactical, to reflect and introspect and to find smarter ways to accomplish the same if not better outcomes.

Concluding, COVID-19 is terrible from a humanitarian, as well as from an economic perspective. Although the short-term impact on revenue and margins is undeniably bad for most companies, we can use these circumstances to realize at least some benefits that may help our companies going forward. This is important as this is not the end. In the same way as the Spanish flu in the early 1900s, SARS in 2002 and swine flu in 2009 weren’t the end. As the poet Rumi wrote centuries ago, this too shall pass.

One of the well-known struggles of every company I work with is to combine innovation with efficiency-oriented operations. This is the classic problem of ambidexterity: the company needs to deliver on today’s revenue and margins while securing its future. The problem is not that companies aren’t aware of the challenge but that they lack the tools or mechanisms to achieve the balance in a good way. This is in some ways surprising as many reams of paper have been written about the challenge, ranging from books to research papers and from blog posts to company presentations.

The key challenge is that the two systems of operation are fundamentally different. In operations, we use the classical assembly-line way of thinking by chopping up the work in chunks, giving it to different people and functions and having handovers between them. The focus is on how each step in the process can be executed at the lowest cost. On the sales side, the focus is on tactics to make customers that have a known and established need for the product to choose us over competitors and to buy now rather than later. This leads to waterfall processes, hierarchical organizations, transactional business models and a relentless focus on efficiency. Resource allocation is based on operational needs and investments sustaining innovation typically have a predictable RoI that follows a Gaussian probability curve.

Innovation, on the other hand, is concerned with finding new opportunities. This means experimenting with new concepts to existing customers and, potentially, selling existing concepts to new customers. As we look to test as many concepts as possible against the lowest cost per experiment and, at the same time, the concept has to cover all relevant aspects including technology, engineering, business model and support, the nature of innovation requires empowered cross-functional teams that engage in continuous relationships with potential customers. The RoI of this type of innovation tends to follow a power function, meaning that the RoI of the most successful innovation is higher than the return of all other innovation initiatives combined. By its very nature, innovation is a high-risk, high-return game.

Many companies go wrong in clearly separating the two operating systems, resulting in a host of issues around innovation. As the majority of resources are on the operations side of the business, innovation efforts tend to be evaluated based on criteria driven by an operations mindset. This tends to lead to two extremes. The first is where any innovative idea is killed before it has had any chance to prove itself. As innovation is, by definition, breaking the existing rules of the game, it’s obvious that the opinions inside the company will seek to kill the idea unless it’s protected. At the other end of the spectrum, there are situations where an innovative concept needs to be fully developed and ready for production before we’re even willing to show it to a customer. This leads to the [minimal viable elephant](https://bits-chips.nl/artikel/are-you-building-a-minimal-viable-elephant/) I wrote about earlier.

Combining innovation and operation is hard. In my experience, there are at least two tools that are useful in this context, ie the three horizons model and unstructured time. The three horizons model (attributed to McKinsey) divides the business of the company into three categories. Horizon 1 are the mature cash cow products that generate the majority of the revenue. The model says that this horizon should receive 70 percent of all resources in the company but also that individual products in this category should receive a resource allocation that’s 5-10 percent below the growth rate. That means that if the product grows at 5 percent per year, it may still mean that the available resources are flat or shrink every year.

Horizon 2 is concerned with the proven, rapidly growing products that aspire to become future H1 products. This part of the business should receive 20 percent of the resources and resource allocation to individual products can and likely should grow faster than revenue growth in order to accelerate things.

Horizon 3 is concerned with new innovation concepts that are unproven. This part of the business should receive 10 percent of the resources and these resources are allocated to running experiments with customers with the intent of finding viable options. In [earlier columns](https://janbosch.com/blog/index.php/2017/02/05/innovation-is-hard-work/), I’ve described how, in my experience, this should be organized.

The important part is to realize that any organization needs to allocate at least 10 percent of the total resources to innovation. One way to allocate those resources is by offering employees unstructured time for innovation. So, everyone who wants to can use 10 percent of their time for innovation efforts without any approval required from any manager. These hours can be used to build teams of people that all use their 10 percent to explore a particular innovation. In [this article](https://janbosch.com/blog/index.php/2017/10/13/the-end-of-innovation-as-we-know-it/), I provide more details.

Concluding, combining innovation and operation is difficult but also essential to ensure the longevity of the company. We need to survive today and ensure a viable future. Although everyone understands this conceptually, my experience is that in most companies, these two systems of operation are conflicting, with the investment in innovation often being the victim. So, think about this: for all the talk about innovation, does your organization really conduct innovation, protect it and grow new businesses out of its innovation efforts? Or is it just ‘feel good’ talk?

As part of the research in Software Center, I work with dozens of companies in the software-intensive embedded systems space on a variety of topics. One of these topics is the development of new products. Having worked with online companies, as well as startups, I’ve become indoctrinated with Steve Blank’s ideas and the “lean startup” concepts. One of the key tenets is that you validate with customers every step of the way. In fact, you seek to minimize the amount of R&D investment between customer proof points. The second tenet is to only rely on what customers say when you absolutely need to, but whenever possible rely on measuring their behavior.

In the embedded systems industry, for some reason, companies are extremely reticent to validate with customers before the entire product has been built. Over the years, I’ve heard a great variety of reasons as to why this is. The main ones include: “We can’t show customers anything but a complete product”, “We’ll damage the company brand if we show an early prototype”, “This idea is so good that they’ll buy it if we only build it”, “Experimentation with customers makes us look like idiots because it looks like we don’t know”, “This stuff is secret and we don’t want to tip off the competition”, “It’s so hard to organize this across the company as I need to coordinate with everyone.”

The consequence of this is that companies tend to build, as one of my colleagues quipped, minimal viable elephants (MVEs) instead of minimal viable products (MVPs). When I confront people with this and we get past the ‘excuses’, it seems to me that there are at least three fundamental causes to this phenomenon.

First, most of the companies established themselves and became successful by building mechanical and electronic products. Because of a variety of reasons, not the least the need to establish manufacturing facilities, the design processes for atom-based products have traditionally been very waterfall and specification based. With the advent of additive manufacturing and rapid prototyping hardware facilities, this is, of course, changing, but the traditional approaches are still widespread. It’s important to realize that building innovative digital offerings requires a fundamentally different process than building physical products. In fact, using the traditional process is a recipe for disaster as you’re flying blind and base your decisions on the beliefs of you and the others at your company – beliefs that are almost certainly wrong.

Second, especially in new product development, complicated internal political processes and games tend to be part of the equation. As a consequence, the attention shifts from the customer and the business ecosystem to the internal political landscape. The folks involved in the development of the new product often have to compromise with various forces in the company. This causes functionality to be added or changed independently of actual customer feedback but based on the opinions of HIPPOs. In the worst case, this results in new products that, for all practical means, are a Swiss army knife that can do many small things but doesn’t solve the one key problem that initiated the product development in the first place.

Third, many think of new product development as a one-shot opportunity that we have to get right on the first try. This, of course, is driven by the difficulty of changing mechanical and electronic products after the start of manufacturing. However, digital offerings are akin to a conversation: constant updates are cheap, allow you to measure how customers respond and, in fact, are expected by many customers.

Building digital offerings that include mechanical and electronic components as well requires a different view on the priorities and process. First, establish problem/solution fit by simply spending ample time with intended customers, well before any R&D effort. Second, establish product/market fit by presenting the intended solution concept to customers and validate the fit, as well as their willingness to pay. Third, build the scrappiest, fastest, smallest realization of the product that allows for small-scale validation. Here you transition from measuring what customers say to what they actually do. Fourth, build a slightly more advanced prototype of the product that can be validated on a larger scale.

Of course, each of these steps is conducted iteratively and you only proceed to the next step when the feedback that you received from customers justifies it. In practice, it often means that the mechanical and electronic parts of the product are over-dimensioned in terms of specifications in order to allow for a larger ‘design space’ of opportunities for the digital part.

Concluding, innovating digital offerings is hard for embedded systems companies and the result often is a ‘minimal viable elephant’ that sees no customer feedback until after the start of manufacturing. Instead, focus extensively on collecting customer feedback throughout the entire innovation process and on customer behavior wherever possible. In the end, it’s the customer who decides whether you’ll be successful.

This week, for the umpteenth time, I met a team in the process of putting a new product in the market, telling me that they were so customer centric. What they meant was that during development, they’d talked to a number of potential customers and some of the employees had used prototypes. For those that read my articles on a regular basis, it will come as no surprise that I disagree with this view. There are at least three aspects that I think are critical to be truly customer centric: choose your customer, measure before you build and focus on behavior, not words.

First, there’s a fundamental difference between making customers happy and making happy customers. Many product teams with which I’ve interacted have vague and conflicting notions of who their target customer is. That makes it very likely that within the team, efforts are focused on different aspects of the product and that feedback from any individual viewed as a potential customer is immediately incorporated as the absolute truth.

To be customer centric, the first step has to be to define who you want your customer to be. Products that try to be everything to everyone will fail. The challenge of defining the customer is that you need to say no to categories of customers and it feels like you’re limiting the market of your product. In addition, team members often have different opinions and engaging in constructive conflict is extremely difficult in many corporate cultures. However, if you don’t know for whom you’re building the product, you can’t be successful.

Second, investment decisions in R&D are almost always based on opinions and qualitative feedback from a very small customer sample that almost certainly isn’t representative of the actual customer base. The mechanism to avoid this is to measure customer response – “signal” – before you even invest a single dime into building anything. Of course, the lean startup movement and Steve Blank’s books have been advocating this for decades, but in industry, this is still far from adopted.

The general feedback that I receive in response to the suggestion to test product concepts and potential features with customers is threefold. First, we don’t want to expose our customers to bad, immature, unfinished products as it will hurt our brand and our customers’ perception of us as a company. Second, what we’re doing is unique and we need to keep it a secret as long as possible so that our competitors don’t get wind of our plans. Third, marketing likes to surprise the market with a bombarding of messaging and if we go out early for testing purposes, everyone knows what’s coming and marketing can’t do its job.

All of these reasons are orders of magnitude less relevant than putting a product in the market that nobody wants and, with that, wasting all your R&D resources. Every investment in R&D, whether it’s new features in existing products or entirely new products, needs to be driven by a clear signal from the market.

Third, product teams put way too much stock into what customers say. Both in B2C and B2B contexts, most new products introduced to the market fail. In the fast moving customer goods (FMCG) space, the failure rate is, according to some studies, above 85 percent. This is despite the fact that every one of these products had extremely positive feedback from potential customers. Decisions in product teams should, to the largest extent possible, be based on measuring what customers do, rather than on what they say. For all kinds of reasons, customers will be much more positive in their verbal responses than in their actual behavior.

Developing new products is hard as you’re dealing with lots of uncertainty, internal stress and negative feedback from the rest of the organization. This can easily lead to the product team ending up in an X-Files style “I want to believe” situation where any feedback not supporting the current direction is filtered out. To be successful, however, you need to maintain the positive drive in the team while being crystal clear on who your customer is, be data driven in your decision-making and focus on customer behavior. Be customer centric, but do it for real!

During the last months, I’ve met with several companies that had an interesting common denominator: they were all building a new platform to replace a legacy platform and things weren’t going so well. The legacy platform often is decades old and has functionality in it that’s the result of hundreds of person-years of effort. And it typically forms the basis for a significant part, if not the entire, product portfolio.

When the new platform effort is initiated, the organization accepts that it will take some time (years) to build it to a point that it can replace the legacy platform. As stalling the product portfolio is unacceptable, there will be a continuous flow of development effort into the old platform to realize the features that are needed right now. This, of course, happens in parallel to the new platform effort. The consequence is that the goal for the new platform becomes a moving target as the legacy platform is continuously adding new functionality that the new platform will need to add as well in order to achieve feature parity.

There are three possible outcomes in this scenario. The first is also the worst: the new platform effort forever fails to achieve feature parity. As a consequence, no product line is willing to move over to it. At some point, there’s a change of management, the new platform effort is reviewed and the track record to date leads to an obvious conclusion: the new platform is canceled. The result is that the company is stuck with the old platform and has lost years of time and hundreds of person-years of R&D effort without any business benefit.

Second, the platform effort starts to be used by one product line and becomes the de-facto platform for only a part of the portfolio. For product management, the choice between building functionality for a product that’s here now or a potential product in the future very often falls in favor of the existing product. When this happens continuously, it results in the platform becoming increasingly optimized for the specific product line and getting further and further behind for the other product lines. This could be viewed as a way for one product line to hijack general R&D resources for its own purposes, which makes it very attractive as a strategy in companies with a strong focus on teams delivering in their own area of responsibility without maintaining responsibility for the success of the company overall.

The third situation is where senior R&D and business leaders understand these patterns and force the organization to abandon the legacy platform and adopt the new one. This often leads to significant tension as product lines are asked to put out new products with reduced feature sets. The discussion typically leads to many requests to perform “small” maintenance efforts on the old platform in response to customer requests and other, highly viable, reasons. In general, many in the R&D organization will fight for staying on the old platform as long as possible. In the worst case, the legacy platform will never be sunsetted and the platforms continue to exist next to each other for years or even decades.

The fundamental reason behind these scenarios is a mechanical mindset by leadership. The notion of having generations of platforms may make sense in mechanics and electronics (although these platforms would benefit from continuous evolution as well), but software is different. Our research shows that there’s no correlation between system age and the level of technical debt, meaning that new systems and old ones have similar amounts of requirements for technical debt management.

Rather than thinking in terms of platform generations, the focus should shift to a continuously improving platform with a constant flow of refactoring effort keeping it current from a technology and architectural perspective. Instead of allowing an existing platform to sink in the morass of commodity and irrelevance, organizations should look to continuously invest some percentage (10-25 percent) into the platform to ensure it never has to be replaced by a next generation.

Concluding, building new platforms to replace existing ones is a highly risky R&D initiative fraught with risks and challenges. Instead, commit to continuously investing a part of your R&D resources in refactoring your existing platform. The best platform is one that never has to be replaced because it’s always current and up to date. Because you committed to keeping it that way!