To build data culture, focus on outcomes

When most people think about data cultures, they imagine multi-screen dashboards with a dizzying array of charts and numbers. But this isn’t what a successful data culture looks like in practice. 

Simply using data to inform decisions won’t make you succeed at building a product or business any more than buying expensive ingredients will make you a world-class chef. In fact, there’s no correlation between the amount of data a company has and the strength of its data culture. I’ve seen large companies with millions of data points stored in a data warehouse struggle to understand this basic fact. 

A healthy data culture is one in which everyone is aligned on the outcomes you want to achieve and is clear about how to measure success.

This may sound obvious. But few product teams and companies truly focus on outcomes. As a result, many teams spend months—sometimes years—building the wrong features and products. 

Data is an antidote to waste and inefficiency. It’s a tool that companies can use to build better products and grow more quickly. But this is all true only when data is used properly. 

Building a data culture doesn’t mean training everyone on your team to write SQL code or constructing advanced dashboards.

Data comes in many different forms. One of the most common mistakes I see leaders make is assuming that data must be quantitative to be useful. Sometimes, the most effective data is qualitative. For example, as a B2B company, you might want to focus on user growth in a certain customer segment. Your goal could be as simple as landing more noteworthy customers for case studies in that segment. 

Thinking about outcomes like this is evidence of a data culture more than the type of data used to measure success. The result is a team that focuses on building products to achieve goals as opposed to building features or solutions for their own sake.

Often a leader’s hardest job is creating alignment on what outcomes are important in the first place. It’s one thing to measure outcomes and another thing entirely to choose and prioritize them. 

At Mixpanel, our leadership team frequently asks ourselves and our team members two questions: 

We’ve found that stating the outcomes we want to achieve is a force for aligning the company. Outcomes and data provide language to drive alignment.

These questions also prevent the type of irrational behavior that leads to wasted time. Every product leader I know has been a part of a long project that goes on for so long that everyone eventually forgets the initial goal. A situation like this is evidence of a lack of alignment. We avoid these scenarios at Mixpanel by constantly asking ourselves what outcomes we want to achieve. 

Once you know what outcomes you want to achieve, it’s important to communicate them frequently and transparently. 

Our leadership team presents slides from our board meetings to the entire company every quarter. This gives everyone visibility into the most important company-wide metrics and creates another opportunity to create alignment.

After board meetings, I frequently talk to my team to ensure that everyone is working towards outcomes that map to our larger company goals. For example, if the company is focusing on reaching more potential customers at the top of the funnel, I will ask managers and engineers how their work is helping grow awareness and reach. If their work is not contributing towards that goal, I’ll often ask them to prioritize other projects. 

Most goals are too big for a single person or team to achieve on their own. In order to create focus and set reasonable expectations, it’s often important to break big goals down into smaller goals. 

Recently, our growth team set a goal of improving our activation rate. After reviewing data and talking to users, we learned too many companies were struggling to connect their existing data sources to Mixpanel. 

It would have been unrealistic to ask a single product manager or team to solve this problem in one product sprint or a quarter. So we looked at how we could break down the goal and narrow our focus. 

First, we looked at all the ways that users connect data to Mixpanel. We learned that data warehouses like Snowflake, BigQuery, and Redshift were one of the most popular sources. We found that users who tried to connect these data sources had a lower connection rate than those who connected other sources. 

Then we tasked one of our teams with improving the connection rate amongst these users. Within a few weeks, we saw improvement. And that work even went on to help birth our Warehouse Connectors feature.

Data gets stale. What’s true today might not be true tomorrow. Behavior, patterns, and trends all have a tendency to change over time. These are the realities that product leaders must face today. 

For these reasons, every initiative and outcome should have a timebox of no more than three months. This doesn’t mean you have to stop working on a project at the end of three months. But it’s important to check in and confirm the outcome is still important and that none of your fundamental assumptions have changed.

One risk of this intense focus on outcomes—especially when they are communicated from the top—is that you create a rigid culture and stymie innovation. At Mixpanel, I’ve found that it’s helpful to have a simple process that allows teams to easily propose changes to a project. 

When someone proposes a change, we ask them to explain: 

This process creates a balance between strategic focus and agile flexibility. It also creates alignment between teams and creates a forum for conversations about goals, priorities, and strategy early on in a project. 

At most companies, product managers are the guardians of data and metrics. But this often creates problems of alignment and communication.

What we do at Mixpanel is have every engineer present their progress toward an outcome in a monthly data review meeting. Along with their data, they also add a green, yellow, or red flag indicating whether or not their work is moving the needle towards that outcome.

This might sound intimidating from outside the company. But it has helped us create a culture where we’ve normalized failure and experimentation. We don’t expect everyone to move the needle on everything they do. Sometimes, we take on projects that don’t have an impact. But creating a framework to communicate about this progress helps us fail fast and learn from our experiments.

Product leaders have no shortage of data at their disposal today. With a few clicks, you can easily fill up a data warehouse or dashboard with countless data points and metrics. But while data is abundant, time is not. 

Product teams must constantly choose what to build and where to focus their efforts. The reality is much of their effort gets wasted on the wrong projects. 

Data cultures are an antidote to this waste and a force for alignment. Building one starts with two simple questions: What is the outcome we’re trying to achieve? And how will we know when we’ve successfully achieved that outcome?