How to be the go-to engineer for product analytics

Engineers are always looking for ways to differentiate themselves. Not only can niche expertise lock down employability, but it can also catapult one’s career in entirely unforeseen ways.

One of those niches that’s become more valuable in recent years: product analytics. As data-driven product development continues to balloon in popularity, so does the need for accurate and sophisticated implementation of analytics tracking in software products.

Here are four ways you can position yourself as the go-to engineer for everything product analytics—and simultaneously make yourself invaluable to both the product and engineering teams.

From the perspective of many engineering teams, product analytics is treated as a second-class citizen. Every sprint planning, stories are prioritized, while the analytics implementation can be seen as an added step on top of the “real” priorities: the feature implementations themselves.

And this pattern creates lots of problems—both for the engineering team and the product itself.

But what if you could save everyone from this insidious peril? You’d be celebrated.

Consider a mobile app with a sloppy analytics implementation. All over the code, you have ugly calls to complex analytics APIs littered amongst your views and business logic. The obvious downside is that the sheer complexity increases the likelihood of bugs in the data you collect, which ultimately leads to a weaker product and an unhappy product team. But it also leads the features themselves to be buggy while universally frustrating engineers, because sloppy code makes everything harder to work with and understand.

More often than not, nobody leans into this problem, so everyone is trapped in an ongoing suffer fest. But the reality is that there are techniques for making your analytics implementation almost unnoticeable and very lean and clear in the few cases it appears in your core app code. Here’s just one example in a SwiftUI app.

If you make it a point to learn these techniques, advocate for them to your team, and take the lead in implementing them, you will be personally responsible for materially increasing the productivity of the entire engineering team that touches the relevant code while also indirectly (but noticeably) contributing to product success. And you’ll likely turn into the person on your team who can be called an expert on this topic, making your role invaluable.

Even if you haven’t yet found the time to refactor the analytics implementation overall, you’re still in a position to make an impact by spotting and fixing implementation bugs that can distort analytics data—and which only an engineer is in a position to see.

For example, a Signup event might be tracked in a place in the code that seems obvious at first but actually ignores an entire class of situations where signups might also occur. As such, signup events that are tracked could be off by as much as 70%, 50%, or—even worse—a significant but smaller percentage that might go entirely unnoticed by the product team and lead to continuously distorted data. On top of that, events could be duplicated if called in the wrong place, and events could be periodically skipped. You can find many more examples here.

The point is that some of these might be catchable by non-technical team members whose job it is to analyze the data, but a lot of cases could only ever be noticed by someone who understands how the implementation actually works on a technical level: an engineer like yourself.

You can tackle this problem by educating yourself on all the ways an event tracking call might be implemented incorrectly and thinking through ways in which these cases could be systematically tested. Once your understanding is solid, you can implement automated tests and/or educate your QA team with processes for testing, while also periodically reviewing code yourself.

And when you notice bugs, promptly informing the appropriate product team members can save the whole company from product missteps based on misinformation. You may be the bearer of bad news, but you’ll simultaneously be the savior from the consequences of sneaky bugs, which, despite all our best attempts, are simply a fact of life of building software products.

Speaking of communicating with the product team, you should also make it a point to periodically update relevant parties about changes made in underlying frameworks and implementation details that may impact the integrity of analytics event tracking.

For example, the team may choose to refactor some or all of the backend from using a monolithic architecture to microservices. As such, a variety of event tracking calls may need to be re-implemented in the new environment and may or may not yield the same results as the prior implementation for a variety of reasons. If the product team knows something has changed (and on roughly which date), they can keep their eyes peeled for anomalies and catch problems sooner than later.

Likewise, you may choose to use SwiftUI to implement a new feature in your iOS app where all prior features had been implemented in UIKit. While both SwiftUI and UIKit have their own opportunities for issues when it comes to analytics, SwiftUI’s quirks are different than UIKit’s. The last thing you want is to introduce a new feature along with framework-specific bugs and have your product team conclude the issue is the feature rather than the implementation details. To avoid this, you might proactively let someone on the product team know about the change and set up a meeting for a future date. In this meeting, you could review the tracked data together to see if anything out of the ordinary can be explained by the technical change compared with their view on what the product team already expects to see.

The more you understand the deep reasons behind why a specific set of events, funnels, or metrics are tracked by the product team, the more accurately you will be able to implement their vision.

It’s no secret at this point that great products cannot be created without both excellent design and strong implementation. In other words, even if the design is phenomenal, the UX will suffer if the implementation is weak. Likewise, even if the implementation is elegant and iron-clad, the UX will suffer is the design is weak. You can’t have one without the other.

The same concept applies to the analytics piece of the puzzle. Someone on the product team can have an incredible vision for analytics tracking, but if it’s not understood with sufficient nuance by the person implementing that vision, the resultant data is going to be of limited use or even counterproductive. Even if the implementation is technically “bug-free,” it still might not quite meet all of the product goals in undetectable ways.

But if you understand the business reasons behind an event you’re trying to track, and you understand the big-picture goals that are going to be informed by the data, then you will likely end up the preferred liaison for all conversations about analytics between product and engineering. Product people will enjoy talking to you since they will see you meaningfully understand their needs and interests, and you will be uniquely positioned to deliver on the goals of the whole analytics enterprise.

Besides, I’ve interviewed hundreds of software engineers, and a surprisingly small percentage of them actually understand the product perspective with any real nuance. Not only that, most don’t really care to learn. Their interest lies exclusively in technical mastery. And there’s nothing inherently wrong with that. It just means there’s massive opportunity for you—if you’re interested.

The product analytics market is expected to reach over $25 billion in the coming years, so this is not a specialty that is going to fade into the background anytime soon. And just as data-focused roles have been prioritized and carved out as full-time roles in and of themselves, product analytics engineering could easily become as highly sought. Right now, any company with a software product that has any chance of succeeding knows product analytics is a critical piece of the puzzle. The more you become an expert on the nuances, the more you can advocate, and the more you will find yourself in critical discussions that bridge the interests of teams beyond engineering.

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.