Product Strategy Center

Resources for product strategy for supply chain management and retail operations software

Supply Chain and Retail Software Market Structure

The supply chain management and retail operations software markets are segmented into a number of sub-segments that are based on function and problem-specific domain. Software companies often struggle with defining and sizing the market so that they can understand opportunities and invest appropriately. This process should start with a common taxonomy for defining the market down to level of specific problem domains. Different analysts have different taxonomies and provide information at different levels of detail. The below chart provides a high level market decomposition (level 0 and level 1 decomposition) for the SCM and retail applications software markets and its downstream adjacency, the customer management (also called customer relationship management) market. 


The supply chain management applications software market has typically been segmented into supply chain planning, supply chain execution, and procurement. In the past, some have viewed the procurement software market as a separate market at the same level as the SCM market. However, procurement is typically under the purview of supply chain, and is therefore included as such in the diagram below.


Planning functions typically include network design, inventory optimization, demand and supply planning, S&OP, and factory planning and scheduling. Execution functions typically include transportation management, order fulfillment, and warehouse management. Procurement functions typically include all the functions associated with the procure-to-pay process. This includes contract management, sourcing, direct and indirect supply management and financial settlement. In recent years, a fourth category call "horizontals" has emerged, as visibility, collaboration, and control tower capabilities became a bigger part of the market. These functions are horizontals that span customer, retail, and the back-end supply chain. 

The retail applications software market is very diverse, but can be segmented, at a high level, down to retail planning and retail operations. Retail planning sub-areas include merchandise financial planning, assortment planning, category management, and space planning. Retail execution sub-areas include merchandise management, workforce and task management, point-of-sale, real-estate management, and perpetual inventory. Areas such as transportation and warehousing, which are heavily used by retailers, are included in the SCM market definition. From a high-level function mapping perspective, retailers and manufacturers execute similar processes. From a terminology perspective, it is important to distinguish between the retail industry and the retail applications software market. The retail industry consumes software from all the other areas here, but the retail applications software markets serve needs that are specific to the retail industry. 

Customer management includes large markets such as sales force automation, call centers, customer service, eCommerce, and order management. Many of these integrate closely with upstream supply chain functions such as transportation and warehousing. Even customer management areas such as sales force automation have to be integrated into supply chain functions so that salesperson forecasts can be directly incorporated into demand planning functions. 

To receive a complete market decomposition and taxonomy, contact Worldlocity

Market Sizing for the SCM and Retail Operations Software Markets

In 2018, the SCM software market will be about a $13-15 billion business, growing at annual rate of about 7-8%. This number is consistent with the number public software companies use in their investor presentations. This represents the amount of revenue flowing to software companies and their implementation partners and includes software licenses, subscriptions, and maintenance. First-party consulting (that done by the software companies themselves) and third-party consulting (that done by partners) would push the overall market to greater than $20B per year. This does not include revenue associated with the adjacent spaces of retail applications, and customer management, which are shown in the diagram above. The total revenue associated with those spaces is greater than the total for the SCM space. 

What do we do with this information? The only thing that is useful about this information is that the SCM software market is large and growing, and thus attractive for investors. But the devil is in the details and at the detail level, there are a lot of devils.  The market is highly fragmented, due to the domain-specific nature of the problems being solved, and because solutions are generally not technically capable of handling multiple problem domains, nor capable of both scaling up and scaling down to handle a wide range of company sizes (they can generally do one or the other). 

Worldlocity is in the process of assembling a composite view of the market and its opportunities. To request a copy of this analysis contact us


R&D Investment Levels for SCM and Retail Operations Software Companies

Software in general, and enterprise software in particular, are R&D-intensive businesses. R&D is the lifeblood of any technology company, particularly software companies. Software company gross margins are typically very high because cost-of goods-sold is usually limited to the labor necessary to deliver the software either on-premise or in the cloud.  Even though enterprise software is R&D intensive, it is important to note that much of what is included in the R&D expense line for a software company is not true R&D in the sense that resources are "researching and developing" new stuff. For established software companies, a high percentage of what constitutes R&D includes taking care of customers, fixing bugs, technology stack upgrades, and feature improvements for previously-developed software already in use at customer sites, in some cases for many years. These updates are packaged into new releases that are then consumed by customers as part of upgrades. 

