Strategy,
product and
operations,
built to scale.

EDENRED SA · BRAZIL/2013 – 2019/CONSULTING OPERATIONS JR. MANAGER

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.

A 21-year-old asking to build a division is easy to dismiss. A 21-year-old who has already mapped every fraud pattern is harder.

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. One of my analysts started as an operational assistant in the 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.

• The most valuable problems to solve are the ones nobody has claimed ownership of yet.
• A methodology that transfers knowledge is worth more than a methodology that produces results.
• Proactive value creation is a retention strategy. Reactive problem-solving is not.
• The real measure of leadership is what happens when you leave.

EDENRED SA · SÃO PAULO/2019 – 2023/PRODUCT MANAGER

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.

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.

The worst thing I could have done was launch another solution before understanding why the first one had failed.

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.

From $250K in the first year to $1M ARR. Not because the technology was revolutionary, but because we finally understood the problem we were solving.

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.

• Diagnosis before prescription. Understand why something failed before proposing how to fix it.
• Missing features and missing fit are different problems. Conflating them leads to the wrong solution.
• Managing executive expectations through uncertainty is a product skill, not a communication skill.
• Being wrong quickly in small ways is safer than being wrong slowly at scale.
• Trust is the real product. Revenue follows when clients believe in what you've built.

KOENING & FERRARINI · BRAZIL/2024 – 2025/MANAGEMENT CONSULTANT

Thirteen years in tech, then a law firm.

After thirteen years in the corporate sector (operations, consulting, product), I left to join my brother's law firm as Business Advisor and General Manager. The firm was growing quickly in financial services and Social Security litigation, and it had reached the point every fast-growing professional services business reaches: demand was outpacing the firm's ability to serve it.

I had a law degree I had never used professionally. What I brought instead was thirteen years of watching operations break under scale, and a fairly specific instinct about where to look first.

I looked at where the most expensive hours were going.

The bottleneck was a person, and everyone knew it.

Every new client engagement started the same way. A Senior Attorney read the client's contracts line by line, looking for abusive clauses, calculating what the client might recover if those terms were successfully challenged, and transcribing the findings into the firm's internal control format.

This took up to two weeks per client.

Two weeks of the most expensive legal talent in the building, spent on work that was repetitive, mechanically similar across clients, and universally disliked by the people who had to do it. It was also the hard ceiling on how many clients the firm could take on.

Nobody in the firm framed it as an operational problem. They framed it as the cost of doing the work properly. That framing was the actual bottleneck.

Every attempt to grow ran into the same wall, and the firm had learned to call that wall professionalism.

Reading a hundred contracts to find the pattern.

Before writing any code, I did the boring work. I went through the firm's historical contract reviews and mapped what the attorneys were actually doing, step by step. The finding was the whole case: the contracts came from a small number of institutions, followed a small number of templates, and the abusive clauses recurred in predictable positions with predictable language. The variation that made each case feel unique was, structurally, quite narrow.

Which meant the task wasn't legal judgment. It was extraction, classification, and arithmetic, with legal judgment needed only at the end, on the exceptions.

So I built the tool: a custom solution in Python that ingests a contract, extracts the key terms, classifies it against the known patterns of abusive clauses, and calculates the client's estimated financial gain if those terms were successfully revised. The output exports directly into the format the firm's internal controls already used, so nothing downstream had to change.

Two weeks of a Senior Attorney's time became hundreds of contracts processed in seconds.

Getting lawyers to trust a script.

Building the tool took weeks. Getting it adopted took considerably longer, and that was the part that mattered.

Law is a profession built on personal accountability for every judgment made. Handing part of that judgment to software isn't a technical decision, it's a professional risk, and the attorneys were right to treat it as one. So I never asked them to trust the output. I ran the tool in parallel with the manual process for the first cohort of clients and put both results side by side. Where the tool matched, that was evidence. Where it diverged, we looked at why, and the divergences became the rules that improved the next version.

The attorneys remained the final authority on every case. What changed was that they now started from a structured analysis instead of a stack of PDFs, and spent their time on the exceptions rather than the pattern.

What actually changed.

Case processing cycle time dropped from 18 to 12 months. The firm's execution capacity doubled with no additional headcount, and the constraint on client intake moved from contract review to sales, a far better problem to have. The two weeks that had been locked up in one senior attorney's calendar went back into the work only a senior attorney can do.

The more durable outcome was cultural. The firm had assumed technology was something that happened in other industries. One tool that visibly worked changed that assumption faster than any amount of persuasion would have. The office now runs on AI end to end: analytical optimization, operational automation, and testing legal theses before committing resources to them.

Two weeks of the most expensive person in the building, replaced by seconds, and given back to the work only they could do.

Why this one stayed with me.

I had automated processes before. What was different here was the environment: a traditional profession, a small team, no technology budget, and no internal appetite for the idea when I arrived.

