I was doing this work before I knew what to call it.

I started The Product Engineer after reading a Product Engineer job description at DOJO AI. It brought together technology, business and design—the same combination I had spent years trying to practice, usually across teams and roles that kept them apart.

It felt like the market was signaling that this multidisciplinary profile was needed. I don’t know the reasons yet: maybe how fast AI is changing what one engineer can do, maybe the end of the zero-interest-rate era in the US.

Then I read Antonio Alegria, who was hiring for that role, trying to sum it up in a public post: an engineer who also likes building product and “genuinely likes sitting with customers to understand what’s actually going on,” as rare as “looking for a specific Pokemon in the wild.” His attempt to name it made me see my own path.

I trained in technology, went looking to understand business, and came to see design—user-centered design and service design—as practices anyone who wants to build a business needs.

Right now everyone is asking what a software engineer is for, now that AI coding agents have supposedly changed everything.

I still love seeing something I built work in the command line or in the IDE, and I don’t know how much of that hands-on work will change, or whether engineers will simply carry more of the cognitive load: deciding what to build, weighing trade-offs and judging the result.

Years ago I made a shift that I keep coming back to: I started caring more about which problem to solve, and whose problem it was, than about how to solve it with technology.

It began at Potere, the company I founded. I had followed an opportunity from the technology side, and ended up learning about business models and going out to find where the problems actually were. That changed everything for me.

When I had to show stakeholders the problem, who had it and which one I thought we should solve, the strongest evidence was always the same: talking to someone who had the problem and watching the cycle validate itself—or not, when it showed the problem wasn’t worth solving for the business.

The work felt complete in a way it hadn’t before. I could see its direct effect on people’s lives, and remembering the people I’m trying to help is what makes the work fulfilling.

That is why it excites me to see the same practices come back in what other engineers and teams describe. I want to understand what this asks of engineers today, and which skills help them make the same shift.

The DOJO role is one signal, not an answer. I want to understand whether companies are asking engineers to connect business, design and technology more often—and what that responsibility looks like in practice.

How I got here

I’ve loved software as a craft for as long as I can remember. I made time to try new libraries and build my own projects.

I went to CPqD to learn RUP and work on a large billing product for telecom and utilities. Working across teams showed me what it takes to build and maintain software at that scale.

Later, I left a stable job to start a company. I found myself learning the parts of the work I hadn’t known how to do: figuring out which problem people actually wanted solved, and how a business could sustain the solution.

I looked for ways to do that with more than a founder’s hunch—business model work, Customer Development and Lean Startup. Design felt natural to me because it gave us a way to learn with people, through co-creation and prototypes, one step at a time.

My time at IBM Global Business Services was one chapter. Later, in IBM Software Group’s product organization, I worked on Watson IoT Platform, helped spread IBM Enterprise Design Thinking from its inception, and led IBM Design Studios São Paulo.

I also worked with business teams on pre-sales and initiatives with Fundação Dom Cabral and Saint Paul Business School. Outside IBM, I helped bring design thinking into the Brazilian technology community through TheDevConf.

Connecting these disciplines was rarely straightforward. I often had to translate between technology, business and design, while organizations tended to keep them in separate silos. Even inside large companies, I saw intrapreneurship programs and practices borrowed from startups take hold, yet the silos stayed strong.

So when I saw Product Engineering describe that kind of end-to-end work as a role, I recognized something familiar. I had been trying to do it for years; now I want to understand why the role is appearing, where the demand is real, and what it could make possible.

Questions I want to answer

I approach them with a cycle I practiced at IBM: Enterprise Design Thinking’s Loop—Observe, Reflect, Make. I observe roles, products and people’s experiences; reflect on what the evidence may mean; then make the learning tangible through examples and proposals. What we make gives us something new to observe, so the inquiry keeps moving.

The four Field Notes acts—define, prove, explain and propose—give this inquiry its shape. I’ll use examples and evidence to make the practical work visible, while being clear about what I can and can’t conclude. I hope readers come away with a better sense of what they already know, what they might want to learn, and what end-to-end product work could look like in their own teams.