Complex problems rarely
belong to a single discipline.
I started coding in technical high school, and that's where I realized I cared more about solving the problem than about the code itself. Over time that led me into UX/UI. Designing the logic of an interface felt a lot like programming, but with the user in the middle of it. At some point studying interfaces I started asking myself why not apply that same logic to physical objects, I wanted my design to reach past the screen. That's how I ended up studying Industrial Design at UNC.
Somewhere in the middle of all this, without really looking for it, I started teaching: first as a tutor at CoderHouse, then as a teaching assistant at the same school where I studied, and now in UNC's new UX diploma program. Honestly, it wasn't planned, it came out of needing to organize what I was learning. Teaching ended up being the way I understand something best myself.
Oh, and I'm also a pilot, but that's a story for another time.
Before studying design I'd already tried building three different products. None of them worked out the way I expected.
At 18 I built an urban mobility platform, kind of an Uber for local taxis and remises, right as Uber itself was just showing up in Argentina. It didn't take off, traditional agencies and the sector's unions didn't let it in.
The following year came Mozum, an app to digitize restaurant menus and let you call the waiter from the table. I dropped it thinking the pandemic would hit the restaurant industry so hard it no longer made sense to continue. What actually happened was the opposite: the pandemic was exactly why the digital menu ended up becoming standard across the whole industry.
And at 20, Herobic, a SaaS for gym management and training plan tracking that aimed to close the gap between gyms, trainers, and members. The product worked, but I didn't know how to execute going to market. Over time several platforms showed up solving the same thing, and those did well.
All three left me with the same lesson, even though I got there by different paths: identifying the problem is the easy part, executing the go-to-market is the hard part. (I go deeper into these in the articles.)
