Let's do Science!
Introduction to Data Economy related research supporting data monetization
Design driven data Servitization process
Standardizing Data as a Service Value Chain to Maximise Data value and Monetization
Jarkko Moilanen (PhD)
My economics oriented 2nd Ph.D. research is focused on the design driven data productizement process, which binds together data products and data strategy in companies. It also includes data product family and lifecycle concepts. My intention is to define the productizement process and then pick spots in the process and do research and write articles on those. Of course I will not be able to cover whole process and the missing spots are limitations of the research and reserved for further research.
Data Monetization as the playground
Data monetization can be seen to include enhanced decision-making support through a better, more effective use of data; creating a unified understanding of data and a harmonised view of all relevant data; creating conditions for data-driven work and thereby becoming a digital company; increasing process efficiency; and building common objectives, benefit concepts and mindsets when dealing with data.
Focus on data products
Although all of the mentioned have value, focus in the research is in data products which are sold as commodities. Data product content is raw data or results of analysis process which might include AI or not. The content of data products is wrapped around with product element such as pricing plans, conditions, versioning, attractive name and description to mention a few. One of the fundamental aims is to define data product as accurately as possible. The added value is in the data which is packaged into easy to understand, buy and consume data products.
Data Product Toolkit
Data owners lack tools and skills to design data products. Furthermore, before data products can be built on top of a platform, those need to be designed. Platform might even offer testbed or simulation tools to test data products before production level publication. Thus, the results of the research are used into development of Data Product Toolkit, which offers canvases and other tools to design and manage data products, product lifecycle and product portfolios.
Data Products and Platforms
Data is increasingly not purchased as a batch or a dataset. Instead data consumer is purchasing access to data. One reason for this is the success story of subscription economy. We’ve seen this with Netflix and Spotify, but also in getting access to cars and other commodities instead of buying one. The purchased data product is stream of data which is either retrieved on customer request or pushed to customer upon changes in content. This resembles more a service than product in the pure format. More often “data product” is consumed via productized APIs. Consumers are not buying APIs. APIs provide modern access to discover, purchase and consume given data products.
Currently only scalable option to deliver data product content to consumers (apps) are APIs. Just as data has to be productized, also necessary APIs must be productized. Commonly data owners lack skills to productize APIs, market place to sell goods in. Thus we need a third party - platform, which will offer productized APIs to access productized data products with modern plans including subscription.
Below you'll find my planned articles to be written. I am more than happy to have coauthors since that enables more fluent authoring experience, multiple viewpoints, fresh ideas, fruitfull discussions and other benefits. I use Overleaf in the writing and that is not negotiable. Take a look at the article candidates and contact me if you want to participate in the research.
I am also publishing some of the results and materials as videos. In addition to that I will gather a curated list of academic materials for others to use. You can find those from Materials section.
Data as a Service Dominates
#1 Draw me a Data Product
What is a data product? How it has been discussed in the research literature (barely!). Data in raw format can be utilized internally with some effort. Situation changes when you want to sell data to others. Data must have clear pricing, solve a problem, offer value and ease of use. Data Product packages your data in the sellable format with business strategy fitting business plan. This is how I define data product at the moment. But what does the empiria have to say into this? Lets ask the people creating and consuming data products!
Do a semistructured interviews among Platform of Trust / other community and discover the common elements of data products in the heads of owners (5-10) and consumers (5-10). Compare the two aspects to find out similarities and differences. Benefits marketplace designers as well as data product designers.
California Management Review (jufo 2)
#2 Rapid Design Driven data product development
I will do 4-5 case workshops with companies with Data Product Toolkit. I will interview participants before and after the workshops about the process of developing data products. At the same time I will improve the Data Product Toolkit and release the next version of it. In the interviews I will focus on the process, not the usability of the toolkit. Amount of interviews is around 10-15. Based on the results I can draft common framework for data product development process. Hypothesis is that will be cyclic and contain multiple steps. Does it follow the classic double diamond model or not? What are the differences compared to design process of a common digital product or service such as an API or app. Do the product designers wish to have multiple designs to select from which to proceed with? What are the steps they take from 0 to product concept testing?
Information gathered in this research can be used in data product tools development. Those tools are now needed more and more.
Not known yet
#3 Emerging Data Economy is fueled by Productized data and APIs
The paper introduces theoretical model for data product concept. Data Economy requires productized data to succeed. Common model has been missing for data products and the discussion has dwelled around vague two sentence definitions. To utilize data products, well defined and productized APIs are more often needed. In the context of Platform of Trust, we have developed a data product concept in co-operation with other companies and cities entering data driven decision making and data economy as well as reuse of data. In addition, APIs required to manage and access data products have been developed and productized. In this paper we describe the data product concept and offer some first hand preliminary experiences. Introduced data product concept is in the heart of multi-city driven smart city development in Finland in couple of projects.
Draft, possibly a position paper?
Not known yet
#4 DATA as a service (developer) EXPERIENCE
Data is servitized more and more. Just like any service, data as a service also has experience - we call it data experience. I don't yet what it is, but the concept started to occupy my head lately. Current customers of data offerings are technically savvy data analysts and in that sense, we might define data experience from a developer perspective much like with APIs. On the other hand are the customers of data as a service just developer-ish people? Probably not. The rising low-code/no-code usage among business people might be the other customer segment to consider. How are these two different? How do the expectations overlap and differ?
Services are created for customers and sales. That applies to data as a service as well. Data Product toolkit (don't let the name fool you!) helps you to focus on defining the value proposition for your customer and think about who is the primary customer. You must have a target persona, a stereotypical customer for whom you are offering data as a service. That persona can initially be fictional, but later on, you should aim for data-driven customer personas.
80% of the customers are data scientists
Different data services might have a slightly different customer profile, but in 80% of the cases, the customer is a data scientist. Keep in mind that traditional application developers are data as a service consumers too as well as their managers. Thus your service-related material and communication must serve both technically savvy and business-oriented people. At the moment data scientists are the sweet spot as the customers for data services.
Data scientists are a new breed of analytical data expert who have the technical skills to solve complex problems – and the curiosity to explore what problems need to be solved. They're part mathematician, part computer scientist and part trend-spotter.
Support customer’s existing tool stack
This in something you should keep in mind while drafting data service offering plans. You need to support the stack consumers are already using. You need to choose which tools and environments your customer needs to support out of the box. Luckily Data Product Toolkit forces you to consider data output channels thoroughly.
If your data scientist customers are hard-core PowerBI users, then you must optimize data services for that platform. If they want to use your data in Unreal game engines in order to create XR applications for the industry, then make sure data service is found by the Unreal game engine users. You get the picture, right? You should not expect costumers to adapt new tools just to utilize your data services.
Supporting tools and platform used by the customers, reduces the friction to become your customer. It lowers also the barrier and learning curve. Keep in mind that not all customers want to fiddle with huge code stack, but prefer to use low-code or even no-code platforms. Keeping your eyes on the instant usage of data services is also building capabilities for the future needs.
Quick results with minimal code development
Application programming interfaces also known as APIs are common technical solution to offer access to data products. Even if the stereotypical customer is technologically talented, you should keep in mind that not all want to use APIs and write code to consume your data products. That is because they might not have time, they just need quickly build proof of concept or use existing graphical user interface driven platforms and frameworks. In those cases you need to consider nocode and lowcode platforms as the most likely usage environment for your data products.
Data as a service customer profile is changing
Future is changing the setting for data services too. To be able to use data services in own apps or environments in minutes without writing any code is becoming the winning feature. Why? Currently we are witnessing lack of developers around the world. Despite of the efforts like training more developers, the situation is not expected to get much better. We will have shortage of software developers in the future. The same is happening with the data scientists as well.
The remedy is to drop the barrier to use data by other people than just hard core developers or data scientist. We - the average business developers - are in the spotlight soon. We are expected to build simple apps and consume data services to create value internally and externally by increasing sales, customer experience and efficiency.
We business people must become “DIY data scientists”. We must be able to use ready-made tools and data services to create quick and dirty solutions for business needs. Thus no-code and low-code solutions are deemed to rise as is expected to happen on the more traditional application development where APIs now reign.
Business oriented segment becomes more important
As I mentioned in the beginning you have two personas among the customers - technically oriented developers and business oriented managers. Nowadays the developer persona is in the focus. It seems that in the future you might want to focus more on the managers since they are destined to be your data product consumers. The size of the markets is also bigger among the not-so-technical business people.
In progress. This is drafted and requires some more work on theoretical background and polishing. Overleaf link: https://www.overleaf.com/read/qycfwwjrttrj
Antti Loukiala and Timo Lehtonen
Not known yet