Why Data Teams need Product Design

Product Design

Stan Dmitriev

Head of Prototype Team

In recent years, the data industry has been moving from data as an asset to data as a product thinking. This is definitely an important shift, and a great opportunity to make data initiatives truly linked to the company’s business goals. But as with all great ideas, they can flop, if done wrongly. Thankfully, product design thinking has existed for many decades and has well-defined fundamental steps and frameworks for creating valuable products.

Product, not tech, Design

The main challenge of product design thinking in the data environment is that before getting your hands dirty and actually working on technical implementation, the time has to be spent on truly evaluating and validating the idea. It requires investing time upfront, to avoid bigger mistakes in the future, and it requires leadership and constant involvement of all parties participating in the process. You have to start with people and conversations about the business use cases, rather than discussing the tech stack and how to create optimal data structures.

Companies tend to hope that tech can solve the challenges by itself, but the data about the data industry proves that this is just not true:

What we keep seeing is that data and business initiatives don’t go well hand in hand, and fixing it should be an important part of the company’s data stack.

So where do we start?

Here at Ellie, we’re building a product design and collaboration platform for data teams. It uses product design and data modeling techniques to help data teams create data products that can be used continuously across the organization – helping them succeed, spend less time, and make more efficient data stack choices.

These are the steps that we find most crucial when it comes to data product design:

Step 1. Start with a problem

The product design process usually starts with identifying a problem or a need and then iterating on different solutions for it. You need to have a clear and well-formulated description of the core problem that you’re trying to solve and what will be the measurable value of your end product.

Step 2. Test your idea

Once you have a well-defined problem, it might seem extremely exciting to just start building the solution for it. But instead, we first need to make sure that our initiative is feasible. We need to validate the idea in terms of business needs. This usually involves doing user interviews and trying to understand how big of a problem you are aiming to solve for the end-user. The goal here is to understand if the problem is big enough to dedicate time to it.

Step 3. Understand the user’s needs

Assuming that the product idea has passed the end-user screening, we now need to see how we could solve the problem in a way that our customers would be happy to use our product. To do so, we recommend using conceptual data models as they allow us to create a detailed scope of the data product needs from the end user’s perspective instead of jumping into the technical features and implementation.

Creating the models at this level and this stage of the process is fast and easy – catching inconsistencies and misunderstandings here is far cheaper than doing so after the product has entered the development phase.

Step 4. Linking product design and technical implementation

And that’s where the magic happens! You can now start working on the technical implementation of your data product based on the real-world needs and specifications of your data consumers. To do so, you can start creating logical data models, which are the actionable “data wireframes” of your product design.

Once your logical models are complete, you can further transform them into the physical data models of your design. The important part here is to always maintain a clear linkage between your different data modeling design blueprints. With Ellie, linking models is a straightforward task, and is one of the core features, ensuring that you know what your technical blueprint actually means in the business sense.

The benefits of continuous linkage between different types of data models are:

A clear understanding of how the product requirements relate to technical implementation
The data product that you end up making is what your customers would actually want to use.
Let’s you realize early in the process if a certain requirement is a technical blocker (potentially end the product development if it’s not feasible)
You maintain detailed documentation for the full product lifecycle

Step 5. Continuous product validation

Once created, data products are designed to continuously provide value, and to be improved throughout the whole lifecycle. For this purpose, we suggest you revisit your product once in a while and evaluate the core metrics behind it. It can be product usage and retention of your end-users, business value (for example increased/saved revenue, or increased efficiency), growing new requests for product improvement, etc. The goal here is to realistically evaluate your data initiative’s success.

As you have a well-defined product design both conceptually and technically, further development and improvement is a much more straightforward task, as you have a well-documented structure of how your product works both in the view of your end users and the tech stack.

Data Product Design is here

All in all, it is great to see the growing adoption of product thinking within the data industry, and the introduction of frameworks like data mesh, that heavily promote the product approach. Here at Ellie, we envision Product Design as the centerpiece in data initiatives and we encourage companies to strongly evaluate using it if they yet haven’t.

Over 40 enterprises use Ellie to create great data products and drive discussions through digital transformation. Interested in trying it out yourself? Schedule a free consultation call with one of our experts and get a free 30-day trial account.

‍