Frontend Platform use case - Acting before a real Product need

This article is about what happens when you anticipate Platform activities before a real company need arises.

Photo by Trevor McKinnon on Unsplash

The problem

In the Hasura Console, Datadog was initially used to track some internal errors and alerts. Then, the plan was to move to Sentry and, in parallel, to Heap to allow the company to create funnels and track user activities to base future Product decisions on data. The company could opt for other tools in the future, obviously.

This changes in terms of tools and not having a unified direction about how to practically implement them in the Console UI (the main Hasura's front-end project) led to a lot of patterns used by different developers.

More: since Hasura treats very sensitive data (the env secrets and database details of the clients) it's crucial that this data are not leaked to third-party services.

The sensitive data problem and the data redaction applies specifically to how Hasura uses Heap, since by default Heap (and a lot of other similar tools) tracks everything the users do in the browser to allow later creating and analysing funnels. At the same time, the Console UI exposes some sensitive data (the database table names, for example) in some HTML attributes (some ids, some data-testids, etc.) that must not be shared with third-party services.

When Heap has been added to the Console UI, Heap auto-tracking has been disabled in favor of manually adding some dedicated HTML attributes (ex. data-heap) that then allow the stakeholders to create funnels like "the user clicked on the element that responds to the [data-heap='Save action'] selector". This is a great thing for engineers too, because knowing what the users do in the Console UI allows also to start discussions with stakeholders about "eventually removing some not-so-used features that force us to keep some not-so-maintained dependencies and some not-so-modern code".

This approach is safe from a data leak perspective, but does not scale from a feedback loop point of view. Due to the internal release management, normally no less than two weeks pass from a stakeholder saying "I'd like to track this button" and the new HTML attribute present in the Hasura products.

The solution

In the Platform team (I was one of the frontenders of the Platform team, along with N. Beaussart and N. Inchauspé) we decided to

1. Create some analytics-related React APIs to centralize adding the tracking HTML attributes and easily switch from a tracking tool to another one in the future without touching the whole codebase

2. Move the data redaction from the app-level to every single feature level, in order to simplify the work of every Feature team. Every Feature team then had to

   1. Analyse the data leaked by their own features in the HTML attributes
   2. Remove the data leak
   3. Remove the data-redaction from every single feature

As a result, the stakeholder could gain automatic tracking and focus on more interesting things like deciding if to expand tracking to other distributions (like on-prem) or not.

The first point was the easy part, the developers working on the Console easily adapted to use the new <Analytics/>, getAnalyticsAttributes, programmaticallyTraceError APIs etc.

The second point, instead, required a lot of refactors, dig into the features code (not something very easy in the Hasura Console), and a lot of manual tests to be sure no features are broken. But this is the kind of tasks for the Platform team, right? Especially if you think about unleashing the Feature teams' potential in terms of re-enabling the auto tracking, right? Well, not exactly...

Why it did not work

The work every Feature teams should have done (fixing leaking sensitive data and reenabling the auto tracking) requires time, and this time should be planned and prioritised. What happened is that I found myself pushing for this activity, the Head of Analytics pushing too... But the company had not a strong interest in prioritising everything analytics compared to other activities!

Not all the work is wasted! In fact, the the new React APIs are in use and they leave room for future evolutions. But the most impacting process, removing the block to auto-tracking, remained uncompleted despite the initial big effort from the Platform team.

Conclusion

I wanted to share this experience because it is the perfect example for when a Platform team does something not very coupled to the Product goals. This kind of problem could happen especially if the Platform team has not a Product Manager, something I spoke about in my Frontend Platform use case - Creating a roadmap without a Product Manager article.