.png)
If you’re working at a developer tools startup, chances are your company really cares about making data-driven decisions, but doesn’t necessarily have the resources to make that data easily consumable by revenue teams.
Developer tool startups tend to face some unique barriers when it comes to arming revenue teams with data. Internally, these companies generally have an outsized engineering to business team ratio due to the nature of the products they are selling. This means that business teams need to work within a technical-first culture.
Externally, most developer tools startups employ a bottoms-up strategy that involves very low barriers to entry for a single developer. Developers can start using the product with just a personal email (or even anonymously), which does wonders for adoption, but definitely causes headaches for the revenue teams trying to figure out which contacts to sell to.
So what does this mean for revenue teams at early stage developer tool companies? In our experience, having worked at companies like Cockroach Labs and Timescale, it’s important to get your hands dirty early on and learn enough about the data stack to communicate your needs in a technical-first culture. In this post, we’ll provide a step-by-step guide on how to start making data-driven decisions at a developer tools startup. We’ll follow up with a post that covers the basic SQL queries that can get you started, so stay tuned!
Step 1: Survey your company’s data landscape and make sure you’re tracking what you need
If you have a product that’s being used by users, it’s highly likely that your company is already tracking usage data. Most companies we’ve worked with dump this data into a cloud data warehouse (think Redshift, BigQuery, Snowflake) or SQL database for future use. Data is typically stored in two formats: (1) event-based - which is essentially a table with columns for the timestamp when the event occurred, a description of the event, and any other additional information about the event itself, or (2) metadata - which is a table that includes information about a user that doesn’t change often. These two types of data are usually stored in two different tables - kind of like how you would store these two different types of data in different sheets in Excel.
Let’s run through an example of how this might work. You might have a table of “product events” which includes when a user logged in, clicked on a button in the UI, and logged out. You might also have another table that includes all users, including their email, their company name, and their title. Ultimately, our goal is to ask questions about how users are using the product to identify which users might represent good sales opportunities.
So how do we combine the data in the “product events” table with the user table? If you’ve ever used INDEX() or VLOOKUP() in Excel, you essentially need one column that helps you match rows between tables. This is essentially the “unique id” which is usually a string of random characters in the database. The “unique id” might also be a user’s email.
All this is to say, here are the key questions you need to ask your data team:
- Where is usage data stored today?
- Where is meta data about customers stored today?
- What is the unique id that ties those two data sets together?
One caveat is that across the companies we’ve worked with, most companies actually store metadata in Salesforce. Pulling data from Salesforce requires accessing their API, which requires knowing how to code. If your company stores data in Salesforce that you want to join with usage data, check us out here. We help revenue teams join usage data with Salesforce data with zero code on your part.
Step 2: Start exploring the data being stored in your cloud data warehouse or SQL database
It’s beyond the scope of this blog post to describe how to get connected to a data warehouse or SQL database, but this is something your engineering team can quickly show you. If you’re looking for a more visual interface to write your SQL queries, Mode Analytics is a good bet. We’ll dive in further in our next blog post with specific examples of the most commonly used SQL queries that will get you 80% of the way there. At a certain point, writing SQL shouldn’t be your core expertise - it should be selling product! For more complex use cases you’ll need to work with your engineering team directly or use a tool like Correlated.
Step 3: Choose 3 KPIs that matter to you the most
When you’re starting out with a data strategy, less is more. Avoid analysis paralysis by collecting and tracking everything, but only surfacing a handful of metrics that really move the business.
If your company is focused on growth, an important KPI could be total signups or installs. If your company is looking to drive adoption, a KPI could be the average time it takes for a user to sign up and use one advanced feature, or even something simpler like % of users this month who used an advanced feature.
If your company is looking to drive sales, conversion to paid is one of the most telling metrics to look at. Regardless, choose the 3 KPIs most important to you and go from there. That doesn’t mean you won’t be pulling data related to those KPIs, but it does restrict the surface area of what you might want to expose to your team in the next step.
Step 4: Expose data to the rest of your team
Although some companies try to train their entire business team to write SQL, that’s a tall order at startups where time is of the essence. Rather than requiring everyone on your business team to learn how to connect to a SQL database and write SQL themselves, you should consider exposing key metrics via 3rd party applications. Here are some options we’ve used or explored before for you to consider, with varying degrees of complexity.
Google Sheets is a surprisingly powerful tool for basic graphing, and we’ve used Google Sheets to cover some pretty complicated use cases. Databases almost always come with an export to CSV function, so writing a query in SQL to pull data out and exporting that data to CSV before importing it into Google Sheets, though time consuming, is a valid option.
Grafana, for all you OSS fans, is similarly a great tool for graphing event data. We’ve used it to explore total active users and feature usage. Although Grafana excels at real-time data exploration, it does have a higher learning curve for more “dashboard-like” views that involve aggregation. That being said, many engineers are familiar with Grafana, so they might already be using Grafana for their own monitoring use cases.
Mode Analytics is a more business-user friendly tool that allows you to build dashboards and query databases using SQL. They also have a lot of educational resources to get you started with SQL. That being said, it does require a higher level of technical competency from the user who is setting up dashboards.
Tableau and Looker are also popular options in the data visualization space, but most startups don’t move towards those options until they are more mature. Tableau and Looker tend to be more expensive, and unless your data needs have expanded, it’s likely unnecessary for you to expand to Tableau and Looker if you’re at an early stage developer tool startup.
Step 5: Define how you’ll make data-driven decisions
At the end of the day, the reason why we collect all this data is to make more informed decisions. Dashboards only go so far in actually driving data-driven decisions, since each team member who looks at the dashboard might interpret it differently, and the dashboard often lacks the context needed to act. Let’s take as an example a dashboard that almost every company has: new users over time. As a member of the sales team, seeing new users increase over time doesn’t help you figure out who to talk to. You might want to know what account each new user is associated with, or you might want to figure out which accounts have had a large increase in users. You can’t do any of that in a dashboard.
As a first step, doing things manually can be a stop gap. For example, each week, you might pull accounts with the most new users and have your sales or customer success teams reach out to the new users in those accounts. However, this ultimately becomes a huge burden on the team since each report needs to be pulled manually, and any adjustments require someone to go in and manually update whatever SQL queries they are using. There are a lot of cool vendors in the space making it easier to put data in the hands of business teams, including reverse ETL vendors like Census and Hightouch.
What’s Next
If you're tired of writing SQL and running manual reports that don't drive actions, reach out! We are helping sales teams at some of the leading developer tools and product led growth companies take action off of product usage data.
If you’re still writing SQL, we’re writing a follow-up post with the most important SQL queries you should know. We hope to see you there!
.jpg)
