Software Development At SAP: Product Strategy

To be successful, a product needs to have certain properties: A unique selling point, for example, or features matching the demand. It needs to be aimed at the right user group and provide a high gross margin. Furthermore, it needs to be futureproof, technologically feasible, and more. As a customer, keeping these properties in mind avoids buying a product that will be deprecated soon.

Software is created to be a financial success. A well-established product must create one million USD revenue per year for each developer headcount, minimum. Products falling short of that will be terminated eventually. We have all seen it happen: Software being promoted heavily in one year just to be “put into maintenance mode” a few years later. Often, we have a feeling if a product is successful in the market. Assuming we achieve that, we as customers can avoid the expenses of software licenses, training, hiring specialized staff and the costs of re-implementing the project later with a different tool.

Therefore, when I am asked about an architecture and the components to be used, I am evaluating the contenders against financial success criteria. When involved in building software, answering these questions upfront is even more important.

Unique selling point

Every product must have a unique selling point (USP). Without, it is just one of many possible options to choose from – a commodity software, so to speak – and can only cost very little. Literally asking the vendor, “What is the USP?” allows to check if the product strengths match your own requirements. Example: The USP of the SAP ERP system is its integration of the various modules, e.g. creating a sales order triggers many different things: internal manufacturing orders, material movements, purchase requisitions, profit center bookings, etc. Thanks to its unique integration capabilities, buying a single ERP module from SAP and integrating it with modules from other vendors will rob customers of the USP they are looking for.

Some products do not even have an USP. The likeliness that a multi-product software vendor will lose interest in such a product is high.

Going through the list of SAP offerings, most do have unique selling points; for some, however, the value of the USP can be questioned and there are also a few important offerings I would say have no USP and are sold to customers regardless.

Margin

The goal of any company is to make money. In a software company, the number of development resources is finite and therefore a product with a high margin will get more development resources at the expense of a less profitable solution. Obviously, customers cannot really see the margin, but if companies add a lot of features to a specific product over time, it is safe to say that there is ongoing investment in it. I encourage every manager to ask users how they feel that the product is treated by the vendor.

Other factors play a role as well, e.g. the initial ramp-up investment for a new product, or if it is a strategic product.

Calculating the margin within the company is unfortunately not as easy as it should be. Especially SAP has many attractive sales bundles with 10 products included, and for customers, the bundle is still cheaper than individually buying the two products they actually required. Internally, all ten products get their share of revenue assigned regardless of how much customers are actually using them.

The same trick, but on a different level, is to make a product bigger even though each customer needs just a small subset. This reduces the product margin and, per my argumentation, increases the danger of being terminated in the next years. As a result, I am very cautious when it comes to such products that are being hailed as a cure-all for anything and everything. Small tools with a lot of leverage and open and immediate return for customers, that is what I prefer.

Pay-per-use

A better suited sales model for software is pay-per-use, preferably based on volume. The advantage for customers is clear: They only pay for services they use. The more it is used, the more value the customer creates with it and the charged fees reflect that. At the same time, it allows correct revenue allocation and matches the new reality of microservices, lean development, etc. This transparency requires the development team to keep improving the product to retain customers.

Translated to an ERP system, a pay-per-use model could be based on the number of sales documents created per month instead of named users or a license fee plus annal fees in the form of support contracts. Kudos to every vendor going that route – they must be confident about their offerings.

Built-on

Another dangerous case is when a product is defined as the foundation of others. “Every SAP application has to use Hana as database”; “SAP Cloud Platform must be used for all cloud developments”; “Hana apps must be built on XS Advanced”; and so on.

While it does make sense to set standards, it is also an effective way to create revenue for the base product even if there are better alternatives. It is easy to find out if that is the case, though: What do your developers have to say about those underlying technologies? If they like it, good, if they don’t, tread carefully. I, for example, like Hana a lot, and with the Hana runtime license, it’s an attractive foundation to build on.

A concrete example of something gone south fast: The Hana big data story of 2018, which was based on SAP Vora. Vora was supposed to be Hana’s twin but for big data volumes. Technically, Vora has to support the same SQL syntax as Hana to allow users to execute any query in Hana and transparently access the Vora-managed data.

First problem: Vora itself required all data in memory which is impossible to achieve for big data volumes. The solution was to silently incorporate the Sybase IQ database and call it the disk engine of Vora. Second problem: The most important Hana operation is joining tables. The most expensive operation for Vora (or any cluster system), however, is joining tables. Common sense can tell you that this does not match. The situation today: Vora is no longer on the price list and everybody who used the product for this use case had to replace it at their own expense.

Meanwhile, the SAP Hana team did the sensible thing. They merged the Sybase IQ disk engine into Hana directly and released the Hana Native Storage Extension feature, allowing table partitions to be kept on disk. Now a single engine supports hot, warm, and cold storage. All done by the Hana engine which is faster, cheaper, easier to manage, and has no fractures caused by the different engines. See SAP Hana Data Lake. Took no rocket science to predict that outcome.

Why does this happen?

If the root cause is so obvious, why does anybody fall into those traps?

Three common reasons:

• Change of direction
• Lack of communication
• Retrospection

If we use building a house as an analogy, a house is designed according to the requirements and then built following that plan. Some adjustments are possible, but nobody will say later on, “Uh, I changed my mind, I need twice the living space now”. In software development, the “building” process is less visible, and thus managers have less qualms to replace the underlying technology, the targeted use case, or both. Especially when the sales team found a large prospect, if only development would change something last minute. Using our analogy, “Can we build the house out of stone instead of wood? It’s the same house so it can’t be difficult!” Development managers need to resist the external forces and protect their dev team, even if users believe it is just a little change.

For larger projects, active cross-team communication is essential. Development knows the effort, marketing knows how it fits into the competitive landscape, architects know implementation options to utilize synergies, product owners negotiate the importance of each feature in detail. Every decision made by one has immediate impact on all others. If just one of these areas is underrepresented, the likeliness of a failed product is drastically higher. For example, the result could be a perfect product, even matching the customer demands, but it would have no go-to-market channel, meaning no access to potential customers. Or a product that was built for one use case could be sold to customers with different requirements, causing frustration on both sides.

Concerning the third reason, retrospection, it is easier to see where you went wrong in hindsight, following the path of how your own and other’s decisions have led to the result. Anticipating things upfront is the tricky part. I prefer assigning probabilities and ask myself a lot of what-if questions. How likely is it that xyz will happen, and what would need to change to cope with that? Most failed projects did not have a plan B, simple as that.