I build digital products. Not just the interface. The thinking behind why it works, who it is for, and whether it is actually solving the right problem.

Over the years I have moved across agencies, multinationals, scale-ups, and freelance, building both B2B and B2C products. The work was always the same underneath: understand the problem properly and then build something that actually solves it.

For me, Product is communication. Every problem has a story: where it comes from, who it affects, how it plays out day to day, and every decision has one too. I've found that teams move faster and build better when the work is framed that way: not as tasks or tickets, but as something with a beginning, a tension and a direction. It also makes it easier to know when you have actually solved something, and when you have just moved the problem elsewhere.

I make decisions with data (I love diving into dashboards and playing around with tracking events), but I do not stop there. Numbers tell you where something is breaking, but rarely tell you why. That why usually lives in the small human details: the hesitation, the workaround, the thing nobody files a ticket about but everyone does anyway. There is always a real person on the other side of all of it, with a full day, a specific context, a level of patience already being tested before they even reach your product. Getting that in the same picture as the numbers is where I spend most of my energy, and it is usually where the commercial answer is too. Most problems turn out to be genuinely interesting once you get close enough to them.

Mostly, I like building things, not just thinking about them. I feel like something happens when you actually make something (even badly, even just to throw it away) that no amount of framing gives you. In the paradigm shift we're living through, the bottleneck has moved from production to decision, and I find that interesting rather than threatening. Anyone can generate now, and what matters is whether you can evaluate what comes out with real product judgment. I think that is also making the old role boundaries less relevant. Designer, PM, dev, whatever the title, what you actually need is someone who can tell a good decision from a bad one and move. That's what I am trying to be.