Having said that, a software company's level of R&D investment is an indication of its commitment to the health of its current products and its long-term competitive viability. The level of investment is an important part of any strategic discussion. In order to do company-to-company comparisons, the level of investment is typically looked at in terms of R&D investment as a percentage of revenue. The level of investment in comparison to others is an indicator of the priorities and motivations of a given company. 


Different companies choose different levels, based on where they are in their overall lifecycle, and a host of other factors, including short-term profitability. There will always be tension between short-term profitability and long-term investment. R&D investments (or lack thereof) may not be realized through revenue impact for two to three years or more. On one end of the spectrum, high growth companies sacrifice short-term profit and invest large amounts in R&D with the idea that they will be the leaders of tomorrow. On the other end of the spectrum, established companies place higher value on short-term profit and thus invest lower amounts in R&D. These companies are placing an educated gamble that they will be able to ward off the high-growth upstarts. Of course, most established companies will make the claim that they are employing a balanced approach, between profitability and growth. 

In any case, benchmark data on R&D as a percentage of revenue is useful to look at and understand. Worldlocity looked at 32 public software companies in the SCM and adjacent software market spaces, examined their most recent 10Ks (in most cases 2016) and analyzed their R&D spend levels as a percentage of revenue. The resulting chart is shown below. The average R&D investment as a percentage of revenue for these companies is 17.9%; the median is 16.4%. These numbers are surprisingly high. There are a few significant trends going on here:


  1. Newer companies are spending a lot of money to take on incumbents; these companies are flush with cash and growing rapidly. This is also true of the private startup companies not shown here. This is good news for the enterprise application software market.

  2. As a result of the trend in point 1, larger established players have had to up their game by investing more, thus helping move upward the average. 

  3. Companies on the lower end of the scale are typically established players with low-growth profiles. Because their growth is low, they have calibrated their R&D investment lower. This leads to chicken-and-egg questions about the relationship between growth and R&D investment.

We will explore more on this topic in future research. If you wish to receive updates, join our email list

To see R&D investment information for a wider group of software companies, jump below.


R&D Return on Investment

Measuring R&D return on investment is notoriously difficult, if not impossible. As David Hounshell wrote twenty years ago, based on work in the chemical industry, "If people tell you they have an accurate and infallible way to measure ROI in R&D at the firm level, the industry level, or the national level, take it with a grain of salt. It is likely that the claimant has an agenda that conflicts with the goal of truly assessing the costs and benefits of R&D. I say this because research—especially long-term research—is highly uncertain, and also because the benefits of research are highly complex, going well beyond the abilities of most models to comprehend them except in a crude probabilistic sense."

This, however, does not mean that executives, shareholders, and boards will stop asking for a quantifiable understanding of the return on R&D investment. For managers of R&D, there is a dearth of empirical data, or empirical studies that one can leverage, not just for the software industry, but for all industries. Furthermore, a search on Amazon will not yield much in the way of help from books. The book, "R&D Productivity," by Gerald Dundon of is one of the few that offers a data-driven framework. 

