{"id":1941,"date":"2024-09-02T08:30:34","date_gmt":"2024-09-02T08:30:34","guid":{"rendered":"https:\/\/janbosch.com\/blog\/?p=1941"},"modified":"2024-09-02T08:30:35","modified_gmt":"2024-09-02T08:30:35","slug":"from-agile-to-radical-business-model","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2024\/09\/02\/from-agile-to-radical-business-model\/","title":{"rendered":"From Agile to Radical: business model"},"content":{"rendered":"\n
\"Photo
Photo by Slidebean on Unsplash<\/figcaption><\/figure>\n\n\n\n

Have you ever wondered why car companies don\u2019t run A\/B experiments with their customers\u2019 vehicles to improve the fuel efficiency of the engines? It would be perfectly feasible to build engine control software that would, safely, allow for experimentation with a wide variety of parameters to evaluate what settings, in what context and for what driver profile, lead to the best fuel efficiency.<\/p>\n\n\n\n

On the other hand, many SaaS companies run hundreds if not thousands of A\/B experiments per year on an offering that for all purposes often is significantly smaller and simpler than a car. And the nature of these A\/B experiments can be quite narrow and seemingly insignificant, such as the \u201c50 shades of blue\u201d experiment that Google ran years ago.<\/p>\n\n\n\n

So, why do SaaS companies run tons of A\/B experiments and car companies run so few, if any? The answer is very simple: it\u2019s the business model. A\/B experiments in SaaS companies almost always are concerned with improving the bottom line. For e-commerce sites, it\u2019s conversion. For publishers, it\u2019s ad revenue. The goal of the A\/B experiment is to improve company revenue and profit. Conversely, for car companies, improving the fuel efficiency of their cars has no revenue implications. Especially the cars that have already been sold to customers. As there\u2019s no business incentive, car companies don\u2019t conduct A\/B experiments on fuel efficiency.<\/p>\n\n\n\n

If we generalize this to all continuous practices, we see the same limitation in the business model. Companies that are slow in adopting DevOps for customers often lack a business model that allows them to monetize any improvements that customers may experience. Instead, periodic releases of software are typically concerned with fixing quality issues as the company is contractually obligated to do so and less with delivering new value to customers.<\/p>\n\n\n\n

Of course, I\u2019m far from the first to realize this and many companies have been looking for ways to complement the transactional revenue from traditional product sales with continuous revenue for updates to the product as well as complimentary services around the product. The challenge is to convince customers to give them money beyond the initial transaction. The main reason is that the continuous offering is too close to the base functionality of the product itself and customers feel entitled to that for free as they already paid for the product.<\/p>\n\n\n\n

In research we conducted a few years ago (see figure below), we realize that companies evolve through a number of steps in their business model. They move from traditional product sales to providing their product as a service for some customer segments. For instance, several car companies offer their cars as a subscription that customers can cancel whenever they want.<\/p>\n\n\n\n

\"\"
Four dimensions of digital transformation<\/figcaption><\/figure>\n\n\n\n

The next step often is to provide complementary services around the product. For instance, many companies offer uptime services. A truck company may offer fuel services, trailer services, safe resting place services, and so on. The idea is to provide services that make the base product more attractive but still monetize the services using a freemium model or something similar.<\/p>\n\n\n\n

The hard part is the step after that: aligning the business model with the customer KPIs. In this step, the traditional transaction goes away and all revenue is created continuously instead. For example, the customer no longer buys a truck but pays for every on-time delivery achieved using the truck. This transition has enormous implications on the cash flow of companies during the transition as the transactional revenue often is generated at the time of sale whereas the continuous revenue is generated throughout the economic life of the product. The lifetime revenue may be significantly higher, but in many ways, the model forces the company to extend a loan to the customer as it\u2019s forced to finance the product on behalf of the customer.<\/p>\n\n\n\n

The advantage of the fourth step is that continuous practices immediately have an associated business model: any update and new functionality we can provide improves the customer KPIs and since we get paid for delivering on these KPIs, we\u2019re automatically monetizing the work associated with the continuous practices.<\/p>\n\n\n\n

Many companies struggle with the transition to the fourth step, and fail without having a business model in place to support continuous practices. This is a dangerous place to be, especially as new entrants often don\u2019t have the baggage of incumbents and have no qualms about offering a customer KPI-based business model to their customers. So, when customers are ready to transition, you better be ready too.<\/p>\n\n\n\n

The lack of a business model supporting continuous practices often leads to significant resistance outside of software R&D. Incurring continuous cost in R&D without getting paid for it isn\u2019t an attractive idea in the eyes of many business leaders. However, the right answer isn\u2019t to stop the adoption of continuous practices, but rather it is to more aggressively explore alternative ways to generate continuous revenue. To end with a quote by Scott D. Anthony: “Most companies are built to execute today’s business model, not discover tomorrow’s.” <\/p>\n\n\n\n

Want to read more like this? Sign up for my newsletter at\u00a0jan@janbosch.com<\/a>\u00a0or follow me on\u00a0janbosch.com\/blog<\/a>, LinkedIn (linkedin.com\/in\/janbosch<\/a>) or Twitter (@JanBosch<\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Have you ever wondered why car companies don\u2019t run A\/B experiments with their customers\u2019 vehicles to improve the fuel efficiency of the engines? It would be perfectly feasible to build engine control software that would, safely, allow for experimentation with a wide variety of parameters to evaluate what settings, in what context and for what … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[4,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1941"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1941"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1941\/revisions"}],"predecessor-version":[{"id":1942,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1941\/revisions\/1942"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1941"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1941"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1941"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}