When and how can I get started with data when launching a new service?

I was talking to a friend that I respect and admire who is starting a new payments service within a large enterprise. He knows that data is going to be important but does not know when to start thinking about designing data into the product itself. There are a lot of clarifying questions that would need to be answered first, but that got me thinking in general about what I would recommend to people starting a new product or service. When is it practical to start working with the data produced by the service (as opposed to using data as a part of the service delivery itself which is a different thing altogether)?

Here are a few thoughts about one way to look at this question–I hope it will be of some help to both start-up founders and transformation practitioners in large enterprises alike, thinking about when and how to get started with data in the product or service development process.

From many conversations with clients over the past twelve months, it seems that some people are thinking about the necessity for a data-hungry machine-learning (ML) model to give them insights about what customers are doing and why so they can act on it. Others go even further with the expectation that such a model has to be deployed to production (running on a live application), fed with real-time data from data pipelines.

Wait. Let’s back up a bit.

Neither of those is required and can prevent people from getting true knowledge about how (and how well) their service is working.

It’s often helpful to my clients to discuss the business problem that they are trying to solve. We also want to take the customer’s point of view as this is where we get into conversations about what provides the customer value. Customers are not all the same, so what provides value to one customer may differ from another. The same customer may have different use cases so considering them as a “persona” can also be too simplistic. The service may have bias embedded within its design and so does not serve customers in the way they want. Often, we can re-focus the service to work better for customers.

First takeaway: Where possible, fashion the problem into doing something that matters to customers. This sounds obvious but missing this point is common, especially if there is a prescriptive management mandate to do something a particular way.

Once we have a problem to solve, we want to take a look at what data we have. Data that helps us understanding how and how well a service works and what the customer expects is what we are looking to find first. Sometimes data scientists can start digging too deeply into Exploratory Data Analysis (EDA) before obtaining a more general understanding of what we would like to learn from the data. Establishing the context of data is crucial for understanding what it could be telling us about what we’re trying to solve.

For example, if we do not have any evidence about what matters to customers, we could be building the wrong service or incorporating the wrong steps. Maybe the data is suggesting that a customer with a certain profile is more likely to contact us with a problem when they order our product or use our service. This could then get people thinking about how to solve their problem more quickly or predict that it’s going to happen so we can address it quickly. Sounds great, but this thinking avoids contextual understanding on why the problem happened in the first place. In this example, were we to know why customers were contacting us we could re-design the service to dissolve problems before they occur (this could be picked up from Natural Language Processing on emails and chat logs from customers to see what goes wrong and why with the highest frequency.)

Second takeaway: Understanding context of the problem makes for better problem solving.

This sort of work can be done with readily available open-source tools such as R or Python. If we have someone that has the right mindset and coding skills, we can interpret and visualise the data to share with the team building the product or service (whether it’s purely digital or not, there is value in both cases). The team can learn what’s working and what’s not quickly, and test a re-design.

One does not (yet) need a team of engineers to create a central place for the data (such as a data warehouse) and feed it with data from “pipelines”, which require care in their design to prevent the need for large engineering teams just to maintain them. One could get quite far early on in the product or service development process by starting small with one data scientist teaming up with a business person and a software engineer–to discover data, ask good business questions, make a change in the product or service, and keep iterating from there.

Third takeaway: Starting early with “small data” and a data scientist can generate a lot of understanding quickly, leapfrogging some painful steps in getting to product-market-fit.

Focus is extremely important as there are hundreds of different ways to measure whether your service or product is getting the product-market-fit you need for growth–without costs of poor quality following revenues up in lockstep. For example, measuring overall CSAT (Customer Satisfaction) just gives us a relative value describing how customers liked their last encounter with the service. We still need measures that tell us how capable the business system was at doing whatever customers wanted. Was the customer’s use case fulfilled without having to call us for support? Did it get delivered on time? Was the service done right the first time? Again, context is king when selecting what to measure. Having a look at the variation of these sorts of measures over time is a huge benefit as well.

Fourth Takeaway: The more that we can predict about our service or product early on, the faster we can learn how to improve it.

This data-driven approach to getting started with building a new product or service is all possible right from the start. It does not require a huge team, large capex or operational budget outlays. It does not require massive amounts of data. It just requires a focus on purpose from the customer’s point of view, what matters to them, and then measuring how well the new service is doing what matters. Customer feedback data, event logs, and manually recorded observations are often enough to get started on being data-driven early.

The benefits are fewer missteps and less friction in the customer experience which reduces churn, improves the number of early fans and accelerates organic growth (reducing the need for big marketing budgets). With the right measures, this approach also helps builders quantify the effects of improvements to the service, putting more power in the hands of the people who are using, designing and re-designing the service.

- Jason Frank is the Managing Director of Re:Adapt Data Science who has a passion for re-thinking how we manage and leverage data to make better decisions.