Two approaches for developing a platform

In this thesis, two approaches for developing a platform for solutions have been identified: starting with an individual solution or with developing the basis, i.e. the platform. The first describes so- called ‘learning projects’ (Paper 2), which aim to develop both knowledge about technology and knowledge about users and usage by learning from an individual case. Along with the COBO project, Gamma runs several such learning projects. Usually, projects starting with an individual solution are conducted in close collaboration with a customer, thereby enabling in-depth insights into that customer’s specific processes. Knowledge gained from such collaboration can thereafter be mobilised in developing new solutions for additional customers. Such an approach is closely associated with the development of repeatable solutions in the complex product systems context (Davies & Brady, 2000) and overlaps with the idea of customer platforms, in which expansion into related markets is made by using a beachhead as a base (Sawhney, 1998). Another common feature of the approach is its application when technology is still immature and when it remains unclear what the business model for the solutions will entail. In such projects, the establishment of the business model, sometimes together with a partner, as described in Paper 5, has been the point of departure. That situation also means that the development of technology, as well as the knowledge about the technology required, is greatly influenced by the service aspect that doubles as the foundation for the business model, especially in terms of revenue. Based on that newly established business model, the development of the solution occurs on a small scale, usually to solve a specific problem in close collaboration with the specific customer and partners. Accordingly, knowledge about technology and knowledge about usage are developed in an integrated fashion, and the knowledge gained will thereafter be used as the basis for another solution, meaning that the

102

platform evolves. That approach partly describes the replication of services discussed by Gremyr et al. (2019), albeit focusing on a platform architecture under development instead of a modular approach.

Because developing a platform by starting with an individual solution offers flexibility, it can be a suitable amid relatively high variation in customers’ needs over time. After all, the platform will evolve as the knowledge gained by collaborating with different partners and customers accumulates, and in that light, it is also flexible in relation to emerging trends and problems. However, even if the approach enables closeness with the customers and affords considerable flexibility, it comes with challenges associated with its emergent nature. Because neither the platform nor the solution family is decided upon beforehand, the size of the potential market cannot be known, nor can the solution’s value for the customer and how it will determine potential revenues. Those challenges were evident at Gamma. On the upside, the approach could be fruitfully applied if the company seeks to explore the solution business, for it can be implemented on a small scale at first. However, the approach also requires customers who want to participate in explorative projects. Furthermore, customers are likely unwilling to pay as high a price as they would if they had reference cases (Paper 2) which might have indicated the magnitude of the potential improvement and in turn the cost savings. Consequently, the individual solution could result in a negative business case. Ultimately, however, even if an individual solution may seem to end as a loss, it could be a necessary cost of acquiring and developing knowledge to be exploited in developing other solutions.

The other way of developing solutions through a platform approach is by first establishing its basis. The ECOS project, described in Papers 3 and 4, followed that approach. Therein, the functionality that needs to be delivered is defined, and in turn, the platform is developed based on capabilities needed to provide that functionality. For such an approach, knowledge about technology appears to receive initial emphasis. Of course, knowledge about usage is also involved, but it seems to be mostly concerned with usage at a more general level (i.e. targeting different segments or users), because the development of such a platform occurs remotely from the customer both in time and space. Accordingly, in-depth knowledge about usage is unavailable at the time of development, which burdens the approach which a few major challenges.

103

At Gamma, the product development function occupies a relatively strong position within the company. Representatives of service development, perceiving an overly ‘industrialising’ mindset of the product development function, argued that the function thus tries to ‘make everything a platform’. That tendency creates inertia in development efforts, in which customers are seldom involved in the first place. By contrast, service development is usually more agile and with shorter lead times than product development. Developing a platform by taking the approach in which the basis is first established requires defining services well in advance. That process thus takes place removed from the customer’s usage, which makes the platform’s relationship to more specific problems less clear. This results in that the services are defined at a very general level. Also, to be able to do so, stability in the customers’ problems are required. Due to the length of this development approach, the risk of delivering services that are addressing obsolete problems at the time of launch must be considered.

Moreover, as described in Paper 4, the ECOS project also confronted problems with being overly focused on product aspects at the expense of interest in services that were supposed to be integrated with those products. Another problem is the problem of mostly building business cases based on number of sold products, as noted in Paper 3, making it tricky to show the value of service development in general. However, this is even more challenging when the services are to be integrated with products. Further still, in platform projects, especially those in which the ultimate (economic) value comes from services, it is challenging to calculate the return on investment. The value deriving from a platform project of that sort is accordingly difficult to grasp from a business perspective, especially when the solutions have not yet been defined or priced in detail and because platform projects are typically costly, as Paper 3 shows. In fact, this difficulty was reported as a reason for the budget cut to the ECOS project as described in Paper 4.