PART 1 — ABOUT ME
An only child learns early to get by on their own imagination. Mine landed on the internet: as a teenager, I discovered forums and blogs and, with them, HTML and Photoshop, learned on my own, deep into the night. Digital wasn’t a career plan. It was the place I already was.
When I went to study Graphic Design at ESPM, the marketing emphasis came with it: market, industry, positioning entered my education before my first job. The connection between design and business wasn’t something I learned on the job. It was the ground I started from.
From then to now, what changed wasn’t the field, it was the size of the problem. I started out answering for a single piece of artwork. Then for a screen, then for a team, and today, as a senior manager, for two design teams and a business metric. I never “became a PM”: I kept widening the scope without letting go of the lens that shaped me. The climb happened one step at a time, and it’s all right below.
The product seat, in fact, wasn’t something I asked for, it was offered. The invitation came three times: from my direct leadership, from my engineering peer, and from a global technology leader, because of the way I already led design, with a strong product lens in how I worked. I accepted for the reason I always do: the problem had gotten bigger.
Challenge moves me. And competition, but the kind that doesn’t need an audience: the one against myself, like Monica from Friends. I’ve been at Daki for 4 years because the bar on challenges never stopped rising.
PART 2 — TRAJECTORY
STEP BY STEP since 2012
I started as a designer, as an intern, making artwork and layouts. From there it was one step at a time, in order: designer, senior, lead, manager.
Because I started in 2012, each of my steps landed alongside a big shift in the profession. So the timeline below reads two ways: what I was doing, and what was happening in the market at that moment.
2012–2018
Designer
BR Mobile (intern → designer, 2012–2015) · freelance on the side
I answered for the artwork: layout, execution, delivery. The actual beginning, no euphemism.
The market at that point
Brazilian digital was migrating to mobile, and design was still treated as the final layer: the pretty one, brought in after the decision had already been made.
2018–2021
UI/UX → Senior Product Designer
Sciensa · FIAP
I answered for the screen and the flow, and, at senior level, for the problem behind them.
The market at that point
"UI/UX" became "Product Design". The profession's yardstick stopped being the deliverable and became the problem solved. This is where I built the technical depth that today lets me refuse to outsource the quality bar.
2021–2022
Product Design Lead
Kyte (SaaS)
First formal leadership seat. I started answering for a team’s quality, not just my own, reporting to a GPM, which put me inside the product conversation from day one of managing.
The market at that point
Design leadership became a real career, with a track of its own, instead of a consolation prize for the longest-tenured designer in the room.
2022–2024
Product Design Lead
Daki (quick commerce)
Same title, a different level of pressure: leading craft in an operation that changes course in days, with real business risk riding on every decision.
The market at that point
Speed became a requirement. Design that can't match the operation's pace turns into a bottleneck, and this is where most teams lose the quality bar.
2024–2026
Design Manager + Group Product Manager
Daki — Customer and Fulfillment
Two seats, at the same time, in the same role: two design teams and one business metric: purchase journey conversion.
The market at that point
The border between product and design started dissolving at companies mature enough on both sides. I didn't move from one seat to the other. I kept both.
2026–today
Senior Manager
Daki
Until here, my product leadership covered only the Customer context. Now it covers Customer and Delivery Experience: a whole new business context, with its own products, different stakeholders, different objectives and different indicators. The jump wasn’t in volume, it was in complexity.
The market at that point
Hybrid leadership stopped being an exception and became org design, with companies structuring the role instead of improvising the person.
PART 3 — HOW I LEAD
- Current role
- Senior manager
- Daki — design leadership (Customer and Fulfillment) and product leadership (Customer and Delivery Experience)
- Leadership track
- ~5 years
- design leadership (~3 years) → product leadership (~2 years)
- Most recent scope
- End to end
- the customer journey from pre-order to post-order, with conversion as the yardstick — and logistics operation efficiency focused on last mile
CONTEXT in two seats
As the timeline shows, the way I lead wasn’t born in my most recent role. It formed on the earlier steps, leading design teams.
From here on: the most recent role
But the most recent role is where it shows up in full: two consecutive seats, in the same area, in the order they actually happened.
The first was in design. I took over the area’s design team, six people serving 2 to 3 squads, and that’s where my way of leading became a system: a discovery method, team allocation by design, a career track, rituals.
The second came as a consequence of the first. The invitation to lead product arrived from three directions at once: my direct leadership, my engineering counterpart, and one of the global tech organization’s most senior leaders. It didn’t come because of a launch. It came because the design leadership was already operating as product leadership: business context at my fingertips, and an app migration where, in practice, the product role was already mine.
WHAT WAS at stake
Each seat had a problem of a different nature, but with the same root: work without a system.
IN DESIGN — METHOD
In design, the problem was method. Discovery planning was scattered across product, design and engineering: teams skipped critical points or lingered on the irrelevant, each pair following its own criteria. Discovery quality depended on who was in the pair, not on a method.
IN PRODUCT — GOVERNANCE
In product, the problem was governance. I inherited an area with no backlog for the weeks ahead, no roadmap, not a single alignment artifact, and stakeholders long frustrated with the lack of visibility into priorities and timelines. The recurring meeting with the business areas (five fronts depended on it, from commercial to CX, through marketing, sales planning and new business) had no supporting material: near-zero visibility, high friction, launches discovered at the last minute. With no visible prioritization criteria, the only way to win the team’s time was influence, escalating around the process, asking for status in DMs.
DESIGN LEADERSHIP
THE OPERATING SYSTEM of the team
Method: discovery stopped being personal criteria. That’s where I created the guiding questions dynamic: starting from the business problem’s context, the teams (engineering included, from day 1) generate questions and prioritize them sequentially over the Double Diamond structure; from the questions come tasks, methodologies and owners. I later iterated the format into CSD (certainties, suppositions and doubts), keeping the question-driven kickoff. Discovery became a method, and stopped depending on who was in the pair.
Team design
The team itself was my decision, not an inheritance: I reorganized who served which squads and fronts, redistributing people by the risk and the moment of each front: specialists where the risk was craft, coverage where the risk was throughput.
Career: a Y-shaped track anchored in real work
I structured the team’s career track in a Y (a management route and a technical route) built on competencies matched to the company’s, aligned with HR rather than parallel to it. The mechanics are two-sided: the designer’s self-assessment plus the leader’s assessment, by proficiency levels; the contrast between the two produces the PDIs, prioritized and anchored in the cycle’s actual projects: development in real work, not in a list of courses. It’s still in use as the team’s PDI guide.
Rituals: a cadence that protects craft and relationships.
- A structured monthly 1:1, documented per report, and it always closes with the question pointed the other way: “where could I have acted differently?”. Feedback in both directions, grounded in concrete examples and in the person’s potential.
- A non-negotiable weekly touchpoint with each person on the team, also documented: the short cadence that catches a small problem before it becomes a cycle-sized one.
- Design Day: one day a month, in person, designed edition by edition rather than as a fixed format: one edition dedicated to career (the Y track presented to the team, with a map per person), others to research, design system, AI in the design process, and editions of learnings brought by the team itself. The goal: sustaining craft and exchange in a high-velocity environment, where day-to-day work consumes that space if no one protects it.
- Batidão + Partiu: the annual close, with a retrospective and next year’s planning built with the team, not presented to it. Three cycles delivered.
PRODUCT LEADERSHIP
THE GOVERNANCE of the area
When I took over product, the team’s system didn’t stop: the rituals crossed the transition with me. What the area lacked was the equivalent of that system at the decision level, and that’s where I started.
Before any process, trust. I ran dedicated 1:1s with every stakeholder: understanding each front’s accumulated frustration before proposing the system that would resolve it. Only then, instead of rushing to refill the backlog, did I install the decision infrastructure.
A single PRD
I created one place per initiative, from start to finish: explicit business objective and indicators, every discovery artifact centralized, the solution hypothesis declared, and a decision recorded post-rollout: keep, reject or repeat. It’s the artifact that got team and stakeholders speaking the same language. And the guiding questions, the method I had created in design, became a mandatory section of the PRD: the whole area’s discovery now starts from them.
Data as a single source
I rebuilt the app’s data tracking, previously scattered across numbers that didn’t match: discoveries arrived with data that contradicted itself. I built dashboards, a glossary as a common language, and a weekly insights ritual presented to senior leadership, with a dedicated Slack channel. The material evolved from a presentation into a dashboard on an internal platform, and became the company-wide reference for app data.
A roadmap with public criteria
I structured the roadmap by business indicators and effort, grouped by themes, fed by an opportunity pool built in working sessions with the areas: looking at the business’s problems and generating ideas over an opportunity tree. Built with the areas, not announced to them. A valuable side effect: it unblocked initiatives dammed up for months, smaller features, processes and improvements too granular to become a case, but with real value for the teams.
That public criteria is what made it possible, for example, to block a recurring queue of small catalog improvements: grouped, they looked like value; isolated, they couldn’t sustain impact, and operations wasn’t ready to absorb them. The “no” stopped being an opinion and became a demonstration. Time confirmed the criteria: operations carried on without them with no perceived loss, and the topic only returned to the table when it had a real business case.
THE PRINCIPLES behind the system
What this trajectory shows in action, named. These are the principles that cross any area I take on, each with its corresponding evidence above.
Trust is built; autonomy is earned.
I don’t give blind trust up front, not even to seniors. The degree of accompaniment is a function of initiative risk × seniority × relationship history; full delegation is the rule once trust exists. This principle was born from a mistake of mine: early in my management career, I gave immediate autonomy to a senior professional, and discovered too late months of masked underperformance that detailed accompaniment at the start would have exposed. Never again.
Direct communication, in both directions.
Feedback always grounded in concrete examples and in the person’s potential, with the channel open on the way back: every monthly 1:1 closes with feedback for me. Evidence: the rituals above.
Respect for the craft.
I hire and develop people who do things well for the simple fact that they’re done well. But craft isn’t assessed by opinion: it’s assessed against an explicit baseline (technical calibration, standardized artifacts, working agreements, a career track). Technical feedback happens in the team; performance feedback, always one-on-one. Evidence: the Y track and Design Day.
Foundation before velocity.
Every area I’ve taken on, I started from the structural base: in design, discovery planning; in product, a single PRD, data as a single source and a roadmap by indicators. System first, so the team knows what’s expected and moves on its own. Evidence: the two seats above.
Evidence over opinion (including mine).
I prioritize by expected value × resources × challenges ahead, and I kill what doesn’t hold up, even when the idea belongs to an executive, or to me. Evidence here: the “no” to the catalog queue, sustained by public criteria. (Elsewhere in this portfolio, the same principle appears in reverse: my recommendation not to invest in an initiative from my own team.)
OUTCOME still in use today
Average discovery time fell by nearly half, and the method created in design is still in use by the design and product teams, along with the career track and Design Day.
The team’s operating system proved itself where it matters most: designers were promoted within the track I created, the team crossed the period without relevant losses, and part of it later took on leadership positions, including a promotion to leader under my management.
In the product seat, the biweekly initiatives report became the single source for deliveries and decisions, distributed by e-mail to a broad leadership forum, replacing the workaround escalations and the status requests in DMs. The app data, presented weekly to senior leadership and in a Slack channel created just for it, evolved from a presentation into a dashboard on an internal platform: the company’s reference for app data.