Having said all this, there are certain things that can and should be done.

  1. Everyone must understand the vision, strategy, and timeframe for the business. This includes a common understanding of the core businesses and product lines, and whether to optimize growth, or operating profit, or some combination of growth and operating profit. It is also important for everyone to understand the capital structure of the business and any constraints it places on investment. It makes no sense complaining about under investment in R&D if it is known that the capital structure of the company will not support it.

  2. Everyone must clearly understand the composition of R&D investment, and where specifically the investment is going. Much of what is characterized as R&D investment in the enterprise software business, particularly for established companies, is actually taking care of the water that flows through the pipes for past and current revenue. The amount left over for true innovation is usually a small percentage and this usually shocks people. At the same time, these established companies must compete with upstarts, where the true innovation percentage approaches 100% of the R&D budget.

  3. Everyone must understand the company's current competitive position, particularly the position of its products. This includes a robust understanding of the market and specific sub-markets of the SCM software market and how fast they are growing. If a product's revenue is growing faster than the market, its share is growing; if the opposite is true, its share is shrinking. Each of these scenarios was in part created by R&D investments made over the course of the previous three years. Competitive position analysis also includes an understanding of how much and where competitors are investing. If a competitor is investing twice as much in R&D in a particular area, then you must either belly up to the bar, or figure out how to be twice as smart as they are. 

  4. Everyone must understand the time lag between an investment (or lack thereof) and its return (both positive and negative). Enterprise software is a long-lag business; products that cross the chasm and become successful are likely to have more than twenty years of revenue-producing life. In fact, there are many enterprise software products in use today that were conceived more than twenty years ago. Investments in R&D today may not manifest themselves in the market for three years (either good or bad). Architectural decisions made today may not manifest themselves for five years (either good or bad). Creating linkages between market performance and specific prior-year investments (or lack thereof) is critical to understanding ROI even at a subjective level and also creating organizational accountability. 

  5. The organization must have in place a robust decision-making framework. This includes a common commitment to, as Jack Welch said, "face reality as it is, not as it was, or as you wish it to be." Sometimes facing reality is among the most difficult things for an organization to do; too much energy is spent defending past decisions and the resultant current positions. This only delays pain and makes the pain much larger when it arrives. Having everyone in decision-making roles knowing and agreeing on reality is often half the battle. 

  6. It is critical, particularly for companies with established revenue streams, to understand the "do nothing scenario." This is a mindset put forth in the Harvard Business Review classic "Innovation Killers," by Christensen, Kaufman, and Shih.  As the authors state "The first error is to assume that the base case of not investing in the innovation— the do-nothing scenario against which cash flows from the innovation are compared—is that the present health of the company will persist indefinitely into the future if the investment is not made." In fact, doing nothing or under-investing (which is a form of doing nothing), puts at risk the entire franchise of a product, even if it manifests itself only slowly over time. This makes R&D investment an asymmetrical bet - while lowering investment yields immediate short-term results in terms of operating profit, it puts at risk the entire franchise. Companies spend very little time discussing and understanding the do-nothing scenario, which is related to the "facing reality" discussion in point 5 above. The first job of managers with regard to R&D investment is to understand, as completely as possible, what it will take to "first, do no harm." This means what is the amount of investment necessary to continue existing revenue streams (unless there is an explicit strategy to exit those businesses, or to explicitly take money away to self-cannibalize products in order to invest in their successors). 

  7. It is critical that everyone understand and agree on the technological threats facing the organization. Technology has the ability to completely disrupt markets; the days of product management driving requirements and then handing them off to others to figure out the "how" are obsolete. Technology and product decisions are inextricably intertwined. Architectural and technological decisions have long-term and lasting impacts on the health of software companies. If you get them wrong, no amount of R&D investment can correct them. If you choose the equivalent of the betamax direction, it is unlikely you are ever again going to be a leader in whatever business you are in. Strategically bad decisions lead to strategically bad outcomes, particularly when it comes to technological shifts. Thirty-five years ago, IBM could have just as easily chosen the Motorola chip instead of the Intel chip, but once the choice was made winners and losers were decided. The sooner these shifts are recognized the better; too many times in the technology business, managers will rationalize and hang on (see the discussion in point 5 on facing reality). When you get data that no longer supports your assertions, you need to change your assertions. Today, many are choosing one blockchain technology over another. If blockchain eventually ends up being the foundation for new industries and business models, there will be winners and losers. Those that chose correctly will have a high return on their R&D; those that didn't will have a very negative return. But choosing correctly is a crapshoot at this point in the proceedings and luck is likely to figure prominently for the fate of any winners and losers. 

This is obviously a complex topic. Worldlocity will be spending a lot more time on this topic in the future. If you to receive updates, join our email list


How to Think About Product Roadmaps

Product roadmaps became a big part of the packaged software industry in the late 1990s and early 2000s. The idea was to give customers insight into where a product was headed with some varying level of detail over some time horizon. This differs from consumer industries where you don't really have much of an idea of what is going to be in the next iPhone until pretty close to when it's released; Apple has a good idea, but they don't disclose this information to their potential customers until very close to the product release date.

But packaged software is different because customers pay maintenance (or implied maintenance through a SaaS subscription) and these customers want insights into the future of the product so they can decide if they want to continue paying maintenance or start to seek alternatives. 

