How can digital transformation be sustainably integrated into the company in the long term with digital products?

A successful transformation and introduction of digital products – also with IoT – is based on the three pillars “Strategy & Business”, “Organisation & Process” and “Technology & Product”. In this way, the company is viewed holistically. If the three pillars are carefully designed in terms of content, nothing stands in the way of a successful digital product.

Each of the three pillars is additionally divided into three levels or ways of thinking. The three levels of strategy, structure and implementation differ in terms of altitude. The levels must be passed through accordingly in the organizational structure without anyone being left behind.

Advisory three stages

If all these topics are taken to heart, therisk involved in digitizing a product is minimized enormously and at the same time the chance success for a functioning solution with real added value increases.

It doesn’t have to be a linear process. It is important that all topics are at least considered. Every company is at a different point.

In the following, we show step by step the aspects that should be considered for a successful implementation of a digital product. We give you a practical guide so that all relevant points become visible at the beginning of a project and can be conceptualized.

Strategy and Business

Strategic level – IoT business potential

With what intention should a digital transformation or a digital product be realized?

The business potentials result on the one hand from optimizations of existing value chains, and on the other hand from the establishment of completely new business models and thus a unique selling position (USP). In the latter case, the potential lies in the generation of new customer groups and additional value streams; a new type of customer loyalty.

Digital solutions generate benefits that are more difficult to recognize at first glance. These include increased customer loyalty, more direct contact with the end customer, new marketing and sales opportunities and, last but not least, opportunities for differentiation on the market.

A positive cash flow of the use cases is always essential for the implementation and scaling of the potentials. It is therefore important to consider how a Return-On-Investment(ROI) and a realistic cost-truth is presented. In addition, it is important to consider what the customer is willing to invest money for in the long term and how much.

Our practical tips

  • It is crucial to know the customer with his jobs and challenges.
  • Existing customers are not always the customers for the digital product. Depending on the business model, the customer can always be different. End customer, reseller, sales organization, service partner, internal departments, etc. are all possible customers.
  • Business models must fit the company and be implementable. The plans should be challenging, but not too ambitious.
  • Customers must also be able to “digest” new business models and be willing to engage with them.
  • Ideas are very good. t is important to test them quickly and find out what really works in the market.
  • Sales as the key to success → The classic sales organization faces the challenge of having to sell an unknown product that neither they themselves nor presumably the customers have had anything to do with before. At its core, it’s about trust.
    No one wants to sell things in which they have no trust. So it’s important to involve the sales department right Establish him as the internal representative of the customer and also address from the beginning how to support sales to sell the new products and services.
  • How can the risk be kept in check?
    • Test ideas quickly in all areas, focus on the relevant aspects, and thus enable rapid learning.
    • Scaling is the consequence of doing it right!
    • Cost risk for implementation → at the start, assemble your own solution from “standard solutions” as far as possible.
    • Custom development or later backward integration usually only really makes sense once the viability of the business model has been proven.

Structuring level – product life cycle

The product life cycle represents the “life cycle” of the product – from cradle to grave. It is not simply a process, but rather the entire value proposition manifests itself in the product lifecycle. By looking at the lifecycle of a digital product from manufacture to operation to retirement, requirements arise for the product itself as well as those for the organization and its processes.

One of the first steps is therefore to outline the product lifecycle and derive requirements and measures from it. Through these considerations, all stakeholders are identified. This ensures that all stakeholders are known. This helps to ensure that all stakeholders are included in the complex world of digital products, that their requirements are perceived, and that they can thus contribute to the success of the product.

Product Life Cycle

Our practical tip

A lifecycle can only be described if the value proposition is already roughly defined. To do this, there must be an internal consensus on the business case, target group and value proposition. Tools such as the Business Model and Value Proposition Canvas are suitable for this. The product life cycle is subsequently a means of implementing the value proposition in a structured manner.

Implementation level – Value proposition

The value proposition is the central component of the business model with which the digital product is offered. It pays immediate dividends to extend the value proposition consideration to all participants in the value chain. These can be identified with product lifecycle considerations. It is not uncommon for the greatest added value of a digital solution to arise not for the end customer alone, but for other participants in the value chain, such as sales or service or business partners.

While it is obvious to actively involve these partners in the business model and in the development of the solution, this is often overlooked in practice. By answering the following questions, the added values for the respective stakeholders can be identified.

  • Which jobs of the target groups are simplified by the solution?
  • What problems can the solution take away from the target group?
  • Who are the customers of the digital product? For which target group does the solution generate added value?
    All participants in the value chain should be considered as potential customers.
  • Who can use the products and data to create their own solutions? Do you have to develop the right solution for each end customer yourself, or can you enable partners to do so?
    For example: as a manufacturer, one could offer service partners the possibilities to generate applications and added value for their specific market. A sales company in France, for example, could automatically deliver consumables to the end customer based on the data. A partner in Germany uses the same data for a specialized on-site service.
  • Does the solution itself create new jobs for the target group? Do the benefits outweigh the cost of these additional jobs?

The Value Proposition Canvas is an optimal tool to get the answer to the above questions.

Value Proposition Canvas

Our practical tip

Ask the customer the right questions! You should only ask the customer about his tasks and problems, not about his wishes or solutions. According to Henry Ford: “If I had asked people what they wanted, they would have said ‘faster horses'”.

The claim should not be to want to please all customers 100%. You will never be finished. The goal should be to create the greatest added value for the customer group with the highest potential.

