Using data to achieve impact at scale | Mixpanel

Using data to achieve impact at scale

Data, while perhaps once reserved for scientists and academics, is essential for nearly every business function today—and is key for achieving positive impact at scale.

Susheel Daswani Director & Head of Engineering at Citi Ventures Studio

Since the beginning of my career as a software engineer, I’ve been energized by the idea of impacting people’s lives through great products. Though engineering teams eventually need sleep (yes, really), many of the products they interact with do not—the code we write has the potential to create an outsized impact on users for months and years to come.

Data, while perhaps once reserved for scientists and academics, is essential for nearly every business function today, and is key for achieving positive impact at scale. So, how can people who want to build great products (or ship great features) do so using data as their foundation? And how can companies drive impact in a way that’s not only data-informed, but also scalable and safe—for users, and for their business? 

It all comes down to the process, the tools, and the people.

The process

No matter the size, scope or maturity-level of your company, creating a strong foundation for data-informed growth can feel daunting. But in its simplest form, building products is about combining raw materials to create something new. For product engineering teams, these materials are: code, time, strategy, design and data. Breaking down the process into distinct steps helps us take stock of our assets, identify the cracks, and know when to call in reinforcements. 

When leading teams in building new products, the most successful ones I’ve been part of use the following framework:

  • Step 1: Understanding your customer. First, spend time collecting data from customers to gain insights into their existing habits, beliefs, and routines. Your goal during this early stage should be to step into the shoes of your customers; develop an intimate understanding of how they behave; and begin to conceptualize the kinds of products that will ultimately surprise and delight them—and feel like they’ve been missing them all along.
  • Step 2: Product ideation. Next, explore product features and interactions that use your most important raw materials, such as data and code, to provide customer value. What data do you have that’s useful to customers? How can you present data in a way that’s interesting? How can your code or choice of technology fulfill an unmet customer need?
  • Step 3: Validation with qualitative data. Without usage data from your product being in-market, you can’t rely on the law of large numbers to make decisions. You’ll need to validate your assumptions with qualitative user research, which will help you to better vet the ideas that came out of your work on building customer insights in Steps 1 and 2. This critical step will help you refine your product, model the business potential, and sometimes even prevent or mitigate a costly failure in the future.
  • Step 4: Measurement with quantitative data. Set Key Performance Indicators (KPIs) to track product success and guide future development, and build these measurements into your product engineering process. Go deeper than just tracking who’s clicking on what by layering this data with user feedback.
  • Step 5: Documentation. Just as the industry standard has advanced to mandate code reviews within engineering, build data reviews into your team’s process. You may get some resistance here. Resist back. I tell my engineers that every piece of data they collect must be reviewed as one would a piece of code (In fact, many companies I’ve worked with require it—from financial institutions like Citi Ventures to non-profits like Mozilla). This is especially important in business settings with the potential for liability or downside, though all companies should make data documentation and review part of their culture.

The tools

Direct feedback from users, while essential, can’t provide answers at scale. But deep qualitative analysis takes time, which—as we learned above—is one of the essential raw materials for building products. Here’s where high-level data analytics tooling comes in. 

In fact, the industry has progressed to the point that it’s become a competitive disadvantage not to have powerful data analytics tools (not to mention, building your own tooling can be extremely expensive and time-consuming).

You wouldn’t ask your engineers to go back to using Assembly when the industry standard is higher-level languages or frameworks like React, Kotlin, and Swift, would you?

When I first started my career at LimeWire, the only data we had was the number of downloads at We had no idea what users were doing within the product. But if the tools available now had existed back then, we would’ve loved to track all sorts of product metrics (e.g. DAU, MAU, daily time spent, churn). We’d probably track media consumption too (like Netflix does today) which could’ve helped us understand so much more about users—and very likely changed the trajectory of the company.

Today, powerful data tools and Software Development Kits (SDKs) can save companies valuable time, greatly reduce data bottlenecks, and supercharge product teams. My own team makes heavy use of features like live data views, filters and funnels—all of which provide efficiency, accuracy and trust. Plus, they can easily be accessed by the entire org chart, which democratizes data access and greatly enhances understanding amongst teams.  

Though everyone’s business is data these days, most engineers set out to build products, not data platforms. Whether they hold a computer science degree, or they attended a bootcamp, not all engineers are fluent in data science or data engineering. Good product leaders know the value of setting teams up for success at scale with the right data tools for the job.

The people

With the right process and tools in place, the ability to build a strong foundation for data-informed growth hinges on the people.

Although it all too often is, data should not be owned solely by the data team. Companies with a strong data muscle make it foundational to everyone—both on the input and output side—and democratize its access along the path to building great products. Data has a role to play on every team. While data scientists will help you understand what product functionality can be extrapolated from your data sets, engineers will build access to this data into your products. Designers will lend valuable insight into the way humans interact with your data, and product teams will uncover how best to deliver it to your customers.

In today’s landscape, conversations about data can’t happen without considerations of user privacy. Indeed, with regulations like CCPA (at the California state level) and GDPR (across Europe) coming onto the scene, we’re witnessing a seachange in how businesses must operate—from the largest commercial enterprise to the smallest startups. 

In the past, it might’ve been enough for people who build products to think only about how to get it on Google, AWS or Azure. But today, it’s essential to think about how products will service user requests to delete and expose data, and fulfill the demands of these new regulatory frameworks.

Don’t be caught unprepared when venture capitalists ask: “if data is your business, how are you going to handle these regulations?”

A first step that any company can take is making their privacy policy read like a values statement. During my time at Lookout, the Legal team turned ten pages of mumbo-jumbo into a single concise, easily digestible statement. I’m a firm believer that this kind of transparent practice will create a trickle-down effect that results in both better data choices and respect for user privacy within your product.

At the end of the day, data isn’t good or bad. It’s all about how you use it. If you’re anything like me, you build products to delight your users. Your use of data should ultimately delight them too.

About Susheel Daswani

Susheel Daswani is responsible for Citi Ventures Studio’s engineering team, where he empowers them to deliver on Studio’s product vision while helping individual engineers reach their professional development goals.  Susheel received his BA in Computer Science from New York University, graduating Phi Beta Kappa. He then received his MS in Computer Science from Stanford, where he focused on Distributed Systems. Finally, he received his JD from University of California, Berkeley, and was admitted to practice law in California.

LinkedIn | Twitter

Get the latest from Mixpanel
This field is required.