The first thing to understand about software product roadmaps is that they are plans and represent no commitment or promise, direct or implied, to deliver. A big part of this is due to revenue recognition rules that got introduced to the packaged software industry in the 1990s. In these rules, if a promise is made, then any revenue associated with that promise cannot be recognized until that promise is delivered. And, the rules are such that even if you've delivered 99.9% of the functionality and the promise only represents 0.1% of the functionality, 100% of the revenue cannot be recognized. You can take the money from the customer, but that money has to be placed on your balance sheet as a "project or deferred revenue" asset until the promise is delivered. Once the promise is delivered and the customer has signed off, the money can move from the balance sheet to the P&L statement as revenue. 

Thus, if any part of product roadmap is represented to a customer as a promise, then any revenue associated with that product from that customer cannot be recognized as revenue until that promise is delivered and signed off by the customer. Over the years, this has rightfully caused many enterprise software companies to be cautious when communicating product roadmaps. This is also why product roadmaps are front-ended with safe harbor language. 

This does not mean they cannot be useful. Here's how to think about them. SAP, Oracle, and others have over the years established a three-element roadmap structure that correlates somewhat to the classic McKinsey three horizons of growth model. The diagram below translates this to the typical roadmap structure in place at established software companies (note that the translation is not exact; it's simply an adaptation to roadmaps). Horizon one focuses on the here and now - typically the capabilities that will be delivered over the course of the next twelve months. A large part of this horizon is frozen, but there is some level of flexibility on the back-end of it. Horizon two is typically focused on the eighteen months after the first horizon. Horizon three usually contains broad themes associated with strategic shifts that may be occurring in the market and is intended to give customers the understanding that you are working on them. This horizon-based structure is similar conceptually with an old APICS master production scheduling construct - the idea of three horizon fences - frozen, slushy, and fluid. 


The problem in many established software company is that the horizon three activities never seem to get done. As time slides forward, each successive roadmap shows continued emphasis on incremental improvements. Many of the great ideas of three years ago do not seem to be showing up in horizon one of this year's roadmap. This leads to a self-reinforcing focus on existing customers, existing solutions, existing revenue streams, and existing architectures and functionalities and derivatives thereof. This is good for the short-term, but increases the risk associated with longer-term relevance. 

Thus, we see the recurring dynamic that many of the horizon three ideas are worked on and commercialized by newer startup companies. This is true because that is all they are focused on; once they achieve some level of commercial success, they are just as likely to fall into the same trap as the established companies they disrupted. The Jeff Bezos ethos that "every day is day one" is very difficult for software companies to achieve. Of course, customers and the market know this. Over the years they have become conditioned to view any horizon three roadmap items with a healthy degree of suspicion. But this is also where customers can help - they can drive to value realization the longer-term strategic items by collaborating with software providers. 

At most software companies, there is no lack of knowing what needs to be done; there is a big lack of knowing how to go about it given the structural dynamics of how companies operate and how the industry itself has evolved. This is a core principle of disruptive innovation theory developed by Clay Christensen and discussed in his book "The Innovator's Dilemma." This is also one of the reasons that in the past decade, established software companies have tried to create incubation centers away from the mainstream of core product management and development. In this case, incubation of some of the strategic themes referenced in the diagram below is done through experimentation and customer piloting through the incubation center, brought to a point where commercialization is feasible, and then brought to realization through the "normal" roadmap process. The jury is still out on how effective this approach has been for most software companies. 

How to Segment R&D Investment


The term "R&D" conjures up images of workers in white coats toiling away in laboratories trying to come up with the next great invention. In enterprise software, this is a small fraction of what happens in R&D. Understanding where R&D money goes and having some understanding of benchmarks are critical to making sound business decisions on how much money to invest and where the money flows. Figuring out how to segment R&D investment is a multi-dimensional problem, particularly for those companies going after multiple segments of the market with multiple products. 

As discussed elsewhere, much of what is included in software company R&D is really investment in keeping current revenue flowing through the pipes - bug fixes, technology stack upgrades, assisting support, and incremental improvements to existing functionality. All of this continuous improvement is important; in fact, it is vitally important to at least maintain the current competitive position of a product. But what if you are now threatened by an upstart that seemingly came out of nowhere and now offers a simpler solution that also has functional richness? Your rear flank is now exposed, and unless you have been paying attention (and money) to that rear flank for the past five years, you could soon be toast. 