That taught me something I had partly forgotten inside a multinational, where technical capability is assumed and the hard part is prioritization. In a firm of twenty people, the hard part is permission. The tool was never the difficult piece. Establishing credibility with people whose professional reputation was on the line was the difficult piece, and the only way through it was to show the work rather than describe it.

It also confirmed something about where I want to spend my career. The satisfying part wasn't writing the code. It was watching a room of skilled people stop doing work they resented and start doing work that used them properly.

• The most expensive recurring task in an organization is usually the best place to start looking.
• Before automating a process, spend real time doing it manually. The pattern is the whole solution.
• In a small, traditional organization the constraint is rarely capability. It is permission.
• Run the new process in parallel with the old one. Evidence converts skeptics; arguments do not.
• Automation should return expert time to expert work, not remove the expert from the loop.

EDENRED SA · SÃO PAULO/2016 – 2017/OPERATIONS COORDINATOR

The company that bought us used to be the company we were beating.

In 2016 we were acquired by a French group that had, until the paperwork was signed, been our main competitor in the market. Overnight we went from a local technology company to part of a fast-growing multinational.

The strategic logic was clear to everyone. The human reality was less comfortable. My team knew exactly what the acquirer's organizational chart looked like, because we had spent years competing against it, and it contained a department that did, functionally, what we did.

Two teams, one job. Everybody in both rooms could do that arithmetic.

What I was actually asked to do.

As Operations Coordinator, I was given the synergy mandate: merge my department with its counterpart on the acquiring side, and demonstrate quantifiable gains to a leadership team that had never met me.

The brief looked like an org design problem. It was really two problems running in parallel, and they pulled in opposite directions.

The first was people. Both teams were operating with high anxiety and no information, which is the condition under which good people quietly start taking recruiter calls. The second was clients. Enterprise accounts do not care that their supplier is going through an integration. If service levels dipped during the transition, the synergy case would be irrelevant, because we would have destroyed more value than we captured.

Doing either one badly would have made the other impossible.

Nobody wants to hear that some roles will go and that you can't yet say which. Saying it anyway was the only thing that bought any trust.

People first, and honestly.

I made a decision early that shaped everything after it: I would tell both teams the truth about what I knew, including the parts that were bad, and including the parts that were still undecided.

That was uncomfortable. It meant saying out loud that some roles would be consolidated and that I could not yet say which ones. The conventional instinct is to withhold until you have a finished answer, because partial information creates noise. But in an integration, silence is not neutral. People fill it with the worst version of events, and by the time the real answer arrives they have already emotionally left.

Alongside the transparency, I did the work that made it credible. I mapped every person in both teams against their actual capabilities rather than their job titles, and I went looking for landing spots across the wider organization before the consolidation was formalized. I spent a significant part of those months in other departments, essentially selling my own people into roles elsewhere in the company.

Sixteen roles were eliminated. I placed ten of those people into other parts of the business.

Then the operating model.

With the people question moving, I turned to the mechanics. Both legacy teams had arrived at their own processes, their own tooling, and their own definitions of what good service looked like. Neither set was wrong. Running both in parallel indefinitely was what would be wrong.

We went through the work stream by stream and chose a single standard for each, sometimes ours, sometimes theirs, decided on the merits rather than on who had been acquired. That detail mattered more than any efficiency it produced. A team that sees its own method selected on evidence stops experiencing the integration as a takeover.

We then migrated both operations onto a single unified system, sequenced so that no client-facing process was ever running on an unproven configuration. The migration was deliberately slower than it needed to be. Protecting service levels through the transition was worth more than finishing a quarter early.

What the integration produced.

Process standardization doubled service capacity per team member. The combined department handled the merged client base with materially fewer people and without a measurable dip in service levels during the transition, which is to say the clients, who had every reason to be nervous about their supplier being acquired by their alternative supplier, largely did not notice.

The result I think about more often is a softer one. The people whose roles were eliminated and who did not land internally still told me afterward that they were grateful for how the process had been run.

Being made redundant is not a good experience. Being made redundant by someone who told you the truth early and spent their own time trying to place you is a materially different one.

What I would carry into the next one.

Post-merger integration is usually presented as a synergy calculation. The number is the easy part. Two overlapping departments will always produce a defensible efficiency figure on a slide.

What determines whether that figure survives contact with reality is whether the people who have to execute the new model believe the process was run fairly. Every decision I made about sequencing, transparency, and whose process to adopt was ultimately a decision about credibility. The capacity gain was the output. The trust was the mechanism.

It also taught me to be suspicious of integration plans that treat the client as a constant. Clients are the one stakeholder in a merger who did not choose to be there, and they are the first to leave when the internal reorganization becomes visible to them.

• In an integration, partial honesty early beats complete answers late.
• Choose the better process on the merits, not by who acquired whom. That single decision sets the tone for the whole merger.
• Sequence migrations to protect service levels, even when it costs you a quarter.
• Synergy figures are easy to produce and easy to lose. Execution credibility is what makes them real.
• How you treat the people who leave is watched closely by the people who stay.