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
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.
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.
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.
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.