R&D investment can be viewed in terms of two broad categories - customer care and innovation. Customer care consists of foundational things necessary to "keep the lights on." In enterprise software, companies pay maintenance (either outright or through their SaaS subscription); part of maintenance are contractual obligations, including bug fixes and associated service level agreements. R&D shoulders the portion of maintenance cost that requires intervention in the software or where the support organization is unable to solve a product problem. Also included in this bucket are technology stack refreshes, beta and premium support programs that R&D must support, and other customer commitments requiring software changes. While most software companies try to minimize such customer commitments, they can still consume a material amount of R&D investment. 

The innovation category can be segmented into two sub-categories: sustaining innovation and disruptive innovation. This follows Clay Christensen's innovator's dilemma framework. In this framework, sustaining innovation is focused on existing markets, existing products, and existing architectures. This is typically the continuous improvement curve associated with an existing product and includes improvements in feature richness, usability, integration, performance and scalability, and total cost-of-ownership.


The framework describes disruptive innovation as new products or capabilities that reach customers that cannot be reached with the expensive, feature-rich products currently on the market. This is almost axiomatic in the enterprise software business, because any new product that is released into an existing market will by definition be less feature-rich than those that have been competing in that space for the past ten or twenty years. It is simply impossible to create a new product that has, in its first release, the feature richness of products that have been around for ten or twenty years. Thus the new products will compete on different terms - easy to use, easy to implement, zero-cost upgrades, and simpler to maintain. This will likely initially appeal to smaller companies with less sophisticated needs.

For example, when introduced its product in 1999, it did not match the feature richness of Seibel Systems. What it did offer, however, was something easy to use and easy to understand, making it easily digestible by salespeople. Furthermore, it was not initially targeted at enterprises with sophisticated needs; as Marc Benioff points out in his book, its first customer was Blue Martini, a relatively small software company. The key for established companies is to initially not try to sell these new products to their existing customers, who are accustomed to, and need, feature richness. Christensen's research has shown that this has historically been very difficult for incumbent players, because of the application of their established-product ROI frameworks to these new products and because their business models have been set up to only service the same types of customers they already have, creating a self-reinforcing circle. 

This segmentation framework can be used to answer key questions:

  • How much money do I spend on servicing existing customers?

  • How much money do I spend on servicing user group enhancement requests?

  • Where do products stand in their lifecycle and how imminent is the disruptive threat?

  • How much should I spend on existing architectures and products and how much should I spend on next-generation architectures and products?

  • Where do I target new products? Should I go after new existing segments or new segments?

We will be exploring this more in future updates and reports. 

To receive updates on this and related topics, contact Worldlocity

General Software Company R&D Investment Levels

Software is an R&D-intensive business. It's surprising how little is generally understood about investment levels and how much anecdotal data is used to make decisions. When evaluating and valuing a software company, it's important to look deeply at R&D, its level of investment, and how the level of investment fits into the company business model and its long-term competitive position in the market. 

As a follow up to earlier research into the R&D investment levels of SCM software companies, Worldlocity decided to cast a wider net to look at publicly-held software companies across a diversity of industries to gain an understanding of general software company dynamics. This analysis was also done to see how SCM software company investments stack up against general software company investments. 

In this analysis, we looked at 113 publicly-held software companies for which R&D investment levels are published in their annual reports. What we found was quite surprising. The average investment as a percentage of revenue across these 113 companies was 19.8% for the most-recently reported full-year financial results; the median was 17.4%. The group of 113 was also divided into three sub-groups: large cap companies (market capitalization equal to or greater than $10B); medium cap companies (market capitalization equal to or greater than $2B and less than $10B); and small cap companies (market capitalization greater than $300M and less than $2B). Another surprise is that there was very little variance in investment levels across the subgroups - the large cap companies invested an average of 19.2% of revenues, the medium cap companies 19.2%, and the small cap companies 20.6%. 

The lowest quartile across the 113 companies had R&D investment levels below 13.9%; in other words, if you invested 13.9% of revenues or less in R&D, your company fell into the lowest 25% of companies across all 113 companies. These numbers will probably surprise many; in fact, they highlight the need for greater investment by SCM software companies. 

Below is a summary of the findings.

Download the summary report here.