We all know that any organisation building digital products and services will collect data. We also know that just collecting data is not the same as actually using if effectively. Even if you have an amazing tracking plan in place, supported by a strong toolkit, your strategy will fail if you don't take the time to engage in one key thing: collaboration.
Analytics touch everyone in a data-led company
Think about building a new feature for your product. There are two main considerations at play here: what new data points will this feature bring in, and who are the audiences for those data points? Well, if you truly want to make data-driven decisions, more or less everyone will be an audience for your customer data.
The key stakeholders involved in analytics tracking will all bring their unique ideas and expertise to the story; a nice mixture of domain knowledge and technical know-how. We’ve got:
- Product managers
- Analysts / data teams
Each of these teams will have their own distinct tasks and goals, but ultimately they will be working from the same tracking plan.
☝️Tip: Having too many cooks can be a nightmare — have a read of this post to learn more about who should own the tracking plan.
How these teams (should) collaborate with each other on analytics.
Let's start with the team(s) who will want the most high-level view of events tracking. When building a new feature, the executive will care most about what the goals of this new feature are, and what metrics will be used to measure success.
That means teams working beneath the leadership need to be equipped to do some high quality reporting. A good leadership team won't want to make important decisions about the future of the company based on hunches — they'll want hard proof on what works and what doesn't.
Key collaborative behaviors of this team:
- Leadership should be working the hardest to inspire collaboration throughout the organisation, and fostering a culture that understands the value of data-driven decision making.
- Celebrate successes that were born out of making decisions based on data.
- Crudely, if your manager doesn’t care about good analytics tracking, then why should you?
Product managers know your product intimately, and how it sits in the market/industry. They are responsible for shipping this new feature, and as such will be looking to turn those metrics that the leadership care about, into actual events that they want tracked. In order to build reliable reports on this new feature, that event tracking needs to be built in from the beginning.
While a product manager is armed with a great deal of domain expertise, they may not have the technical skills needed to define the tracking plan themselves. This means they have to collaborate with other teams to get the job done. A good product manager is less likely to dictate a list of events they want tracked, and expect perfect reporting to result from that. Instead they might discuss and agree on what's possible with analysts and developers, as these are the teams that will be implementing the tracking plan, and building the reports.
So product managers will know what metrics are important, but may rely on others to turn those into trackable events. They will be instrumental in asking the right questions of the data, deciding when to A/B test, and creating appropriate feedback loops: looking at the performance of prior decisions, and iterating on those.
Key collaborative behaviors of this team:
- Regular check-ins with analysts: what events are being tracked and why, keeping everyone on the same page with taxonomies and naming conventions.
- And the same for developers: what changes to the tracking plan need implementing, if it’s infrastructurally possible, how long they need to do it.
- Making sure they feedback to leadership with high quality reports.
Your team of data analysts are like the company’s central hub for reporting. They are most likely the ones who get their hands on raw data first (possibly the only ones). They will work to join, model, and visualise the data. They help turn the data into insight.
☝️ An important note on the analyst team: they should not be seen as an organisational resource -- i.e. the ‘people to ask’ when you need something data related. If this is the case, analysts may find their capacity is taken up with fulfilling daily requests from other teams, as opposed to actually building insights and generating meaningful reports.
Part of the analyst’s collaborative process is to enable other teams to self-serve as much as possible. A basic example of this might be working with product managers and marketers to build predefined queries into a tool like Tableau, so that the questions that are asked the most can be answered at the click of a button.
Key collaborative behaviours of this team:
- Working with product managers to understand more about the people behind the data; they can work with abstract data all day, without knowing much about end users, but will be all the more effective if they have a greater understanding of why this data is important.
- Facilitating challenging conversations about what questions are most helpful to ask of the data, and what other teams want tracked (e.g. know when to push back if teams are asking to gather more data than is needed).
Of course, the developers are the ones that are actually building the product, and thus implementing your tracking plan. Technically speaking, a software engineer doesn’t have to know much about the industry you’re operating in, or about end user behaviour. This isn’t true across the board, and has led to the assumption that developers don’t care about analytics.
In actuality, an engineering team may struggle to get on board with analytics in a meaningful way if there is no systemised collaborative process in place. When building a new feature, receiving a spreadsheet of which events to track can be frustrating because it’s a huge disruption to workflow. Switching back and forth between an IDE, a spreadsheet, and a Jira ticket is cumbersome, and very easily leads to errors and inconsistencies.
Good developers are much more likely to care about how the products they build are performing -- they also know more than anyone how the product actually works, so are best equipped to implement the tracking plan in the most effective way.
Key collaborative behaviors of this team:
- Making sure product managers understand the limitations of their products’ infrastructure; when and where tracking is appropriate, and how long implementation might take.
- Working closely with analysts to build data and analytics pipelines, and making sure everything is going where it’s meant to go.
- Helping all other teams understand that to track events effectively, they need the time to build tracking into features right from the beginning, and not as an afterthought.
Fostering collaboration around analytics tracking
With this broad understanding of how teams can work together on analytics tracking, it's hopefully easier to start developing a collaborative process. It's quite clear that if everyone is working towards building and maintaining the same product, cross-team communication is going to be extremely important.
Start thinking about your analytics as a key design point in the backend of your product. It's not just something you tack-on once you've shipped a feature, but an integral part of the SDLC.
Many companies, especially in the tech industry, will already be comfortable with using collaboration and knowledge sharing tools like Jira, Slack, and of course, Iteratively. If you're passionate about adopting stronger collaborative processes in your organisation, we advise that you build your case to the willing. Getting buy-in for new processes is often the hardest part...
There's no need to reinvent the wheel; apply existing processes that already work
Quite often, adopting new processes (such as collaborating effectively on analytics) has almost nothing to do with technology and everything to do with culture. When it comes to analytics, knowledge will not exist in a single person or team — everyone needs to work together to get the most out of your data.
It's important to note that no one will adopt a new process (no matter how good it is) unless they see the point of it. Practically speaking, a great way to get company-wide buy-in on a new process is to demonstrate the value of that process, by comparing it to other pre-existing ones. A couple of examples:
GitHub: I don't think I'd be overstating anything if I said that practically every person/company/organisation that is building software, uses GitHub. It's a very elegant, but hard-coded, process: every piece of code written is subject to branch, commit, and merge. So Github is actually less like a tool and more like a process: it simply wouldn't work if everyone didn't use it.
Figma: a tool which perfectly demonstrates seamless cross-team collaboration; Figma enables product designers to hand off prototypes to developers with great clarity of how all the elements fit together.
Iteratively is here to help you collaborate
It’s useful to think of Iteratively as Github for your analytics. It facilitates a transparent, auditable process, that everyone can be involved in regardless of technical ability. It’s the first tool that allows product managers, data analysts and engineers to collaborate on data. The easy-to-use web app enables data analysts and product managers to define and evolve their tracking plan together without having to continuously refer back to spreadsheets and Jira tickets.
The best processes are the ones you don’t even notice: we have developer tooling so that no one’s workflow is disrupted, allowing engineers to easily and accurately implement analytics tracking with type-safe, open-source SDKs, a CLI and CI/CD integration.
Iteratively is first and foremost a collaborative tool -- it enforces a reliable source of truth for analytics, meaning those consuming the data know that they can trust it.
If you’ve achieved significant buy-in for new collaborative processes, Iteratively can certainly play a part in supporting that. Sign up or book a demo now.