I Didn't Study to Become a Product Engineer: How I Got Here Anyway

This morning, before nine o'clock, I already had VS Code open, a Supabase console, and an Excel file in its twenty-something version called FIJI Calcs v3.23b.xlsx. What I'm building is a product that validates real estate brokerages in the United States. At its core, it's about translating that spreadsheet into a system that supports buying and selling decisions worth millions of dollars. Every cell with a formula is a product decision I need to understand before writing a single line of code.

Five years ago, my day started very differently. I was in my final year of Bioengineering at ITBA, in the middle of the pandemic, stuck at home, reading papers on colorectal cancer with liver metastasis. My thesis was an honest attempt to apply machine learning to predict mortality and KRAS gene mutation in oncology patients, in collaboration with Hospital Italiano de Buenos Aires. It wasn't just another final project: we were testing a real hypothesis, against real papers, with mentorship from a medical team that explained diagnostic concepts so we could connect them to the results our algorithms produced. The program didn't cover ML or coding at that depth, so we learned on demand and against deadlines. It was exhausting. It was also what convinced me that I liked building tools more than using them.

The jump to software, however, didn't come from the thesis. My first formal job was at a company that maintained medical equipment across the country, optimizing processes nationally. It was a good place to start, but the in-office dynamic didn't match what I was looking for: I lived almost two hours by bus from the office, and the role could perfectly well be done remotely. That mismatch made me pay attention to what I actually wanted: working remotely, joining an industry where I could build products, not just optimize existing processes. Around that time, I got an offer from a software factory. Better pay, remote work, and an entry point into an industry I had been flirting with since my thesis. I accepted. I had spent a year training models in Python, but I had never worked on a real software team. Git, code reviews, deploys — I learned all of that on the fly. What I did bring with me, without fully realizing it, was the way of thinking about problems that the thesis had left me.

From that decision until today, four years have passed, a startup in Techstars, a team in California, and Digital Techniques classes for high school seniors at my old school in Posadas.