The market always speaks the truth. All ideas and concepts should always be tested with suitable customers as quickly as possible and with minimal effort.

Organization and process

Once the business potential has been identified, the value proposition has been clearly formulated and all stakeholders have been identified with the help of the product lifecycle, the organizational and process transformation in the company also starts at the same time as the product development.

Strategic level – IoT business processes

The Internet of Things combines physical products, data transmission and software into one solution. IoT products cannot be developed and sold like pure physical products or software. The art lies in effectively combining processes from the mechanical, hardware and software world. Again, this applies not only to the development phase, but to all processes that are necessary to realize the business model. In addition to the abstracted example processes in the graphic, significant process extensions can be expected in the areas of management, product management, finance and law.

Looking at the processes is important because they give rise to requirements that the digital solution must map in order to enable the processes in the first place. Above all, however, the need to make organizational adjustments also becomes clear.

Our practical tip

Digitisation is a matter for the boss!

It is important to be clear about the following:
Especially when looking at processes and the organization, it becomes clear that companies have optimized their value chain over the time of their existence. The introduction of digital solutions cannot be mapped exclusively via existing value chains and organizational structures. The new value creation elements therefore require corresponding process and organizational adjustments as well as extensions to the existing skillset.

Structuring level – responsibility matrix

The integration of digital products creates new areas of responsibility with initially unclear responsibilities. By analyzing the business processes, the changes can be recognized and tasks identified and described. It is advisable to detail the tasks from large to small.

As soon as the tasks are identified, they are assigned to an area and skills and resources are built up for them.

Our practical tip

The redistribution of tasks and responsibilities can lead to tensions between individual areas. The redistribution of tasks and responsibilities can lead to tensions between individual areas. These can be, for example, fear of not having the resources and competencies in the respective area. When deciding on the allocation of tasks, the focus should be on what makes sense in terms of content.


Implementation level: Skillset of the operational team

A successful digital product is the result of interdisciplinary collaboration between teams within the company and expertise brought in by external partners. Be it on a strategic, organizational or technical level.

Especially in technical implementation, the challenge is to bring together an unusually large number of competencies. From mechanics to embedded software to cloud and app, a multitude of technical tasks arises for which specific competencies must be built up. These different competencies are rarely united in a single person.

Our practical tip

The multitude of competencies are brought in by people with different mindsets. A superordinate system architect is an important function for assuming overall technical, interdisciplinary responsibility.

When building up competencies, it is important to be aware of which areas you want to take on permanently yourself and which you want to commission externally. Buying in competence externally can bring advantages in terms of time and quality. Just as it makes sense to consider which competencies you regard as core competencies and then build them up internally.

Technology and Product

Strategic level – Ecosystem

The technical possibilities for implementing a digital solution are almost inexhaustible. It is an art in itself to select the appropriate ones from the multitude of platforms and technologies. In many cases, a variety of technologies and services are combined to create a solution. When developing a solution, it is crucial not to focus on quick success, but to take afar-sighted view of the operation and the diverse scaling across all levels.

Technology decisions must be made on the basis of requirements derived from the preliminary work on strategy and structuring. decisions must be made on the basis of requirements derived from the preliminary work on strategy and structuring. Nevertheless, it is advisable to foresee variability so that technology leaps and the evolution of the business cases can be mapped.

The core goal for the ecosystem is to create the technical possibilities for partners, customers, retailers and all other stakeholders to participate in the system.

Advisory Architecture

Our practical tip

Building new competencies on technologies creates a technology push situation. Innovative ideas arise from the internal visibility of new possibilities. In daily business, it is therefore advisable to keep a product roadmap and a technology roadmap synchronized and in parallel.

Structuring level: Architecture and non-functional requirements

The equal weighting of

  • functional product requirements – what does the product do?
  • non-functional architecture requirements – How does the product do it?

is essential in order to keep expanding the digital solution in incremental steps.

digital product requirement scale

A digital product does not work well if it has many functions but is slow or insecure. The reverse is also true for a product that is technically elegant but lacks utility. The best case scenario is to balance functional and non-functional requirements and move steadily forward with an MVP-approach(Minimum Viable Product).

MVP for the development of digital products - how the transformation succeeds

The following checklist provides a starting point for checking whether the most relevant aspects have been taken into account in the systemarchitecture or whether they are at least on the roadmap.

Advisory - Get Digital Solutions Done - System Architecture Checklist - Title Page

Have you considered all aspects of the system architecture for your IoT solution?

Implementation – product requirements

Regardless of the tool, it is necessary to set up a requirements management system in the event of scaling. In this, requirements for the technical solution are collected, evaluated and implemented step by step. Beyond the implementation, the fulfillment of each requirement should be tested. On the technical level, this is done by quality assurance, but the content fulfillment of a requirement can only be done by the stakeholders.

The V-model is well suited for requirements to go through the different levels from conception to development and from functional testing to acceptance by the stakeholders. This also works when the solution is developed in an agile process.

V-Modell - Source Wikipedia own representation
Source Wikipedia own representation

If the solution is to be certified according to certain standards, for example as a medical device, continuous documentation from the requirement to the testis mandatory anyway.

Our practical tip

Although there are many technical options for implementing requirements, the focus should always be on simplicity and good usability for users.


The plethora of issues that arise when implementing a digital solution can be opaque at first glance. However, with an awareness of the issues that need to be addressed, many pitfalls can be easily avoided. As long as the added value that a digital solution delivers is at the forefront of everything you do, everything else is “just doing”.