Value based approach to data products
Recently you may be hearing a lot about data products and data product management. They typically imply use of machine learning or deep learning to solve a business or technical problem. However when you a take a value based approach, not all data products need to have advanced methodologies to enable a business action. The data products spread across a spectrum of how value is delivered.
What is a data product?
So, when you take a value based approach,
A data product is defined as a product that enables its user to make a business decision or commits a business transaction on behalf of its users using internal or external data or both.
There are two key factors in the above definition. Firstly, the outcome: enable vs commit. Secondly, the data: internal or external or both. These two factors define the complexity of the product. For example, its relatively easier to build a data product that provides an insight as opposed to a system that commits a finance transaction based on the insight provided. Similarly, its easier for us to build a product that relies on its own data as opposed to the one that relies on the data from another system in the organization or outside of the organization. Bringing an external data often comes with integration, format and quality issues.
Why value based definition?
For a data product, though the objective is to leverage data for business decisions and outcomes, the focus must not move from customer problem to building an awesome but ineffective or expensive data product. The value based approach will serve as a guardrail to our thought process and ensure that appropriate solution is provided to the customer problem using optimal resources.
Types of Data Products
Based on the value based approach we can classify the data products into two category, namely:
- Insights as a Service
- Decision as a Service
To better explain this lets have a quadrant based on the outcome and nature of data mentioned in the definition above. The outcome (Enable vs Commit) on the y axis and data (Internal or External) on the x-axis.
Insights as a Service
The bottom quadrants can be called as “Insights as a Service” data products that enable decisions. They do not focus on developing capabilities that automates decision but rather leave it to the customers. But it can learn from user behavior/ action on the past insights to improve itself. Best example of such data product is the recommendation engine that provides insights/ options based on your past purchases but does not order a new purchase.
Decision as a Service
The top two quadrants can be called as “Decision as a Service” data products that commit transactions. These products are the ones that makes decision on behalf of the user that provides efficiency and effectiveness. The best example of such products is the real-time fraud detection of credit card transactions. The product blocks a credit card transaction and blocks the card if it detects a possibility of fraud rather than wait for users to take actions.
Where do you start? …It depends!
It depends on whether the product is developed from scratch or is an add-on product that is built on top of an existing system and data. Assuming that the product is built from scratch its relatively easier to start at bottom left, ensuring that the key insights that enable decision making are captured. The decision to move to other quadrants must are subjective to many factors and must align with the overall product and organization roadmap.
However, any such decisions must make the product more efficient in solving customer problems or add more value to the entire business process.
Development of data products
Due to the experimental nature of model creation and optimization, MVP (minimum viable product) based approach will suit the data products. It helps the team understand more about the data and how customers react to the output of the product.
Last thing you want to have is an accurate model that does not serve your customers.
Irrespective of your position in the above quadrant, you can always start small and refine your product based on the feedback.
Example of an iterative data product development
For example, lets assume that a new data product is being developed to prioritize orders to be fulfilled on a daily basis.
Lets take two iterations that can take place in the first quadrant.
Iteration One:
The minimum viable product could be a place where users can see the number of priority orders remaining to be fulfilled and the list of actual orders. The users can decide which order they want to fulfill based on the nature of the order. The machine would then learn from the user selection to recommend and sort the lists in the future
Iteration Two
The second iteration can be an algorithm that recommends the user which order to be picked up based on multiple data points from the same system that generates and fulfill order but still let user take decision.
Assume that after multiple iterations, we have enabled decisions by providing insights based on the data available in the order management system. But we still cannot automate the decision of prioritization unless we have data from the shipping department that the user uses to take the final decision.
Iteration x — leveraging external data
This iteration will transition the data product from quadrant one to quadrant two. This means the data product still enables decision (“Insights as a Service”) and not commit transaction or action. The data product now predicts the time it takes to ship an order and uses it to enhance its recommendation to the user.
There can be multiple iterations here before the product transitions into the top right quadrant.
Iteration n — Commit action/ Take decision
This can be the iteration where the team has proved that the system’s prioritization has an acceptable level of accuracy. Now, the system will not provide the list of orders but pops-up orders, one at a time, for the user to fulfill. Here the product transitions to provide “decision as a service”.
The key take away is that a product can always remain as “Insights as a Service” and not transition to be “Decision as a Service”. The movement to the top-right quadrant is not a measure of success but solving customer problem is.
