OLX Brasil

A dominant classifieds marketplace with a platform problem

OLX Brasil is the largest classifieds marketplace in Brazil — cars, real estate, jobs, and general goods. At the scale I joined, the company was running multiple product verticals simultaneously, each with its own squad and roadmap.

I was PM of the "Ad platform" and "Ad management" squads — the first responsible for the core "ad" entity that everything else in the marketplace was built on top of, and the second for the end-user ad creation and management experiences. The ad entity was fragmented across approximately five legacy microservices, each owned by a different squad, each with its own review queue and codebase conventions.

Every new use case required touching infrastructure nobody owned end-to-end

Adding a new product category, changing a listing field, or launching a new vertical feature all required coordinating changes across those five services sequentially. Each step took between one and three days — not because the work was complex, but because each service had a different owning squad, different code conventions to navigate, and a separate review queue to wait in.

The most complex use cases required approximately 20 sequential steps to deploy. Vertical teams — the squads responsible for autos, real estate, goods — couldn't ship independently. Their roadmaps were blocked by infrastructure they didn't own and couldn't change.

The business consequence was visible: the vertical roadmaps (new features, category specialization, new monetization products, B2B tools) were consistently slipping and renegotiated.

Solving the management problem before the technical one

Platform investments are long by nature — months of build with no visible user-facing output. In my experience, the biggest failure mode in a platform investment isn't technical; it's losing stakeholder buy-in halfway through when quarterly reviews come around and there's nothing to show yet.

My first move was to create a measurement system before touching any code. I mapped existing use case workflows step by step and defined "workflow steps" as the proxy metric — each step representing one to three days of real engineering work. This gave us two things: a concrete baseline (the most complex use case was 20 steps), and a tool for showing measurable progress at each iteration rather than asking management for trust until full delivery. Watching a specific use case drop from 20 steps to 12 to 7 to 4 is concrete. Architecture diagrams are not.

In parallel, I ran discovery sessions with every vertical PM to map their forward roadmap — ensuring the architecture we designed would support what teams needed to build next, not just what existed today.

On the rollout of the new architecture, we enforced adoption by requiring that new use cases use the new services, and measured the percentage of data traffic being served by legacy vs new services as the migration progress metric.

Clean external APIs abstracting the legacy layer

The platform we built exposed a set of well-defined external APIs that abstracted the five legacy microservices entirely. Vertical teams could now build new use cases by composing existing API capabilities — without needing to understand or coordinate changes to what was underneath.

• Designed the API contract schema in collaboration with backend and frontend leads
• Prioritized highest-traffic use cases first to accelerate adoption and create early proof of concept before broader rollout
• Versioning and deprecation governance defined from the start — who could add to the contract, how breaking changes were handled

The numbers that followed

What I specifically did

• Proposed the "workflow steps" measurement system — one of the strategies to keep management bought in for 12+ months and deliver long-term value
• Led the cross-team discovery process with all vertical PMs, producing the architectural requirements the platform needed to support
• Designed and enforced the adoption policy

Other significant work in this role

• ZAP+ integration crisis — Following OLX's acquisition of ZAP, the flagship cross-marketplace publishing product had a critical integration failure: ads published in ZAP weren't appearing in OLX. I was brought in to diagnose. First move: built a SQL query joining both data warehouses to measure the problem quantitatively (15% of accounts had at least one ad with an integrity issue). Root cause: OLX and ZAP had different ad lifecycle models — ZAP's "unpublish without delete" feature was triggering OLX's delete API. Accounts with integrity issues dropped from 15% to 1% after targeted fixes.