Where do you start if you want to build a data analytics function from the ground up? As an analytics leader at a startup, you will need to make several important decisions early on to build an effective team. This article dives into four decision areas and highlights ways in which to think about them:
- Team Structure & Skillset
- Foundational Processes
- Analytics Focus Areas
- Tools & Delivery
The important thing to remember at this early stage is that most, if not all, of your initial decisions will need to be revisited as the company grows and its analytics needs evolve. For the decision-making to be effective, it is important to be in lockstep with the company’s growth stage. For example, hiring a talented set of data scientists interested in deep learning before your company has aligned on its core metrics may not be the best use of resources early on (unless you are a deep learning startup, of course!).
Team structure & skillset
Centralized structure
This decision is relatively straightforward, especially if you are starting from zero and need to hire your first few data analysts. Your first few hires will need to wear several hats, support multiple teams, and set up foundational processes and reports for the entire company. Given these requirements and the broad nature of the analytics role at this stage, a centralized team structure tends to work well.
This structure allows you to ensure that the few resources available are being utilized completely and in the most impactful areas. A central structure also efficiently establishes best practices and defines core company metrics.
The appropriate team structure is definitely a decision that should be revisited over time and contextualized to the company size and stakeholder needs at different growth stages. Often, analytics teams will begin as a centralized unit and transition to a decentralized or hybrid model as additional specialization and dedicated support are required.
Broad analytics skillset
Your first few hires, as mentioned above, will be working on a wide variety of projects across domains. At this stage, you are not only interviewing for technical expertise but also for folks who are truly excited about building something from the ground up and passionate about the startup’s mission. As cliche as it might sound, they should be extremely comfortable dealing with ambiguity and adapting to changing requirements.
From a technical perspective, you will often look for candidates with a broad analytics skillset across tools and techniques versus specialists in any area. Assuming your startup already has a data engineering team that has set up the data infrastructure, you are looking for data analysts who can leverage the company’s data to generate insights and guide decision-making. You will need candidates with exceptional SQL skills and the ability to communicate and present data in a simple manner to your stakeholders. Experience with Python (or R) would be a bonus and help with automation.
A common trap when hiring early team members is overemphasizing candidates’ expertise in several technical areas while undervaluing their enthusiasm for the startup. Suppose the candidate is genuinely passionate about the company’s mission and excited about the prospect of building something new. In that case, it is worth giving them a shot, even if there is a certain technical area that they need to ramp up on.
Processes
Context is key
It is important to understand how evolved the data culture at your organization is. Are you truly data-driven, or is that just a buzzword in investor presentations? How data savvy are your stakeholders? How often are you or your team being asked to share data to assist with decision-making? The answers to these questions will help you decide what is and isn’t required from a process standpoint at any stage.
When setting up your analytics team, you can think of the processes you need to have in place from an external stakeholder perspective and an internal team standpoint. At this stage, balancing processes with the ability to move fast and iterate is crucial. Processes should only be added in places with a glaring need for them.
Don’t rush the intake process
If your stakeholders are not comfortable using data and metrics to guide their decisions, then your team goal should be to help them get there. Your choice of processes should reflect this goal. For example, instead of implementing a formal and rigid intake process where you ask all your stakeholders to fill out a detailed form to make a request, you should encourage them to reach out through whatever medium is easiest for them. It could be a simple Slack message, an email, or a casual in-person conversation.
At this stage, the role of you and your team should truly be of a coach and partner. Once you get a data request, work with your stakeholders to refine it and guide them on what data they should and shouldn’t be looking at to accomplish their end goal. Adding additional processes at the intake stage too early will only discourage outreach and be counterproductive in the long run.
Internally, however, the analytics team should maintain extensive documentation of each incoming ask. You should keep track of items such as the objective of each request, the requesting team, the SQL/Python code used to complete the request, and finally, a link to the deliverable shared. Access to this type of information can be a game-changer as the team and company grow. It will be useful to guide decisions across hiring and team structure, automation opportunities, and also for data analysts to share information and best practices quickly.
Serve before Self-Serve
An often overused phrase in the analytics community is “self-serve.” Self-serve refers to stakeholders accessing data and insights on their own through dashboards and tools, usually created by an analytics or BI team. Self-serve makes a lot of sense in organizations where teams are already data savvy and have developed sound intuition in interpreting and acting on data trends. A major advantage of self-serve is it frees up bandwidth for the analytics team to work on other important tasks. However, as with the intake process described above, how much to rely on self-serve will depend on your company’s context and its stakeholders. It is important to ensure that the analytics team is not using self-serve as a proxy for “I don’t have time for this; figure it out yourself.”
If you believe your stakeholders are not quite ready for self-serve, work your way up to it. Spend time educating them on interpreting the information you share and why it is important. Your first few reports may be automated emails pushed directly to their inboxes, removing all access barriers. The next set may be static reports available on Google Sheets. Once your stakeholders have built the habit of regularly accessing data for decision-making, you can finally begin implementing a more self-serve system with interactive dashboards using Tableau, Looker, or other similar tools.
Focus Areas
At most startups, you will be pulled in a hundred different directions, all seemingly important. While much of your time at this stage will be spent servicing the need of the hour, it will be equally important to carve out time to build foundational reports and establish baseline understanding across core business areas.
Key metrics
An important first step will be to ensure that your stakeholders are aligned on the definitions of key business metrics. Even if certain definitions seem obvious, it is worth discussing them as a group to avoid confusion later.
Once the definitions are established, you can develop one of your first few reports – a daily high-level view of key business metrics. This should not be a laundry list of every metric you are or will be tracking, but the handful that leadership and other stakeholders should have a pulse on constantly.
These metrics will vary based on company, business model, and industry, but here is an example of the metrics an audio streaming consumer app would track in such a report:
- Daily Active Users (New/Existing): the number of unique customers performing a certain action, such as visiting the app or playing a song, on a given day. The action(s) leading to a customer being counted as a DAU should be discussed in the definitions stage.
- Daily Streams: the number of song plays lasting over 30 seconds.
- Streams per DAU: the number of song plays per unique customer per day – this measures your daily customers’ engagement.
- Paid Subscribers (New/Existing) – the number of unique customers with an active paid subscription on a given day.
The first version of this foundational report may only contain information on the four key metrics above, shared in a daily email. With time, you can continue to iterate and get more granular, but having this single source of truth early will drive alignment and understanding of core metrics.
Understanding the customer journey
Almost all analytics tasks, directly or indirectly, tie back to a stage in the customer journey. For example, the asks from the marketing team are likely to be acquisition or reactivation-focused, while product may be looking for support across engagement or monetization initiatives.
The teams at a young startup may not be organized by these stages. However, it is still valuable for an analytics leader to begin developing insights for the company across this journey. Without a conscious effort to build this holistic understanding, you risk placing too much or too little emphasis on a specific focus area.
Continuing with our streaming app example, here are the types of questions you would begin to explore for each stage:
Acquisition
- How many new customers use our app daily/weekly/monthly?
- How are these customers finding our product? (Acquisition Source(s))
- Are we paying to acquire new customers? If so, how much? (CAC)
- How much monetary value do we generate from our customers (LTV), and how does this compare to our CAC?
Onboarding
- How well are we able to onboard new customers?
- What is the drop-off at each step of the onboarding funnel?
Activation
- The first and more challenging step here is to come up with a definition for activation. Answering the following questions will help:
- What actions do we want new customers to take on our product that will lead to a higher chance of them being retained?
- When do we want them to take these actions?
- Activation definition example: “Stream five songs within the first two sessions.”
- What percentage of new customers are we able to activate?
Engagement & Retention
- How much and how often are our users engaging with the product? (Streams per DAU, DAU/MAU, L7, L28)
- How well do we retain our customers? (Retention curves by acquisition cohorts)
- Which features are our customers engaging with and returning to most often?
Monetization
- How many paid subscribers do we have?
- How many free trial customers do we have?
- What is the free to free trial and free trial to paid conversion rate?
- What is our paid subscriber renewal rate?
Reactivation
- How many dormant customers do we have, i.e., customers who have used our product at some point in the past but have not used it in the last 7/30/60 days?
- How many customers do we reactivate in a given period? These customers were previously dormant but are now using the product again.
Customer Growth
- This is not a specific stage but depends on performance across each stage described above.
- You will want to build a detailed understanding of growth accounting, especially at a startup.
- Levers that determine growth (or reduction) in monthly customers include:
- New customers acquired this month (+)
- Reactivated customers who were dormant last month but active this month (+)
- Churned customers who were active last month but dormant this month (-)
Tools & delivery
Similar to processes, the decision around what tools to use can be broken out by tools that are internal to the analytics team, and tools that are used to share data and insight with external stakeholders. However, a guiding principle applicable across both categories is not to treat any tool as an end product or give it more importance than it deserves. Of course, you want to ensure that the tools you are using are appropriate and make your life easier, but it is important to remember that they are simply a means to an end.
The decision of what internal tools to use will be based on various factors such as team expertise, functionality provided, pricing, and budget. The tools you are using shouldn’t be set in stone and should be iterated on as needed.
For your external stakeholders, the tools used to communicate data and insights are less important than the format and delivery of that information. This applies not only to analytics teams at early-stage startups but also to more mature organizations. When sharing analyses and insights with your stakeholders, the emphasis should be on highlighting the most important takeaways in the most straightforward manner possible.
A few actionable data-driven bullets via a Slack message can have a much greater impact on your company than a hard-to-follow data dump in a CSV file. The data dump will be equally ineffective whether in a Google Sheet, Jupyter Notebook, or Tableau Workbook. Similarly, the simple and actionable bullets will be impactful regardless of whether they are read on Slack, in an email, or on a Google Doc.
Summary
In a fast-paced startup environment, building an analytics team from the ground up requires a thoughtful approach across four key areas:
Team Structure & Skillset: Start with a centralized team and hire adaptable data analysts passionate about your mission.
Processes: Context is critical when establishing processes. Align them with your organization’s data culture and encourage stakeholder interaction rather than rushing into formalities. Internally, maintain detailed documentation for future growth and efficiency.
Focus Areas: Prioritize key metrics and align on their definitions early. Follow a systematic approach to building knowledge across the customer journey, addressing acquisition, onboarding, activation, engagement, retention, monetization, and reactivation.
Tools & Delivery: Remember that tools are a means to an end. Focus on delivering insights to stakeholders in a format that resonates with them, regardless of the underlying platform.
