The problem nobody wanted to own.

I was 21 years old, still in law school, working full-time as a Junior Analyst at Edenred — a French fintech operating across 42 countries. My job was straightforward: organize fleet management data for major enterprise accounts. Clean up spreadsheets. Cross-reference receipts. Flag anomalies.

The anomalies were everywhere.

Fleet management — the process of controlling fuel cards, vehicle expenses, and logistics costs for large corporations — was one of the most complex and fraud-prone areas in the B2B expense management business. Drivers inflating mileage. Suppliers billing for services never rendered. Internal processes with no audit trail. For a company whose enterprise clients represented hundreds of millions in annual revenue, this wasn't an accounting problem. It was an existential risk that nobody had formalized a response to.

There was no team. No methodology. No playbook. There was a junior analyst with a spreadsheet and a growing sense that this gap was much bigger than anyone had acknowledged.

The decision to move before being asked.

I didn't wait for a mandate. I started mapping the problem systematically — cataloguing fraud patterns, cost leakage types, and the operational gaps that made them possible. I brought my findings to leadership not as a complaint, but as a proposal: this area needs a dedicated structure, and I want to build it.

It was a bold ask for someone still finishing his undergraduate degree. But the data was undeniable. And I had something more valuable than seniority: I had already done the work to understand the problem deeply enough to propose a solution.

They gave me the green light.

Building from one.

The first year was about proving the concept. I developed a proprietary fleet analytics methodology — a structured framework for identifying cost leakages across client operations. I ran it manually at first, account by account, generating insights that clients had never seen before. The results were immediate: an average of 15% cost savings per client. The word spread fast inside the sales organization.

As demand grew, so did the team. I hired carefully — prioritizing analytical rigor and client empathy over pure technical skill. I developed SOPs that didn't just document processes but transferred knowledge in a way that made the team genuinely self-sufficient. When I eventually left the role four years later, the division didn't skip a beat.

By that point, we had grown from one person to 45. We were focused exclusively on Edenred's top 100 enterprise accounts. And we were directly responsible for retaining 40% of the company's total revenue.

None of this works without the people above you.

There's a version of this story where I take all the credit. That version would be dishonest.

Managing upward was just as important as managing the team I was building. My direct manager and our director were not passive observers — they were active participants. They listened when I came to them with ideas that probably sounded half-baked at first. They pushed back when my thinking had gaps, and they bought in when the logic was sound. They gave me room to fail safely and cover when I needed it.

What I learned from them wasn't just operational — it was about how leadership actually works. That before you can lead a team of 45, you need to know how to bring one person along. That active listening isn't a soft skill — it's the mechanism by which trust gets built. That the most experienced person in the room often isn't the loudest one, and that the best thing a young leader can do is shut up long enough to learn something.

I came into that role with energy and ambition. I left it with judgment. That difference was entirely the result of having leaders who were willing to invest in me — to hear my crazy ideas, to guide the ones worth pursuing, and to kill the ones that weren't. A structure that protects $400M in revenue doesn't get built in isolation. It gets built in conversation.

What the numbers don't show.

The 98% client satisfaction rate and 25-point NPS improvement are real, and I'm proud of them. But what the metrics don't capture is the organizational shift that happened along the way.

Before this division existed, enterprise account retention was reactive — the company responded to problems after clients raised them. We changed that model entirely. By embedding ourselves in client operations, we moved retention upstream: identifying risks before they became complaints, and delivering proactive value before clients thought to look elsewhere.

We also reversed churn for 18 enterprise clients who were on the verge of leaving. That's 18 relationships — each representing significant annual contract value — that stayed because someone finally understood their operations well enough to fix the right problems.

The leadership lesson I didn't expect.

Building a team of 45 people before I had graduated taught me something that no business school course had yet: the most important thing a leader does is make themselves replaceable.

Every promotion I took in my career at Edenred, I left behind someone who was ready to fill the role I was vacating. Tayana started as an operational assistant in my department and ended up replacing me as Operations Coordinator when I became Product Manager. That wasn't an accident — it was deliberate. I spent the last year in every role I held developing my successor, because I knew the organization's resilience depended on it.

