How to get engineering buy-in (and even excitement) on product analytics

At most companies, software engineers are in a constant state of rushing to get features and bug fixes out the door. So they tend to lack enthusiasm for anything that adds ongoing work to their plates.

This means product analytics can be seen as a burdensome afterthought for a lot of engineers—one that just adds more grind to an already packed schedule.

But the truth is your product is given its best shot when product analytics is treated as a priority, and that’s a great overall reason why engineers should be bought in. Here are some ways product teams can help facilitate that buy-in from engineers—and maybe even gin up some genuine excitement.

As I explain here, product analytics should be implemented alongside the development of new features in every single sprint (as opposed to all at once in a maintenance sprint after feature development is complete).

But in order for that strategy to work, you can’t just pile on the analytics implementation without sufficiently reducing the scope of features planned for a particular sprint.

There needs to be ample time to implement the analytics accurately and thoroughly. If you don’t plan for it, you’re guaranteed to generate resentment from the engineering team and get half-baked results that will only make it harder for the product to reach its goals.

The solution is to make analytics a first-class citizen in your sprint plans. Implementing analytics can take anywhere between 10% and 25% of your engineering time depending on the complexity (and volume) of the metrics being tracked. As such, for every feature, you need to allow the right wiggle room and deprioritize features (or specific feature requirements) in a given sprint if the added wiggle room pushes your sprint goals over the line of reasonability.

If you do that, not only will your engineers not resist, they may eventually applaud you for prioritizing analytics because it’s going to give them a better sense of product goals just by being forced to think about the metrics.

The other point of tension engineers tend to have when implementing product analytics is the specific way they’re integrated into a codebase.

That is, when engineers implement analytics tracking without laying sufficient architectural foundations, the result tends to be a codebase that’s littered with calls to an analytics framework in a way that creates a mess and obfuscates business logic.

That means engineers get more easily frustrated by the code. They get more easily confused. Every task becomes harder because they have to sift through additional clutter. More time is wasted fighting the code, and more deadlines are missed.

And let’s not forget the most insidious side effect: more bugs.

However, if you begin your foray into product analytics by allowing your engineering team to dedicate a sprint or so to elegantly integrate one or more analytics frameworks into the codebase, every single one of these negative side effects can be avoided.

As a result, adding analytics in each following feature sprint becomes way less complicated. Engineers see it more as a simple necessity that adds value rather than a project in itself. And that means the time it takes in each sprint to add new events and metrics gets much closer to the lower end of 10% of engineering time (or even less if the tracking is simple).

An analytics event should only be tracked if it adds meaningful insight to your product strategy.

What you should never do is attempt to track every event and version of an event that is technically possible to track in case you need it down the line. Not only will doing so make it harder for the product team to make sense of the analytics tracked, but it will also make your engineers’ lives a nightmare.

Every additional event you choose to track will likely become work for one or more engineers. To track it correctly, they’ll need to understand the reason it’s being tracked and the nuances of what’s being measured. After that, they’ll need to strategize about the best approach to implementing it and potentially coordinate with multiple engineers to get the job done.

The more events and metrics you choose to track, the higher the percentage of engineering time that’s spent on analytics vs. feature development. And if you haven’t yet taken the time to properly prioritize analytics in your sprints, you’re making your engineering team a pressure cooker of discontent and subpar results.

Engineering is a fundamentally technical skill set, so engineers tend to have pretty technical interests.

One such technical interest (common amongst most engineers) is data. They love it. They like parsing it and arguing about it. And they especially like tracking outcomes from it.

As such, product analytics happens to be a natural fit for their interests, particularly since it constitutes data that drives what they end up doing at work every day.

The problem for most companies is that they miss the opportunity to get their engineers properly enthused about this data by not looping them into the larger picture of why the events they’re helping collect are impactful.

That is, if your engineers aren’t privy to the deeper “why” behind your product analytics, the data that comes out of it is a less exciting or altogether less interesting proposition.

But if you make it a priority to be transparent about the strategy behind every metric and how it leads to greater success for the company as a whole (including the engineering team), enthusiasm drives itself. Suddenly a bunch of empty metrics and numbers are imbued with meaning that a technical mind can enjoy parsing, which in turn leads to more thoughtful implementations and proactive partnership (rather than resistance) on behalf of your engineers.

A great way to do this is by including a data segment in all-hands meetings or adding a walkthrough of your data analysis dashboards to periodic stand-ups between product and engineering.

On top of providing transparency, there is no better way to garner enthusiasm from engineers than to help them use product analytics to do their jobs more effectively.

You see, product analytics isn’t just beneficial to gleaning product insights. It can also help engineers notice bugs or performance problems by staying on top of user behavior. If engineering is provided ongoing access to analytics dashboards (just like the product team), they now have the opportunity to interpret changes in user behavior from a technical lens rather than just a product lens.

For example, an engineer might consider a sudden drop in usage for a particular feature as not simply a loss of interest, but a reason to investigate the existence of new bugs or performance hurdles. On one hand, the drop in engagement might be the result of the feature being no longer readily accessible due to it being inadvertently hidden by a recently added feature. On the other hand, the performance of the feature might have been reduced so significantly that users simply stopped engaging.

The point: Product analytics is ammunition for engineering interests. And the more they engage with and feel like owners in both the implementation and analysis of these analytics, the more likely they are to yield high-value data for all involved. From the perspective of engineers, the data not only justifies efforts to fix bugs, but it can provide a business case to reduce technical debt or fine-tune performance—two priorities engineering teams care deeply about but struggle to get added to their sprint plans.

Joseph is the founder of App Boss, a knowledge source for idea people (with little or no tech background) to turn their apps into viable businesses. He’s been developing apps for almost as long as the App Store has existed—wearing every hat from full-time engineer to product manager, UX designer, founder, content creator, and technical co-founder. He’s also given technical interviews to 1,400 software engineers who have gone on to accept roles at Apple, Dropbox, Yelp, and other major Bay Area firms.