View profile

Tools are not enough

Tools are not enough
By Arpit Choudhury • Issue #11 • View online
👋 Hey there, welcome to the Data-led newsletter! Subscribe here if you haven’t already.
In the previous issue, I had announced the relaunch of DLA that is now a place to discover data tools and technologies and get answers to questions about specific tools. 
I had also shared my guide on the Modern Data Stack for Growth. However, tools alone are not enough to build a stack. In this issue, I’m writing about the role of people and processes in building a data stack for growth.
Disclaimer: Data-led Academy is vendor-neutral and we don’t make any affiliate revenue or referral fee from data technology companies.

People
When looking to implement a data stack, most people typically go into an overdrive of vendor evaluation with the idea that the best tools will make all the difference. As someone obsessed with good software, I have been guilty of this too. 
However, while tools are important, the first thing to figure out is getting the right people on board followed by facilitating alignment and defining common goals. Doing so will enable you to work toward the goals without getting derailed once you have the tools and processes in place.
Gather your data champions
Implementing a robust data stack should have a company-wide impact and to make that happen, you need to identify the teams and stakeholders who will get to play with the tools and experience the benefits first-hand. Typically, these teams include Product, Growth, Revenue, Engineering, and to some extent, the Executive team.
In order to gather your champions from each of these teams, you need to define how some of their problems can be addressed with the help of the proposed data stack. 
Some common use cases of a data stack for growth are as follows:
  • Product teams, instead of just relying on their gut, are able to see which features are being used or not used, and how those features impact activation and retention
  • Growth teams, instead of building linear experiences, are able to run experiments to drive personalization and engagement 
  • Revenue teams, instead of flying blind, are able to identify conversion and expansion opportunities
  • Engineering teams, instead of realizing something went wrong only after the damage is done, are able to detect anomalies and act upon them swiftly
  • And Executive teams, instead of waiting for days or weeks, are able to get answers to their questions within a few hours or less
Once the problems and solutions are clearly documented, getting your champions to rally for you is rather easy. 
Align the champions 
Now that you have your champions on board, it’s time to get them aligned.
Every team has its priorities and goals, but with any new initiative involving stakeholders from multiple teams, it’s important to find common ground. 
Allow everybody to pitch in, organize their inputs into well-defined metrics, and prioritize the ones that can lead to quick wins.
You’d be surprised how often different sounding goals contribute to the same larger objective! 
In my experience and probably yours too, “product adoption” is something every team cares about, especially amongst SaaS companies.
Product and engineering want customers to use what they build, growth and revenue teams want to expand usage and attract new users, and needless to say, executive teams want everything
If product adoption is a common outcome amongst stakeholders, aligning them on the following can go a long way:
  • Key features 
  • Activation and retention metrics
  • Goals 
There’s very little that can go wrong and a whole lot that can go right once you’ve successfully got the champions aligned. Once the specifics are laid out and you have a clear picture of what data needs to be tracked, it’s time to move on to the next step.   
Tools + People + Process = Success with a data stack
Tools + People + Process = Success with a data stack
Process
You’ve assembled your dream team, facilitated alignment, and are ready to hit the ground running.
The first step is to define and document what data needs to be tracked, what it looks like, where it comes from, and where it goes. Not doing so is a recipe for failure, frustration, and fault-finding.
On the other hand, once everything is well-documented and agreed upon, implementation of tools also becomes a lot easier and even enjoyable for some. 
Documentation
Defining and documenting what data you need to track starts by creating a tracking plan, also referred to as an implementation spec. In its simplest form, it’s just a well-organized spreadsheet that you and your team can collaborate on
I went through all publicly available tracking plan templates and ended up creating an easy-to-understand, general-purpose template with clear instructions on how to use it. Additionally, there are best practices you must follow when building a tracking plan that I covered in my tracking plan guide (you can find both links under resources at the bottom).
It’s also worth mentioning that while building a tracking plan is a collaborative effort involving multiple teams, IMO, it should be owned by Product or Growth as they have the business context that should inform what data needs to be tracked and when. 
Implementation 
An important thing to keep in mind is that your tracking plan is the basis for your product analytics tool as well as other engagement tools that rely on customer data to enable personalization.
Therefore, it is crucial that the same events and properties flow into your analytics and engagement tools, and that is made possible when the same person or team is in charge of defining what to track and maintaining the tracking plan.
Implementation is generally owned by Engineering or Data (if there is a Data team). Product Ops is also fast becoming a function amongst mid-size companies with a need to consolidate the management of tooling and infrastructure under a tight-knit group that sits at the intersection of Product, Growth, Data, and Engineering
Irrespective of what you call the team that handles implementation, it is highly recommended to assign all tracking-related duties to a tracking manager — one who collaborates with various teams, gathers requirements, defines events and properties as per the agreed-upon taxonomy, as well as ensures that the tracked data is accurate across all the tools and systems.
If you’ve been through this process and have tips to share, send them my way and I’d love to share them in my tracking plan guide. 
Thanks for reading! 🙏
Resources to dig deeper
Progress on Data-led Academy
DLA has come a long way since it started as a side project and since many of you have shared your thoughts and feedback along the way, I’d like to keep you posted on the progress. 
👉 Any company building a product in the data space can create a company profile here – feel free to share the link if you know folks from companies that you’d like to see on DLA.
👉 The Answers repository is live and growing. Data practitioners can share their knowledge by providing answers to common questions they come across about the tools they’re experts at. Practitioners can get started here – feel free to share the link.
👉 We’re working on something new to connect data practitioners with companies that need help with projects with clearly defined deliverables like articles, video tutorials, or connectors, integrations, and open source packages
Interested practitioners can submit their info here whereas companies that have such requirements can schedule a chat to learn more.  
Forward this email to a friend or three and help us spread the word! 💗
Did you enjoy this issue?
Arpit Choudhury

A free newsletter by the founder of Data-led Academy sent almost twice a month for folks to keep pace with the data space!

If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue
Data-led Academy, Urbana NRI Complex, Kolkata, India