The $400M figure represents revenue protected. But the more durable outcome was a division that outlasted its founder — still running, still growing, long after I moved on.

A promotion I didn't ask for, in a role I'd never held.

In late 2019, Edenred offered me the Product Manager role for their mobility platform. I had spent the previous four years building the consulting division — operations, client management, analytics. I had never shipped a product. I had never run a technical squad. I had never written a product brief or sat in a sprint review.

I said yes anyway.

The platform I was inheriting managed fleet operations for large enterprise clients across Brazil — fuel cards, vehicle tracking, expense management. The technical team was in place. The clients were there. And waiting for me on day one was a product that had just been launched prematurely, underperformed against every metric it had been sold on, and was generating exactly the kind of internal noise that makes executives nervous.

My first month as a Product Manager was also my first crisis as one.

Understanding what went wrong before trying to fix it.

The instinct in that situation is to move fast — to show the organization that the new PM has the situation under control. I resisted that instinct. The worst thing I could have done was launch another solution before understanding why the first one had failed.

I spent the first 90 days doing almost nothing but listening. I interviewed clients — not to sell them on a roadmap, but to understand how they actually used the product, where it broke down, and what they had expected it to do. I sat with the engineering team and learned how the system was architected. I went back to the original business case and tried to understand the gap between what had been promised and what had been built.

The picture that emerged was uncomfortable but clear: the product had been launched to meet a commercial deadline, not because it was ready. The underlying logic was sound — there was a genuine opportunity to use telematics and route data to optimize fleet operations — but the execution had skipped the step of validating whether the algorithm's outputs actually matched real-world client needs.

We weren't missing features. We were missing fit.

Rebuilding from the problem, not from the solution.

With a clear diagnosis, we pulled the product back and started over — not on the technology, but on the problem definition. Working closely with a small team of Product Owners and engineers, we rebuilt the algorithm's business rules from the ground up, this time anchored to what clients actually needed to optimize: route efficiency, fuel consumption, unauthorized usage, and predictive maintenance triggers.

This process took twelve months. Twelve months of iteration, client testing, internal pressure, and incremental validation before we had something we were confident enough to relaunch. The executive board was patient, but not infinitely so — managing their expectations through that period required a discipline I hadn't needed in my previous role. Weekly updates. Clear milestones. Honest assessments of what was working and what wasn't. No spin.

When we relaunched, the difference was immediate. The algorithm was deployed across 50,000+ vehicles. Clients saw an average 10% reduction in operational costs — a number that translated directly into contract renewals and new acquisition conversations.

From product to platform: the AI angle.

The relaunched product did something the original hadn't: it generated trust. And trust, in enterprise B2B, unlocks investment.

With a stable core, we pushed further. The logistics optimization layer evolved into what became recognized as the first operating artificial intelligence in the Brazilian fleet management market — a real-time algorithm that processed telematics data across tens of thousands of vehicles simultaneously, generating route recommendations and cost alerts at a scale that no manual process could replicate.

The commercial results followed. From $250K in ARR in the first year after the relaunch, the platform grew to $1M in annual recurring revenue over three years. We managed a $3.5M CAPEX budget across five Product Owners and four technical squads. The product became a centerpiece of Edenred's enterprise value proposition — and a direct driver of cross-sell revenue across other product lines.

What I learned about being wrong in public.

The hardest part of this experience wasn't the technical complexity. It was learning how to hold a position — on product direction, on timelines, on what we were and weren't going to build — in front of people who were more experienced than me and had legitimate reasons to be skeptical.

I had come from a world where I built the playbook. As a PM, I was executing someone else's vision while simultaneously trying to reshape it. That requires a specific kind of confidence: the kind that is grounded in data and customer insight, not in seniority or institutional authority.

I also learned that being wrong quickly is better than being wrong slowly. The original product failed because it tried to be right before it had earned the information it needed. The rebuilt product succeeded because we allowed ourselves to be wrong in small, controlled ways — in client pilots, in sprint reviews, in internal debates — before committing to anything at scale.

Product management, I came to understand, is not about having the right answers. It's about building the right process for finding them.