#68 How to manage data based offering portfolio?
In post #62 Practical start for data monetization strategy, I gave you an example of how to get started with a data monetization strategy. The result of that process is a set of data-driven products and services. In the presented model idea is to mock data commodities and form a portfolio of candidate products and services from the customer's point of view. One of the reasons to do that, is to form a credible plan on how to monetize data and use that set in getting the commitment from the management. You need the commitment since creating the data offering requires resources.
Now the questions that arise are:
Which one should I develop first?
What would be the order of implementing designed products and services?
Portfolio DATA COMMODITY MAPPING CANVAS
I created a small & simple tool that you might find useful in seeking answers to the above questions. It's a rather simple matrix with to axis. It is possible that this tool will be part of the Data Product Toolkit 2.0. which is coming out early next year.
The data commodity mapping canvas has two axis. On the horizontal line is Implementation push, which is divided into three segments: easy/low cost, relatively easy/mid cost and hard / costly. This axis is about how hard / cumbersome and costly the implementation will be. Most likely your CTO can give you a pretty accurate estimate. Of course there might the data product candidates which are both easy and also costly to implement. Supporting such options is something to consider in the next version of this minitool.
On the vertical axis is Market pull, which is also divided to three segments: 0-6 months, 6-12 months and 12-18 months. The market pull is the time when market is expected to be ready for the product / service. Some concepts and tech you might have can easily be too futuristic for the customers now and in those cases you should probably post pone the development a bit.
Now given that you have three candidates (the orange circles), we can see that candidate 3 is a low-hanging fruit since it's easy/cheap to implement and markets (customers) are expected to be ready for it. There probably is already market demand for it and possibly some competition.
The second (2) candidate is a bit harder to implement and/or the costs are higher. Also the customers are not expected to be ready for the service in the near future. This candidate might require maturing technology and thus the costs and risks are higher. In the design, it has been also noticed that this candidate requires number 3 to succeed. There is a dependency (grey arrow) between the commodities.
The number 1 candidate is something that has been considered to be quite far in the future and be costly/ hard to implement. Yet, if this one is considered to be the "killer" product, then you really need to consider when to start the implementation so that market entry is perfect.
The above example is simplified and hardly describes the complexity of reality. Even with the limitations, I have discovered it useful in putting the candidates in my portfolio in some priority order.