All Posts

The Notion of “Data-Driven Products” Isn’t New. But You Need a Strategy.

Not all “data-driven insights” are valuable to pursue for the sake of your product vision. But which data is valuable for your product and business goals and which can you leave behind?

First, it’s the quality of data that matters—not just the quantity. Quality data that precisely matches your business case isn’t going to be free. No matter the licensing terms, collection method, and format, expect to put time and effort into evaluating, cleaning and curating it, especially if you aren’t paying for it.

Second, prudent decision-making and meaningful products are built on useful data, not just any data. If you put in the time and effort to curate, collect, and visualize your data, but you’re not using the insights to efficiently strategize at every stage of your product development cycle, then your efforts to build essential data products are in vain.

Many organizations lack the infrastructure to sort through their data or they have gaps in data expertise altogether. This can lead to disjointed, one-off solutions that must be reinvented each time the product needs to shift or new features are added.

What your organization needs is a robust, flexible, and future-proof data product strategy to build meaningful experiences and successful outcomes for the lifecycle of your product.

Building a Successful Data Product Strategy

The way to make the most out of the data you have is by creating a sound data product strategy. By establishing standards and best practices for building data products across your organization, you can better understand and leverage your data to create products that are indispensable to your users.

1. Create a Structured Discovery Process

Perhaps you’ve been told by others in your organization that you have enough data to create a desired product. You may have even created a product requirements document with beautiful mockups about how you plan to use your data to build your ideal product.

Well, be prepared to revise it.

We’re (kind of) kidding. But in our experience, superficial assumptions early on can lead to a product vision that is either untenable or needs to be augmented to provide the desired experience.

To reduce the chance that your data product vision isn’t viable, you need a discovery process, wherein you ask some critical questions. At Stamen, we start with the foundation:

  • What are your product experience goals?
  • Who are your users and what are their goals?
  • Which features are supported by data?
  • What are your business objectives for this product?
  • How can we measure the success of the product? Its features? How often do we need to take this measure?

Next, we focus on the data itself:

  • What data do you have? Will it need to be updated in the future? If so, at what frequency?
  • Is this data open source? Is it from a single source or will it need to be combined with other datasets?
  • Can this data support desired features? If so, how?
  • Can this data support your business objectives? If so, how?
  • For data visualization in particular, how can you communicate insight from this data, outside of the numbers themselves?

The discovery process is a scrupulous yet necessary step to building successful data products. Without it, you may end up in a lengthy and costly development process that doesn’t actually yield a viable product. 

At Stamen, we tailor the discovery process to each individual project. Depending on scope and complexity, this could mean a days-to-week-long data safari to verify a dataset is viable for our use cases or it could necessitate a more in-depth product and data analysis with user journey storyboarding, collaboratively building a product success spectrum, initial product wireframes, or ideation workshops with stakeholders to tease out hard-to-define requirements like software integrations or how to handle reporting product success metrics. 

All of these coordinated steps aim to get the most complete picture of the resources available, requirements those resources need to meet, and a clear scope of work. We find this allows our teams to enter the next phase of building a data product with the least amount of ambiguity and friction. Ideally, all of these findings are consolidated into a Discovery Report and shared with the team. This report should clearly highlight any outstanding decisions that need to be made, additional discovery that might be needed, and clear next steps in the process.

2. Establish an Iterative Prototyping Process

After the discovery phase, an iterative prototyping process keeps you honest about what’s possible with your product. By starting with simple prototypes and gradually adding design elements and functionality, you can ensure that you’re only working with products and features that have utility to your users.

And don’t forget your stakeholders, too. It’s critical to keep each decision-maker looped into your development process so that you continue to meet the organization’s needs and goals. We find putting prototypes in front of our clients as early as possible and with regular updates is a great way to drive this alignment.

Speaking from personal experience, I have used this ‘sandboxing’ approach many times in my career. Thinking back to one specific project, we had a client that needed us to test whether we could support search and wayfinding for a novel mapping application based on the available data, which they needed our help to source. Using aerial imagery, some basic building floorplans (.png and .jpeg), and incomplete / poorly geo-located business listings, we built a prototype that allowed us to demonstrate the gaps in resources and strategy. This otherwise useless prototype was far more powerful than a detailed data spec and a huge R&D budget, because it allowed everyone on the project to see what the priorities should be and what to address next.

We repeated this process through several product iterations, each time with more sophisticated data and tooling. With each prototype, each iteration, our team was able to quickly identify the steps, data (and data processing), or tools needed to get to the next milestone, all the while showing the efficacy of the work that came before. 

3. Know the Limitations of External Data 

In the above example, my teams had a crucial advantage: the capacity to create data in-house, or source from venue partners based on custom specifications. What happens when you don’t have that luxury? You have to look externally for the data you need.

External data can be a valuable resource — with some caveats. While open-source data options can fill in the gaps where your data falls short, it’s essential to understand the complexities and limitations of those external data sources to ensure it’s not more trouble than it’s worth.

For example, there is always going to be a certain amount of transposition or “cleaning up” required of external data. This is because the data very likely wasn’t created for your product’s specific use cases. The source it comes from made innumerable decisions about how to collect and use it before you came along. Therefore, it must be investigated, tested, and validated many times before you can adapt it for your use case.

Recently, while working on a project to visualize energy grids, we found an awesome 70k bus, simulated power grid from Texas A&M. While this data was available for free and superficially matched our use case perfectly, in fact it matters that we didn’t want to just measure these events, we wanted to visualize them. The result was that we spent a much larger amount of time tweaking this dataset to support our artistic interpretations. 

That’s a scope issue. The additional effort it takes to clean up and integrate an external data source into your product adds time and money that you may not have budgeted for in the development process. If you’re finding you’re spending more time on data scrubbing than the actual building of your product, it may be time to find alternative solutions to your data needs. Thankfully, you can get out ahead of these challenges with an appropriate discovery process.

Bridging the Chasm Between Your Available Data and Your Product Vision

Organizations can struggle to develop a strategy to build products or features from, or informed by, mountains of data. And there is often a gap between understanding the data available and knowing how to use it effectively for decision-making and product development. Partnering with a data visualization design studio provides the resources you need to gather, interpret, and make the most out of your data.

Published: 08.02.23
Updated: 08.02.23

About Stamen

Stamen is a globally recognized strategic design partner and one of the most established cartography and data visualization studios in the industry. For over two decades, Stamen has been helping industry giants, universities, and civic-minded organizations alike bring their ideas to life through designing and storytelling with data. We specialize in translating raw data into interactive visuals that inform, inspire and incite action. At the heart of this is our commitment to research and ensuring we understand the challenges we face. We embrace ambiguity, we thrive in data, and we exist to build tools that educate and inspire our audiences to act.