Building data products

I’ve spent the past decade building various products and tools within the healthcare data space. During this time, I have come to understand there is a fundamental difference between building non-data products and building data products. Although 90% of what I do as a product manager building data products is still the same as what any other product manager does, i.e., stakeholder management, communication, roadmapping and prioritization – not taking the remaining 10% difference seriously has caused me to fall flat on my face more than once. With the lessons I have learned, I hope I can help you avoid the same mistakes.

What are data products anyway?

First, let’s start with defining data products. My extremely simple definition is data products are products that would not be possible without the use of data. Data products exist within a decision-spectrum – from those that rely on getting all decisions from the user (e.g., collected, transformed, cleaned raw data) to those that make all decisions for the user (e.g., self-driving cars or automated drones). Inadvertently this decision-spectrum self-selects the end user of these data products (or the other way around). Those data products that are close to raw data or derived data might be best created for those end users who are able to make sense of the raw or derived data, i.e., technical users. And those data products that enable automated decision-making might be well suited for non-technical users who need not know anything about the underlying data nor the mechanics of how the product works. In designing these data products, as in any good product management, the problem space therefore needs to be defined in terms of the end user.

Five steps to building great data products

Step 1. Discovery

Like in any good product development process, the very first step in your data product development journey is discovery. Product managers will work with user experience (UX) researchers to talk to users or potential users to identify needs (pain) and wants (wow-factors). They abstract this into user personas and define user flows. For data products built to support decision-making through data exploration (viz. dashboards), though, this approach usually falls apart. This is because user flows or user journeys are typically deterministic. In building a data product, user journeys are probabilistic – you are building a product where you are trying to give people a greater understanding through data and not lead them down a specific path. Instead of thinking in terms of pains and wants, you should be thinking in terms of questions. Instead of building user flows that have a single direction and a clear purpose, you should be designing for something that allows for (infinite) branching.

One good way to do this is to tweak the traditional user stories that follow the structure “As a [user category] I want to [use your product] so that [I can get a job done]” into “As a [user category] I want to [ask a question] so that [I can get a job done]”, what I call question-based user stories. Starting with question-based user stories allow for discussions around what people want to do with the data and their motivations for wanting to find certain insights. Then each of these questions can be broken down into a feature list.

Step 2. Validation

Once you have a feature list, the second step is to come up with a minimum set of features to test and validate key assumptions. Validating key assumptions takes a very different meaning in data product development. In traditional product development process, this can be done using a crowdfunding campaign, a survey asking for feedback, a landing page, etc. While building data products; however, validating assumptions is less about asking for feedback. It means making sure you have the right data to build your data product. It means evaluating early how clean and complete your data is, identifying issues with the data and figuring out ways to mitigate them or making decisions to design around the shortcomings of your data. If you think after these steps your data still has a story worth telling, the next step in validating is to figure out the plumbing, i.e., how you get your data from source to your product. Think through data governance, technical capabilities (internal and external) and infrastructure needs. This exploration allows you to determine your minimal viable product (MVP).

Step 3. Design

You now have a set of ‘answers’ to your user’s questions (the MVP). These answers will not be exhaustive but for each question, they will be complete. Now it is time to design your data product. Traditional product developers might work with a UX designer to sketch-out a mockup or a wireframe. There is a strong tendency to do so in data products as well. Avoid it. Design with real data instead. Creating anything with dummy data can lead to two issues. First, you don’t know whether you can deliver the same things with the real data you have (see Step 2). And second, you are relying on your customer’s imagination to give value to the story you tell through dummy data. Once they know you are using dummy data, how much they actually value the story you tell them is questionable. Validate using real data that tell real stories.

Step 4: Implementation

This is where the rubber hits the road – and this is where the scrum team shines! In traditional product development, developers, engineers, and the product manager work together to actually build the product as designed and specified. In addition to this, in data product teams, you should be tracking your code using git, doing code reviews regularly, implementing automated testing and data pipeline orchestration. Alongside all of this – you should be documenting everything. All these steps help achieve what we consider a critical success factor in data science – reproducibility. The same code based on the same data following the same method should produce the same result. Just because you are building a data product does not mean you have to get super geeky about it. You are, after all, building it for the end user, not for yourself. So, keep things simple and intuitive. Get right to solving problems – users interact with your data product to get answers. Give them that and help them get to something tangible quickly.

Step 5. Launch

Now you have your data product ready – congratulations! How do you bring it out into the world? Product managers work with marketing, communications and commercial teams to get the word out, implement a go-to-market strategy, link up with the media, train their users, or do a launch campaign. For data products, you will likely do all of the above – however, you also want to ensure your data product fits right into your user’s work lifecycle. During Step 1 (discovery) you may have identified tools they already use during their work lifecycle. Think about how your product can seamlessly integrate with these. They are giving a webinar? Make sure there is chart export. They are using your data to make financial decisions? Make sure this plugs into their finance software. This is the beginning of your data product’s life – give it a great start by deliberately creating avenues within your product for users to provide feedback easily. This will help refine each iteration of your data product into something your users will trust and love!