We've come to the last video in this course and we're going to pick up the thread of Platform Thinking and see how reasoning about the concepts seen in these videos and the data collected from digital services can help us in the design of a platform. Platform Thinking is the ability to think from a platform perspective, whether you start with a business traditionally based on a linear value chain, a small two-sided platform or more simply a digital service looking for a sustainable business model. This concept is at the heart of this MOOC series, and in previous installments we've seen the process we've developed to help existing companies innovate through platform models. In a nutshell, the Platform Thinking process is based on three main steps: - The first is the identification of the idle assets that will form the basis of the platform; for this phase we recommend the use of the Idle Asset Canvas. - The second is the design of the platform, with the identification of the ecosystem of the platform and therefore of all the actors involved - The third step involves the definition of a roadmap to understand how to overcome the typical problems of the platform, such as the chicken and egg paradox, and how to bring on board the various sides in a longitudinal perspective In the presentation of this process in the second MOOC we referred to the possibility of creating platforms that also had orthogonal sides, as in all the examples we have seen in this course....but we did not introduce a useful tool to identify them and it is now time to introduce it. I am talking about the Data Board. We've talked about it, identifying the orthogonal side - in many of the cases we've seen - is the result of a random process, which we've called Data-Driven Epiphany, and we've tried to structure it, inspired by the principle of platform with idle asset hunter and the idea of Data-Driven Innovation, with the possibility of having a more active and structured role in identifying the actors that will become part of the platform even for the part that concerns data. The data board, like all the templates in the Platform Thinking process, is not a deterministic tool that can give us an answer, on the contrary it is a supporting tool that asks questions, making us think critically about the data we may have available in the platform and then identify potential orthogonal actors to be involved. Let's start by describing it: First of all note that the Data Board must be used for a single type of data, so for the same platform we could compile more than one. In presenting the board, we will use the travel data collected by Uber as an example. Second, we note that the data board, like many creative approaches, relies on a divergent/convergent structure, with the goal of first identifying even the least obvious alternatives, and then focusing on the most promising ones. Let's get into the details. The first step requires identifying the "data creators" by identifying who the data creators are in the system we are looking at and what that data is. In our example, Uber, we have drivers and travelers as data creators who generate data through their encounter, such as ride start location, end point, route, time, and Expected Times of Arrival and its updates during the first trip. The second step leads us to identify the "Related stakeholders in the ecosystem", in other words which are the other surroundings already present on the platform that could be interested in these data. Uber, for example, already has riders and restaurants on board for Uber Eats. We don't know if the data we're analyzing can actually be useful for those players, but writing them down can help us in identifying where that data might actually be useful for someone already on the platform. The third step leads us to identify the "External players that might be interested in the data", in other words this is the purest brainstorming phase, what are those players that may in some ways be interested in the data we have? To identify them, we can analyze the entire value chain of the sector in which we are working, but also adjacent value chains. For example in the case of Uber we might have: - the department of transportation - Mobility Research Centers - The creators of algorithms for the movements Obviously this line is not exhaustive, but it allows us to see how at this stage we need to open up the opportunity set as much as possible, we are in the last divergent step of the process. At this point we should be clear in our minds: - what data we are looking at and who creates it - Which actors are already on the platform - Which actors are potentially interested in this data With the fourth step, we start the selection phase: we have the list of all the internal and external stakeholders that are potentially interesting. The question, for each of them, is what is the value proposition we could offer them? It is not a given that we will be able to identify a value proposition for each of the identified stakeholders. For example, riders or restaurants - among the internal stakeholders of the platform in the case of Uber - do not show obvious opportunities. Similarly, we might offer value to algorithm creators or transportation departments, but also likely to have more extensive and more valuable data from other actors. Think, for example, of navigators like Waze or Google Maps, who actually collaborate with these kinds of actors. That leaves urban mobility research centers; the value proposition for them might be "Let's find smarter ways forward, together." Which is precisely the value proposition of Uber Movemenet, Uber's beta phase project that gives access to travel data collected by the platform to research centers. The last step brings us closer to designing the service for orthogonal customers, such as research centers in this case, what is the degree of transformation that we, as a platform provider, want to do on this data? In other words, to the potential orthogonal customer we are analyzing can we simply offer the database and manage to monetize it - as Twitter does for example by giving basic access to the stream of tweets with hashtags and data - or do we need to transform that data into information - as Strava Metro does for example by offering dashboards with heatmaps and not raw data points? This last question allows us to understand what kind of work the platform provider will need to do before approaching the orthogonal client, which at this point has been identified. With this further step we close the Platform Thinking process, having a support also in the identification of potential orthogonal customers, without forgetting to have a continuous critical spirit on the analysis and consideration that we do. We could also identify opportunities a data-driven value-added service towards one of the actors already on board may not generate new revenues, but maybe more engagement in the platform! I hope after this MOOC it’s clear to you the link between data and platforms and that you can use Platform Thinking as a way to foster innovation starting from data.