What Bioengineering Gave Me (And It Wasn't Code)

When I entered software, I thought I was bringing two things: a year of training models in Python for my thesis, and the nerves of not knowing Git. Four years later, I discovered that what I use most every day, I didn't learn in Python or Git. I learned it studying engineering.

The degree taught me to see problems as processes, and to break those processes into smaller parts until each one becomes manageable. It's not an epic skill. It's the foundation of everything. This week, before writing a single line of code for a new screen, I sat down with a piece of paper to draw what data was coming in, in what order it would intersect, what depended on what, and where the decisions were that the user could change. Only then did I open the editor. Courses like Signals and Systems, Quantitative Physiology, or Machine Learning shared that same logic: no interesting problem gets solved all at once, it gets solved in layers.

But the strongest lesson wasn't technical. It was how to work with people who know things I don't. In the thesis, the doctors at Hospital Italiano knew oncology and I knew some engineering. The dynamic was to listen to the real pain, understand the clinical context, and bring back a proposal that worked for them. It made no sense for me to try to become an oncologist. It made sense for me to lean on them to do what they couldn't do alone.

Today I do the same thing, but with people in real estate, fintech, business operations. The domain is different. The way of working it isn't.

My First Months in Software: What I Underestimated

My first week was chaotic. They had me install tools I had never heard of: Git, Node.js, VS Code, Figma. My first task was to build a user signup on the backend using TDD and object-oriented programming. The first week. I was still figuring out what each icon in the editor did.

The strange thing is that the problem wasn't understanding the system. The engineering side of my brain worked: I could read the complexity, break it down, see the trade-offs of each decision. The problem was execution. I knew the what and the why; what I was missing was the how in code. To this day, I identify more with that description than with that of a pure developer.

But the most expensive lesson of those first six months wasn't technical. It was realizing that I was fighting an identity I had imposed on myself. "I'm an engineer, I have to be able to learn this on my own." Hours and hours in front of the computer, without asking for help, back when AI couldn't help you out. Imposter syndrome grew because tasks kept piling up and I kept refusing to ask. Burnout, fear of looking foolish, all of it. And the most absurd part is that my original goal had never been to become the best developer on the team. My goal was to understand how a technical team worked so that one day I could lead one. But my mind was working against me, pushing me to become an expert at things that didn't matter.

The click came from a conversation with my tech lead. I was delivering late because I kept expanding use cases on my own, based on my own hypotheses, not on real user problems. He explained something simple that changed the way I work: done is better than perfect. I was inverting Pareto. Instead of 20% effort for 80% of the result, I was spending 80% to get an extra 20% that no one had asked for. And that wasn't quality. It was a bottleneck for the team.

That was the first big thing I had to unlearn from college. The next came later, when I started to realize that my biggest strength wasn't where I was putting the most effort.

From Trainee to Product Engineer: What Moved the Needle

My mistake as a Junior was wanting to touch everything. TypeScript, Angular, Express, Tailwind, Bootstrap, PHP, Next.js, whatever came up. Each new technology felt like a box I had to conquer. The result was predictable: I was decent at many things, but reliable at none.

The first real jump came when I picked a stack and stopped jumping from tool to tool. TypeScript became my language and everything else grew around it: Node with Express, Next.js, design patterns, architecture. Having a direction allowed me to start thinking about problems bigger than the ticket in front of me. In that stage, I led several end-to-end projects as a Semi Senior: a services marketplace platform, a B2B management platform, an internal traceability dashboard. Across all of them, around 1,500 active users.

But the jump to Product Engineer didn't come from writing better code.

In those projects, I discovered something that now seems obvious to me: clients never come asking for a feature. They come with a pain, a manual process that eats up their hours, a bottleneck they don't know how to fix. The feature is the translation we make of that pain. And for that translation to be good, someone on the team needs to have a view of the whole product, beyond their role. That was the place I started to fill.

At the team level, what I learned was similar. When I joined, the team was closing sprints at 60% predictability. By the time I left the role, we were at 90%. It wasn't magic: it was identifying where tickets piled up at the end of the sprint, rethinking refinement by prioritizing flows over isolated tasks, and switching from code-then-test to testing in parallel. The difference wasn't faster typing. It was understanding the whole system and pulling the right lever.

If I had to summarize four years in a single habit, it would be this: before touching code, before choosing architecture, before any technical decision, understand the user's pain as much as possible. Become an expert in their problem, not just in your tools. Four years in, I still believe that habit is worth more than any new tool that comes along.

Techstars and Product Under Pressure: When Code Stops Being the Most Important Thing

In parallel with my work at the software factory, I joined a startup as a Product Engineer that entered the W24 batch of Techstars in New York, within the Stellar & MoneyGram Accelerator program. The first thing that felt different was the speed. We needed weekly progress to get real user data on every change. That forced a level of integration you don't experience in a more traditional company: while the sales team was selling the way we solved a problem, the developers were still building it. What sales promised, we had to make real the following week.

The moment I understood that my role had changed wasn't a brilliant code review. It was redesigning an onboarding.

The product had a long onboarding that asked for a lot of personal information before letting the user try anything. The data showed the predictable: people gave up in the middle. The hypothesis was that the entry cost was too high for someone who didn't yet know if the product was for them. The decision was to invert the logic: ask for the bare minimum so the user could try it, and only later, with someone walking them through it, fill in the rest as needed. Post-onboarding engagement went up 40%.

What matters about that story isn't the metric. It's what the process taught me: I wasn't thinking about whether a class was properly typed. I was thinking about why a user was abandoning on screen three and what would happen if we removed it. That's a different seat, a different muscle, a different kind of problem.

What I took most from Techstars isn't taught in a course. Sharing a table with founders, seeing how they think about execution, how they treat technology as a tool and not as an end, opened my mind. I left the program with an idea that still comes back to me: at some point I want to build my own product that people actually use.

Today: Building, Teaching, and Still Without a Manual

Today my week is split across three tables. The first is the product I'm working on right now, a real estate platform for the US market. The second is my Digital Techniques classes at IPSAJ (Instituto Politécnico San Arnoldo Janssen), my old high school in Posadas, in front of 16-year-old students. The third is side cases: real problems from companies or people that I look at to see if I can build tools that help them.

The classes surprised me with something I didn't expect. When you have to explain a technical concept to a 16-year-old, knowing the topic isn't enough. You have to design the mental path so that the other person actually gets there. That preparation, paradoxically, is what I've used most later in meetings with adult stakeholders. I learned to defend a technical position without making it dense, to explain trade-offs with examples, to accept questions that pulled me off-script. I used to be afraid of saying "I don't know, I'll look into it." Now it's one of the phrases I use most, and I discovered that it doesn't make you look weaker, it makes you look more trustworthy.

The side cases are the third side of the triangle. The latest thing that caught my attention was seeing how a hospital in my hometown still manages staff scheduling and medical equipment tracking with manual processes. It's almost symmetric to what I do today, translating Excel into a system, but in a domain I know from bioengineering. It's not a project yet, it's a conversation. The logic I follow is the same as always: understand the pain first, see if it can be eased with technology, and decide whether it's worth building. If it goes through, everyone wins. If not, I keep it as a learning.

If I had to be honest about what I lack the most, it's not technical. It's communication. My English still isn't at the level I want for long meetings with international teams, and sometimes that makes me hesitate at moments when I'd have something to contribute. I'm building my leadership soft skills in parallel, but I still feel more comfortable being the one who executes than the one who decides for others. And public visibility I just don't have: until recently my only channel was LinkedIn and one-on-one conversations. This blog is part of changing that. The idea isn't to present a finished profile. It's to document the journey while it's happening.

---

Four years after accepting an offer I didn't fully understand, I still feel like I'm learning without a manual. But it doesn't scare me anymore. I learned that the manual doesn't exist for anyone, and that the method I brought from bioengineering, breaking down the problem, listening to those who know, iterating against reality, works in any domain where the user's pain is real.

If any of this resonates with your path, the one you're on or the one you're hesitating to start, write to me. The best lessons of these four years came from back-and-forth conversations.