Business Model Design
The development and validation of a (more or less) detailed business model is usually the first step in the journey towards developing a new smart, connected product or solution. The business model will usually play a central role in product development, while in solution development, it will be most likely more basic. This section looks at tools and best practices for developing AIoT-specific business models, with a focus on the product perspective.
- 1 AIoT-enabled Business Models
- 2 Ignite AIoT Business Model Templates
- 3 Proof of Concept
- 4 Investment Decision
- 5 References
- 6 Authors and Contributors
AIoT-enabled Business Models
For a product or service-oriented organization, the business model usually describes how the organization creates, delivers, and captures value . For example, the St. Gallen Business Model Navigator  defines four dimensions for a business model ("What, how, who and value"): What do you offer to the customer? How is the value proposition created? Who is your target customer (segment)? How is revenue created?
For a more operations-oriented organization looking to introduce AIoT-enabled solutions, the business model will often be developed around the OEE formula introduced in the discussion about the Digital Equipment Operator: How will the investment in a new, AIoT-enabled solution benefit asset availability, performance rate or quality rate. The focus here will usually be more on the business case (ROI, OEE), and less on the other aspects of the business model such as value proposition and target customers.
When developing a more holistic business model that combines physical products with digital services, a key question is where to start. Many OEMs and manufacturers have been starting by looking at their existing portfolios of physical products and then trying to extend them with connectivity-based features, adding intelligence in a second step. If the target business model supported by these new, digital features is not clear, this can be problematic: Are the new features only seen as additional differentiators of the original product, or are they new sources of revenue? Not understanding this from the beginning can be very risky, leading to disappointing results. On the other hand, looking at business models only from a purely strategic perspective without taking existing products, capabilities, market access and brand reputation into consideration can also be difficult. So the truth probably lies somewhere in the middle.
Christian Renz, Global Head of IoT and Digitalization at Bosch, has made the following experience in this area: Successful manufacturers of physical products typically have a great understanding of their products’ domain: They understand usage of their product, value creation processes they are part of, the competitive landscape, purchasing behavior and so on. However, they view their domain through the lens of their products, which means they tend to not perceive value creation that their products are not part of. To successfully incubate new AIoT business models, product manufacturers need to build up competencies in service incubation and design. Coming from a hypothesis of value created for customers, dedicated teams quickly iterate through a series of “minimum viable products”, proving or disproving the value hypothesis. These cycles are much faster than typical product engineering cycles. The initial value hypothesis should be purely derived top-down from concrete customer pain points in the domain, rather than bottom-up from augmenting physical products with connectivity, allowing even for the freedom to come up with business models that could potentially disrupt an existing business.
What is important to understand is that business models usually evolve over time. In the agile and lean world, the assumption is that business model innovation is an iterative process. Many Internet-based business models are constantly re-evaluating and adapting their business models, utilizing the flexibility of the cloud and DevOps to do so. However, for business models based on physical assets, this is typically not as easy: Design and manufacturing of physical assets has much longer lead times. Once the assets are manufactured, sold and deployed in the field, any alteration of their physical configuration becomes very difficult if not impossible. Smart, connected products provide an opportunity to address this issue, at least to a certain extent, for example through dynamic configuration of digital features or, in some cases, even the enabling of physical features on demand. The following will discuss typical business model patterns enabled by AI and IoT in more detail.
AI Business Model Patterns
The area of business model patterns based on AI in the context of the IoT is not (yet) widely researched. The diagram below describes the most common patterns from the AIoT perspective.
IoT Business Model Patterns
The area of business model patterns for the Internet of Things is well researched and documented. For example, the St. Gallen Business Model Navigator  defines a number of patterns summarized in the table below. These patterns are generally based on the assumption that they combine physical assets with digital services.
A great example of a 'Digital Add-on' is BMW's announcement to make seat heating available on demand. Two factors make this interesting:
- Physically producing many different, custom configured variants of a car could be nearly as expensive as producing a single, mass-manufactured variant
- Being able to upsell this feature to customers especially in winter could significantly increase the total number of seat heating options sold in total
Ignite AIoT Business Model Templates
The following introduces a set of templates for AIoT business models. As far as possible, these templates reuse existing, well-established business model templates, adding AI and IoT perspectives to them. These templates should be seen as guidance and can be adapted in a flexible way to best fit the needs of your individual AIoT business model.
The Smart Kitchen Example
The following discussion will be based on the smart kitchen example, which is shown below. The complete Smart Kitchen Business Model has been documented in Miro. It can be accessed HERE, in case you can't read some of the details in the following diagrams.
AIoT Business Model Canvas
The business model canvas is probably one of the most established tools in the business model community. There are a plethora of variations, with Osterwalder representing the classic and the Lean Canvas the one probably most established in the agile development community. The basic idea of the business canvas is that - instead of writing a detailed and lengthy business plan - the key information typically found here is summarized in a canvas on a single page. Sometimes, the canvas also serves as the executive summary.
The AIoT Framework proposes an AIoT business model canvas derived from Osterwalder, but adds another area to specifically highlight the impact of AIoT on other elements, including value proposition, customer relationships, channels, key resources, key activities, cost and revenue structure.
AIoT Solution Sketch
The first template is the so-called AIoT Solution Sketch. The idea is to provide a very simple canvas which helps visualize the key functional elements of your solution, mapped to either the field (including EDGE functionality) or the backend (e.g., in the cloud). This simple yet expressive format is especially useful for reviewing and discussing the intended functional scope with management stakeholders.
AIoT Use Case Mapping
AIoT Use Case Mapping can be used to clarify how far one of the typical AIoT Use Cases can best be supported by utilizing AI and IoT together. An example is given here. In the example of the kitchen appliance, almost all generic AIoT use cases are relevant: AIoT will be used to improve the design of the kitchen appliance, data will be used for sales support, overall product performance improvements are in scope, as well as predictive maintenance. Finally, digital services such as recipe recommendations will play an important role.
AIoT Customer Journey Map
Customer (or User) Journey Maps are a common User Experience (UX) tool. There are many shapes, sizes, and formats available. The general idea of a journey map is to help understand and visualize the process that a person goes through to accomplish a specific goal.
The AIoT Playbook proposes a format for a customer journey map that has the key user interactions with the asset at the top, e.g., asset purchasing, asset activation, asset usage and service incidents. Depending on the complexity, each of these steps could be detailed in a map on its own. Below this, the template provides space for the following:
- Touchpoints: What touchpoints is the customer actually using to interact with the solution or the asset?
- Doing: What is the customer actually doing?
- Thinking/Feeling: This covers the emotional side of the journey
- Opportunities: What opportunities from a business model point of view can be found here?
- Key AIoT Features: What features/capabilities from an AIoT point of view are utilized here?
Note that this template focuses more on the high-level journey, including business model aspects. A more detailed, UX-focused version of this is introduced later in Product / Solution Design.
The commercial model has to address the question of how the product or solution is generating revenues at the end of the day. The model must bring together the offering and the target customer.
The offerings must be broken down as follows:
- Unique value proposition: potentially for different customer segments
- Sellable features: identify all elements of the offering that eventually generate revenue, e.g., upfront revenues for the physical asset, subscription revenues for digital premium services
- Pricing: all sellable features must be included in the pricing model
The target customer must be well understood, including:
- Industry/domain: this will look different for B2C vs B2B offerings but should be addressed, e.g., via a market segment analysis
- Profile: again, must be looked at individually, e.g. B2B buying-center vs B2C persons
- Buying process: how is the customer - as a private person or an enterprise - buying this? What formal conditions have to be met?
Finally, the question is how to get to the customer:
- Sales approach: traditional Solution Sales and Key Account Management, web-based sales, in-app sales, etc.
- Monetization: how to turn non-revenue-generating items into revenue, e.g., by getting customers to upgrade from digital fremium to premium services
It is usually advisable to include a set of Key Performance Indicators (KPIs) in the Business Model. KPIs are measurable values used by organizations to keep track of and determine progress on specific business objectives. A good method for defining KPIs is the SMART method. SMART means that KPIs should be specific, measurable, attainable, relevant, and time-sensitive. Example KPIs for an AIoT product are described in more detail in the Product Design section.
KPIs are a good way of guiding the execution team and evaluating their progress against a previously defined set of goals in the business model. Closely related to this are Objectives and Key Results (OKRs). While KPIs are business metrics that reflect performance, OKR is a goal-setting method which can be used as a project steering mechanism. However, this would usually not be part of the business model.
KPIs for the kitchen appliance example could include:
- Number of kitchen appliances sold
- Average subscription revenue per customer
- Monthly recurring revenue
- Customer Lifetime Value
- Customer acquisition cost
These KPIs are assuming an established business. In the early phase of business model validation, different KPIs should be applied - for example, KPIs related to UX.
AIoT Business Case
Another key element of the business model is the business case, including the financial perspective on costs and revenues, as well as strategic contributions.
The direct ROI for an AIoT solution must typically take into consideration asset-related and service-related costs and revenues. On the cost side, the differentiation between capital expenditures and operational expenditures (including unit and operations costs). On the revenue side, the business case must differentiate between upfront revenues and recurring/subscription revenues. The AIoT Playbook proposes combining these perspectives in the template shown below.
Please note that business case development and ROI calculation usually also require some kind of quantitative planning, including projections for numbers of units sold, customer adoption of digital features, and so on. A detailed example is given in the Product Design section.
In addition to the direct ROI of the investment, many AIoT solutions also provide strategic contributions to a higher-level business case. Take, for example, the eCall feature of a car. This potentially AIoT-enabled device in vehicles will automatically call a local emergency service in the event of a serious road accident. Airbag deployment and impact sensor information, as well as GPS coordinates, will be sent along as well. The question is as follows: Does this feature require a dedicated ROI calculation, or is this simply the fulfillment of a regulatory requirement? Since eCall is now a requirement in the EU, for example, it is unlikely that this can be sold as an add-on with extra revenue. So it must be seen as a strategic contribution to the car.
AIoT Business Case Validation
Validating the AIoT Business Case in the early stages as much as possible will save you from costly surprises further down your AIoT journey. The business case validation should include both sides, costs and revenues.
Validating assumptions made about revenue in the business model is of course tricky. Usually, a good way forward is interviews with potential customers to validate not only their willingness to purchase the intended products and services but also their price sensitivity.
Furthermore, one should also not underestimate the importance of validating the cost side of the business model. This is especially important for an AIoT-enabled business: While virtual, cloud-based business can scale very well on the cost side, with any business that is involving physical assets or products, this is different. Physical products will have to be manufactured, distributed and supported. A thorough investigation of unit costs/marginal costs should be performed as early as possible, and ideally validated by obtaining price indications from potential suppliers as early as possible. The AIoT Sourcing BOM introduced in the section on Sourcing and Procurement can be a very helpful tool.
In addition to IoT-related costs (especially hardware and costs for telecommunication), AI-related costs should also not be underestimated. In particular, the data labeling can be a cost driver - do not forget that this will not only cause costs for the initial data labeling but most likely require continued labeling services throughout the entire product life cycle.
In general, IT-centric business cases have a tendency to focus more on the initial costs, and not the Total Cost of Ownership (TCO). Over a five-year lifespan, initial development costs will most likely be only 20% of the TCO.
Proof of Concept
Most investors require some kind of proof along the way, which provides evidence for the feasibility of the investment proposal (this applies both to corporate investors and private equity investors). AIoT-based solutions are not different from that perspective. However, it can sometimes be much more difficult and expensive to run a Proof-of-Concept (PoC) for an AIoT solution: Today it is usually very easy to create a lightweight and affordable PoC for a pure software project (e.g., using simulation or mock-ups). However, as soon as hardware development and/or asset customization is involved, this can become much harder, depending on the hardware and asset categories.
Consequently, the following should be clearly defined for any AIoT-related PoC:
- Duration & effort
- Success criteria
In today's agile and digital world, most investment decisions are staged, meaning that partial investment commitments are made based on the achievement of certain milestones. However, there is usually a point in time for any innovation project where it transitions from the exploratory phase toward the scaling phase with much higher budgets. Each organisation is typically follows its own, established investment criteria. For the project manager, it is often important to keep in mind that these criteria are usually a mixture of hard, ROI-based criteria, as well as the strategic perspective. This is why the business model should address both perspectives, as stated above.
- Business Model Generation, Alexander Osterwalder, Yves Pigneur, Alan Smith, and 470 practitioners from 45 countries, self-published, 2010
- The Business Model Navigator: 55 Models That Will Revolutionise Your Business, Oliver Gassmann, Karolin Frankenberger, Michaela Csik, 2014
- Distribution of Cost over the Application Lifecycle - a Multi-case Study, Ruediger Zarnekow, Walter Brenner, 2005
Authors and Contributors