Lighter Tracking Library

Rebuilt the tracking library from validated requirements only, cutting the effort to add eventing to any new microservice.

↓
effort to add eventing to a new microservice
↑
library portability and compliance with current eventing rules
2
inventories mapped against each other: tracking needs and tracking functions

Phased rollout

Phase 0
Kickoff: legacy library too heavy, no clear ownership
Phase 1
Discovery: inventoried tracking needs and functions, mapped gaps
Phase 2
Ship v1: POC launched after technical evaluation of alternatives
Phase 2
Feedback: legacy library still required for some services
Next
Rolling out service by service with developer support

From heavy to light

Heavy legacy library

Inventory needs + functions

Gap mapped

Lighter, portable library

Two risks, and what happened

Risk	How it was handled	Result
Usability. A heavy, hard-to-implement tracking library was slowing down every team adding eventing to a new microservice.	Gathered engineer feedback on pain points. Validated every component against current requirements before deciding what to keep.	A library that's easy to use and fully compliant with current eventing rules.
Feasibility. A full rebuild or a targeted trim? Legacy pieces were tightly coupled.	Chose the rebuild. Ran working groups with engineers to evaluate technical alternatives, then launched a POC.	Shipped a lighter, portable, expandable library. Some services ran both libraries for a transition period.

My role. Owned the requirements validation, the roadmap, and the POC. Partnered with engineers directly through working groups to evaluate technical alternatives.

What went wrong. A secondary legacy library turned out to be just as heavy as the one being replaced, with undocumented use cases. Not ideal, but manageable.

Product leader with a data scientist past · Zapier, Clearbit, HubSpot

Product doc: ale-cabrera.com/portfolio/lighter-tracking-library