OBSTACLES

A starting company has limited resources available for developing radical innovations and new solutions. However, these resources are necessary for the development and must be acquired. A small software start-up might make do with a few laptops and some cash, but in this case, that will not suffice. In this case, we are looking at a product-service system containing both software as hardware components in a heavily regulated industry with lots of sceptical stakeholders that all have to interact to implement the solution successfully.

The implementation overview provided is not the absolute truth. It is an analysis-based sequence of events that is ought to be suitable for achieving a successful implementation of the solution.

Therefore, it is vital to understand the possible obstacles (i.e.., limitations and pitfalls) of the implementation roadmap. By doing so, it should become clear what the error margin of the roadmap is and thus, what value it brings to the company.

These obstacles are discussed in three different categories. First, a look is taken at resource-based obstacles: restrictions and limitations due to the resource availability of the company. Second, value- based obstacles are discussed that show the difficulty in implementing a radical innovation. Last, project-based limitations and pitfalls are discussed, including the discussion on theory versus practice.

Succeeding in business is often dependent on “overcoming a series of potential barriers, e.g. limited human capital, management capabilities, high uncertainty in terms of product and market, volatile development process, weak partnership ties” (Fielden, Davidson, & Makin, 2000).

13.2.1 Resource-based obstacles

The first generic issue is the lack in resources, especially time and money. As would not be surprising, a company of three has limited access to financial investments when just started. With three employees, the time available that can be spent on the development of this solution is also severely limited. The

second limitation is in the available experiences and knowledge of this solution and of the industry and context in which the solution will operate. The company has three employees of which one works in the medical industry. At the start of the development of the solution, no knowledge was available on CRC or gastroentology which are vital research topics. Additionally, no experience was present on starting a medical device company and thus, no knowledge was available on the regulations and liability issues present in medical device development. Knowledge that is essential, as the solution must be developed according to the regulations for it to be accepted onto the market. Developing a solution but disregarding the regulations will result in rejected proposal and obsolete investments. Third, even more so, due to the lack of medical knowledge and the lack of proof of being capable of developing medical devices, credibility limitations also play part. A company that has not shown being able to develop a medical device and that company also not being supported by trusted care professionals, is not being seen as credible. Due to this lack in credibility, convincing necessary key partners of providing necessary resources and knowledge is quite difficult and will hamper development. In addition, acquiring necessary financial investments is also difficult and will, therefore, negatively impact the development and business viability of the entire operation. Especially in the case of acquiring investments, (angel) investors and venture capitalists (VC’s) look at the team, credibility, and market opportunities to base their investment decision on.

13.2.2 Value-based obstacles

Understanding what the value is of something that does not yet exist is difficult. Seeing the potential in a new innovation or understanding what something could become in the future, are difficult skills to master, burdened by experiences and perceptions.

Convincing customers, key partners, relevant stakeholders, regulatory bodies and other involved actors of the value of the solution when it does not exist yet, is also difficult. When a key actor sees no value in the proposed solution, interaction will be most likely be ruled out.

This has been made abundantly clear during the development of this solution : not everybody is capable or willing to see value in something that has not been fully developed yet. This is partly due to the common Dutch mentality, “eerst zien dan geloven” (“seeing before believing”), as well as due to the evidence-based nature of the industry (which coincides with each other).

This concept can be best explained with some pragmatic examples.

In the case of the customers, buying something that you do not know if it works or not, is highly unlikely. Especially in the current consumer market place that is driven by online reviews, the solution must have proven its functionalities and value. An example could be the introduction of the first iPhone. A new telephone with a touch screen that provided more functionalities than ever seen before. However, Apple needed to develop and built the device to show the consumer the value it offered. Would Apple offered a vague concept and asked consumers if they would be interested in buying such a solution, than the story might have gone a different way.

Even more so, before a medical device can be sold, it needs to demonstrate its functionalities in a clinical study before it can be approved and sold on the market (as mentioned in chapter x.). Therefore, in the case of regulatory stakeholders, a working device must be built as otherwise the clinical studies cannot be performed. Changing variables or functionalities in this device will result in the clinical studies having to be performed yet another time. So, the device must be almost identical to the actual consumer version of the solution.

In the case of the healthcare professionals, promoting a product that has not been tested and accepted is a dangerous move. Especially as all healthcare professionals can be traced in the BIG register (online accreditation register) and can be held responsible for misconduct. So, the solution must be tested and approved upon by the regulatory stakeholders before a care professional is willing to attach his/ her name to it.

In the case of governmental and insurance stakeholders, without proof no financing structures can be employed to implement the solution . The efficiency and (cost-)effectiveness of the solution must be studied and proven before these stakeholders will even go into discussion on adaptation and implementation.

In the case of production and operation stakeholders, without definite proof of customer and market value, no business can be done. In other words, if there is no proof of commercial viability and the possible pay-off, attracting the necessary partners to deliver parts of the operation of the total solution will be an impossible feat. Therefore, due to resource dependency one must be able to contract partners which can provide.

13.3 LEGEND

Across the entire implementation design part, similar symbols are used to display the super-system and system design, as well as the business model of the solution. These symbols include the company (as legal manufacturer), the user/patient/consumer, a healthcare research institute (which is necessary during the validation studies, the insurer, and the NB. Figure 25. shows which of the relevant stakeholders is depicted with which symbols, providing guidance to understand the illustrations.

This phase describes the start of the further development of the solution. Whereas other phases are targeted at specific applications in specific contexts, this phase purely serves to deliver a proof of concept. That is the goal of this phase and it is important, as without proof it becomes nearly impossible to convince stakeholders of participating in this project. First, this phase is elaborated upon in the six perspectives as mentioned before: financial, human, intellectual, social, organizational, and resource capital. In these chapters, suggestions on actions that the company should perform based on the analysis of the context are provided in combination with a summary of possible pitfalls that detail avoidable risks. Additionally, mitigation strategies are provided that can aid the prevention of such risks. Second, a description is provided that details how the company can judge if this phase is successfully executed and completed. Last, decision criteria are provided that should be used to decide if another phase should be entered. To emphasize, the final decision is that of the company. It is not I who decided whether or not a phase is successfully completed or if it’s time to move to the next phase.

14.1 SOLUTION DESIGN

In this phase, the solution should be developed as a prototype. It will become the first real-life implementation of the solution. As mentioned in the introduction, the goal of this phase is not to develop the most ideal version of the solution, but to develop and construct a version that is testable and able to be used for testing and the gathering of feedback.

Prototypes should command only as much time, effort, and investment as are needed to generate useful feedback and evolve an idea. The more “finished” a prototype seems, the less likely its creators will be to pay attention to and profit from feedback. The goal of prototyping isn’t to finish. It is to learn about the strengths and weaknesses of the idea and to identify new directions that further prototypes might take (Brown, 2008).

Therefore, not all functions from the ideal version of the solution are included in the prototype. The functions that are essential to showcase the possible applications of the solution focus only on measuring the faecal components, processing these so that the results can be analysed and an evaluation of the health status of the sample can be provided. Other functionalities, like performing big data analyses or communicating the results to the user, are either impossible due the lack of gathered information, or unnecessary as the product is not yet in the consumer product development phase.