The useful version of an about page.

I do my best work on products where user behavior, operations, and technology are entangled.

At Loadsmart, that meant turning freight audit, disputes, and payments into a product workflow. At Zenklub, it meant translating clinical and operational constraints into a viable scope for in-person care. At EBANX, it meant reducing dependence on human support without treating self-service as simple ticket containment.

I do not need the domain to be simple. I need an important problem, access to the people living with it, and a concrete way to determine whether the product changed anything. I am less useful when the job is primarily maintaining an inherited roadmap.

I try to buy information, not certainty.

I separate what we know from what we are assuming, then look for the assumption that would make the rest of the solution irrelevant if it proved false.

At Loadsmart, a payments expansion looked strategically attractive. Research suggested that many customers were already anchored in their ERPs and were unlikely to move that workflow into the TMS. I recommended not pursuing it at that point.

At EBANX, the appropriate response was different. We set success criteria, evaluated vendors, launched the chatbot gradually, and used resolution and escalation data to guide expansion.

Reversibility matters. When the cost of being wrong is limited, I prefer a small release. When the central premise is weak, I prefer stopping before enthusiasm becomes sunk cost.

I am hands-on, but I do not pretend to be an engineer.

With Fio, I worked directly on strategy, flows, UX, product design, prompts, and the pipeline connecting summarization, script generation, and text-to-speech. I took an iOS product to TestFlight using React Native, Supabase, RevenueCat, analytics, and AI-assisted development tools.

That allows me to prototype, investigate failures, and discuss technical decisions with much more specificity. I also define metrics and use product data to evaluate adoption, reliability, and behavior.

My boundaries matter. I am not a production engineer, specialist visual designer, or data scientist. In critical systems, I expect engineers to own architecture, security, and internal code quality. My contribution is connecting the user problem, desired behavior, experience, and actual system performance.

Fio made me much less impressed by demos.

Getting an AI pipeline to work once was relatively easy. Getting it to produce a good, source-grounded episode repeatedly was the real product problem.

It also taught me that an elegant thesis does not create behavior. I imagined an automatic weekly podcast, while my own usage raised the possibility that immediate listening was more valuable. A waitlist email produced no signups. Free alternatives such as NotebookLM raised the bar for willingness to pay.

Fio is not a clean success story. It forced me to separate four things I might previously have conflated: an interesting idea, an enjoyable experience, a reliable system, and a product that people return to and pay for.

I am good at finding the decision hiding inside a complicated workflow.

I started in customer support, so I tend to see products through exceptions, tickets, and manual work, not only through the intended journey.

At EBANX, that perspective helped structure self-service products that increased the self-service rate by 60 percentage points and reduced refund and payment SLAs from days to minutes. At Zenklub, I connected professional needs, operational constraints, and adoption, contributing to a 25-point NPS increase and a 44 percentage point increase in core feature engagement. At Loadsmart, I applied the same approach to financial workflows that processed more than US$2 million in audited invoices.

The common thread is not an industry. It is decomposing the system, identifying the central decision, and keeping the team connected to the outcome.

I have real gaps.

My strongest experience is in B2B products, operations, and self-service. Fio exposed that I do not yet have the same depth in consumer distribution, retention, or willingness to pay.

I can build and debug AI-assisted prototypes, but my technical depth does not replace an experienced engineer.

I also have a working pattern that needs correction. When the context changes and I do not fully understand a new scope, I sometimes spend too long trying to resolve the uncertainty alone. That delays the point at which the team can help and can cause my questions to surface late.

I am working on exposing assumptions and gaps earlier, even when my thinking is incomplete. Curiosity and self-awareness are not solutions by themselves. These gaps only shrink through practice and evidence.

I collaborate best when the problem is shared and ownership is explicit.

With designers, I want to explore alternatives early and discuss the behavior the experience should produce, rather than only reviewing a finished interface.

With engineers, I bring context, constraints, and success criteria. I expect them to shape the solution and challenge weak assumptions.

At Zenklub, different groups disagreed about pushing adoption of an experience that still carried risks. We translated those concerns into criteria and created a staged rollout.

Most of my experience has been with functional leaders and product teams rather than working directly for founders. What I want from a founder relationship is access to the reasoning behind decisions. I can work with strong conviction. I work less effectively when a personal preference is treated as a fact that cannot be examined.

I do not treat disagreement as a contest of conviction.

I look for the beliefs producing each position and what could make those beliefs testable.

At Zenklub, leadership wanted greater adoption, while CX and the clinical team were concerned about experience quality and the relationship with professionals. A staged rollout allowed us to observe adoption and experience before expanding the change.

I also do not protect a decision because I helped create it. At Loadsmart, I recommended dropping a payments thesis after research weakened its adoption premise. In another launch, a partial rollout broke a critical workflow and was reversed.

Changing my mind, pausing, or rolling back is not indecision when the evidence has changed. It is part of owning the product.

I want a Product Manager role with real responsibility for one product.

I want to work close to users, designers, and engineers, participating in problem definition, creation, launch, and iteration.

AI should change the product's behavior or economics, rather than appear as another roadmap feature. Fio expanded my ability to work directly with prototypes, prompts, quality evaluations, and system limitations, but I do not want to turn that into an inflated title.

I am looking for a small team with strong leadership, where I can own an important problem and remain accountable for what happens after launch.

I am not looking for a role primarily based on coordinating several teams, producing executive presentations, or managing a backlog already defined by someone else.

I work best in a demanding environment with little theater.

I want colleagues who communicate directly, expose unfinished thinking, and change their position without turning disagreement into a status contest.

I prefer small teams, short cycles, frequent contact with users, and proximity to the working product. I do not need constant comfort. I do need context, clear feedback, and access to decisions that change the problem or mandate.

I also work better when rituals serve the work rather than the work existing to feed rituals. Presentations are not a problem when they are grounded in the product. An environment dominated by decks, recurring alignment, and decisions made far from the team reduces both my energy and usefulness.

I want to learn from people better than me, not simply receive autonomy without direction.

Do not hire me if the role is mainly a coordination layer.

If the primary need is executive storytelling, keeping several teams aligned, or navigating organizational politics, there are Product Managers better suited to that mandate.

I am also not the right person to replace an ML engineer, independently lead a sophisticated visual language, or bring a mature consumer growth playbook. My consumer product experience is still primarily Fio, where the main demand and retention risks remain unresolved.

I would probably be a poor fit for a company where AI is decorative, the roadmap is already fixed, or sales requests become priorities without examining the underlying patterns.

My best work requires access to the problem and responsibility for the decision. Without those conditions, I would be more inclined to question the system than simply operate it.