Month: February 2020

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!

Having worked with companies on the use of AI, I’ve noticed an interesting pattern: although most of the attention is spent on algorithms, data storage infrastructure, training and evaluation of applications, the hardest part very often seems to be coming up with a promising concept in the first place. When exploring promising concepts, many start to realize that taking the resultant ML model from the prototyping phase to real deployment is a major challenge that requires changes in existing customer engagement models, product architectures, ways of working, the data collected and often even legal constraints.

Exploring promising concepts, of course, requires exploring both the potential business benefits and the expected cost for introducing a machine or deep-learning model in a product, solutions or service. However, my observation is that many struggle quite a bit with coming up with potential concepts that exploit the benefits that ML/DL models provide.

Earlier, we introduced the HoliDev model, which distinguishes between requirements-driven, outcome-driven and AI-driven development and claims that each type of development has its own characteristics. AI-driven development thrives where, on the one hand, there’s sufficient data available for training and operations and, on the other hand, we’re looking to solve an inference problem that’s particularly hard to solve without the use of ML/DL techniques as there’s no clear algorithmic approach. In general, we focus on three main characteristics that provide the key preconditions for a successful AI concept, ie removing hardcoded responses, using ignored data and revisiting negative RoI use cases.

First, in situations where the system response is hardcoded, there can be a significant benefit to providing a response to each request based on the available information. The obvious example is in the online advertising space where companies like Google and Facebook are constantly looking to create more accurate profiles of users in order to serve more relevant ads, rather than showing people a random ad. AI models can, especially when a good algorithmic approach is lacking, provide better responses by training based on available data.

Second, there are numerous situations where available data simply is ignored as humans haven’t been able to detect patterns in it and consequently follow a mathematical approach to solve a particular problem. An interesting example can be found in control systems where several companies are working to complement or replace traditional P, PI, PD and PID controllers with AI models. The reason being that traditional controllers operate based on a theoretical model of how a system is supposed to behave in response to control signals. In practice, no real-world system responds completely in accordance with the theory and AI models can improve the quality of control by taking all data into account.

Third, the most difficult case is where the cost of collecting data for human interpretation has had a negative return on investment as the effort required to benefit from the data was too high. With the decreasing cost of sensors, computing resources and communication, however, more and more cases exist where collecting the data for use by an AI model is actually becoming profitable.

It’s in this category where the most rewarding AI business cases can be found. One well-known example is sentiment analysis in social media. The amount of data in social media vastly outweighs the ability of even large teams of people to keep track of the sentiment around, for instance, a product or a company and consequently people didn’t even try. With the emergence of ML approaches, however, it becomes entirely feasible to have real-time dashboards of the state of the sentiment and companies use these insights for decision-making.

Concluding, for all the focus on AI algorithms, data and training, one of the most challenging activities remains the identification of interesting business cases and evaluating the feasibility and desirability of each case. I’ve discussed three categories of cases that can provide inspiration for identifying your AI business case.

During the last weeks, I’ve experienced multiple situations where an organization (industrial or academic) simply doesn’t have a business strategy or a strategy concerning a key area for their business. When probed and questioned on the strategy, I’ve observed at least three types of responses.

First, leaders in the company say that there **is** a strategy and that I’m wrong in claiming otherwise. Although I’ve been wrong many times in my life, to me a strategy should provide clear guidance on what tasks and opportunities should be prioritized over others and, above all, what we shouldn’t spend time, energy and resources on. A strategy that fails to specify what we shouldn’t do, to paraphrase Michael Porter, is no strategy.

Second, the company admits that the strategy is high-level and not operational but defends itself by claiming that its key success in the market is to be customer focused and, consequently, it needs to respond to the requests from customers rather than set its own course. Obviously, this is a fallacy as it causes companies to fall into the “make customers happy” trap. It’s impossible to satisfy everyone. Rather, you need to choose what kind of customers you want and then focus on making them happy. This, of course, is a strategic choice.

Third, especially in new areas where the company has no established business, leaders claim that it’s impossible to formulate a strategy as nobody knows how the market will unfold. This, however, causes them to become the plaything of more proactive, strategic competitors who will dictate how the market will establish itself. It’s important to avoid an Alice in Wonderland situation where by not knowing what you want, any direction is equally good.

Although these responses are understandable and human, they lead to a number of serious problems for the company. There are at least three that I’ve witnessed over the years.

First, the company acts tactically and opportunistically. Due to the lack of a clear strategy, individuals at all levels in the organization take tactical decisions that provide them with the most benefit in the short term without considering the long-term consequences. This results in an accumulation of architectural, technical and process debt in the organization, as well as in the relationships with customers and other ecosystem participants, which over time causes enormous disadvantages due to reduced business agility, unreasonable expectations by others, as well as numerous other consequences.

Second, there’s a significant risk that different teams in the company pursue opposing local strategies and consequently nullify each other’s efforts, causing the company to expend, sometimes significant, resources without any business benefit. Burning resources without generating business benefits obviously is the fastest road to bankruptcy.

Third, even if none of the above effects occur at your organization, all employees will, at any point in time, still have way more work than they could possibly hope to accomplish during work hours. In the absence of a clear strategy, individuals randomly prioritize tasks based on personal preferences, expediency and other factors. So, the “strategy in use” will become whatever everyone feels like. In practice, this tends to lead to people doing what they did yesterday, meaning the company gets stuck in the past and fails to evolve and respond to changes in the market.

Concluding, developing and communicating a clear and actionable strategy that represents tangible choices is a critical tool in aligning large groups of people. The alternative is to micromanage everyone, which will cause you to lose your best people as nobody likes being told how to do their job. A successful strategy defines a clear what and why and leaves it to individuals and teams to figure out how.