Lucas Cardoso

I'm a product manager who builds. While building the systems in this portfolio, I was also managing $15M in real estate sales and running 13,000+ yearly ad campaigns—which is why every system I build starts with the business model, not the architecture diagram. Six years in product and technology later, that combination—technical depth to make infrastructure decisions, product instinct to frame problems around user economics, and operator experience from managing P&Ls and leading sales teams—is what defines how I work. I don't hand specs to engineers and wait. I prototype, I validate cost models, I write the first version myself when the team is small enough and the problem is urgent enough.

At Styllus, an 80-person real estate brokerage in Brazil, I was hired as a growth PM and quickly became the company's entire technology function. There were no engineers. I was the PM, the architect, the developer, the person who trained the receptionist on the new system, and the person who got the call when it broke on a Sunday. That constraint shaped everything I believe about product work. When you're the only technical person in the building, you stop designing for elegance and start designing for operational survival—systems that validate themselves, surface errors before a non-technical operator has to diagnose them, and run without anyone needing to understand how they work. I built automated data pipelines, video rendering infrastructure, edge-optimized websites, and lead routing systems, all with one governing principle: the person who inherits this cannot be me.

What started as a summer internship at Solenis turned into an extended engagement through graduation—two products went into production, and the company kept me on to ship them. One of those products meant navigating architecture review boards and IT governance at a $7.3B enterprise, building a multilingual training platform for field teams who share devices across four countries. The through-line is the same at both ends of the spectrum: products succeed when they're designed for the operator, not the builder.

Most of my career has been as a solo operator. I'm now looking for a role inside a product organization where I can apply what I've learned about building from zero while developing the muscles you only build by working alongside other PMs, designers, and engineering leads.

I'm drawn to roles where the PM is expected to go deep: on architecture, on data models, on the technical decisions that shape what's possible. Product thinking grounded in real system complexity, not just user stories and prioritization frameworks.