Blank Page

It's been a while since I last wrote. They say it takes 21 days of repetition to build a habit, but dropping one takes just two or three. Funny how that works. I've always said it's easier for good things to go unnoticed. That bad things are sticky. That one equals seven (seven good things automatically destroyed by every bad thing that happens). I wrote about it in this post when I was at Factorial. Someday I'll revisit it, update it, and bring it here. But let me get to the point, I'm getting sidetracked… I like blank pages. I like that space. Some people hate it. I feel right at home. Going from "I have no idea what to do" to "I know kung fu." I love that feeling. And when I left Factorial, I knew I needed exactly that. A blank page with a lot left to write. Lucky me, shortly after leaving, and the little bit of noise I managed to make on both LinkedIn and here, people reached out. One of them was Genar. He was collaborating on Ticketdoor and put me in touch with the CEO, Toni. What they told me clicked instantly with what I was looking for: A small product Profitable. Self-sustaining on its own revenue With the need to scale And where there's a lot left to do After a few conversations, it was clear. The CTO position excited me. The challenge excited me. And working with Genar (someone I'd seen shine at Factorial but never had the chance to collaborate with closely) excited me. So, just days after leaving, I already had my next big challenge defined. That gave me enormous peace of mind. I got to enjoy a couple of months of disconnection knowing where I'd land at the start of 2026. Today marks one month at Ticketdoor. During this time I've tried to stay humble: listening, understanding, and figuring out where I could act. There's a lot to tell. Not all of it fits in this post. But I want to share what I see as the first important move I've set out to make: a small cultural shift that requires a change in mindset across the whole team. A team I'm enormously grateful to for how they've welcomed, supported, and helped me during this first month of the adventure. What follows is the document as I shared it with them. How we build product Why this document exists For years, the software industry has confused movement with progress. We've filled calendars with ceremonies, boards with tickets, and sprints with features nobody asked for. We've turned product managers into traffic controllers and engineers into spec executors. 2026 is a year of change. The industry will never be the same. The consolidation of AI is reshaping everything, and adapting is now vital for survival. We're no longer the only ones who know how to turn an idea into a digital product. AI knows. It might add bloat or need guidance, but it knows. Therefore, staying anchored as consumers of a ticket board that someone assigns to us, solving tasks during two-week sprints, is obsolete. An engineer in 2026 doesn't own a task, they own a problem. An engineer in 2026 has a horizontal view. They understand (or ask why). They challenge. They participate in defining the solution from the start. And they consume the data after development to make sure their product works. An engineer in 2026 has full ownership. Either we expand our boundaries, become more horizontal profiles, and apply all our human skills or AI will eat us. That's the hard truth. So it's time to experiment. This document is a statement of intent. A different way of working where product and engineering are partners, not client and vendor. Where communication flows without the need for daily meetings. Where solving the right problem matters more than shipping the feature on time. It's not a process. It's not a methodology. It's a compass 🧭. Our beliefs Problem before solution Every line of code we write exists to solve a real problem. If we can't articulate the problem, we shouldn't be writing code. Before the "what", we need to understand the "why". Who suffers this problem. How much it hurts. What happens if we don't solve it. How we'll know we solved it. Features are hypotheses, not deliverables. A feature that doesn't move the metric isn't a success (it's learning, at best). Who decides what Product owns the problem and the priority. Their job is to understand the business, listen to the user, and decide which problems deserve our attention. Engineering owns the solution and the quality. Our job is to propose the "how" and build with judgment. We participate in product design because we understand constraints and possibilities that others don't see. Nobody owns the ideas. The best ones win, no matter where they come from. Communication without ceremonies Information should flow without the need for recurring meetings. A well-written message, an updated document, or a two-minute video are often more effective than a thirty-minute call. Meetings exist to unblock, make complex decisions, or connect as a team, not to report status. If we can solve it async, we solve it async. A 2-minute video sometimes explains better than a 10-line paragraph. Use it when it adds value, not out of obligation. About rhythm We don't believe in false urgency. We believe in focus. Each quarter we bet on 2-3 important problems. Not 15 initiatives. Not an infinite backlog of "nice to haves". A few clear bets with room to do them well. Maintenance, bugs, and tech debt don't compete with product; they are part of the product. A system that can't be maintained serves no one. The Manifesto We solve problems, we don't ship features. Product defines the "what" and the "why". Engineering defines the "how". Async by default. Sync when it adds value. Few bets, done well. Saying "no" is part of the job. The best ideas win, no matter where they come from. If something's not working, we say it as soon as possible. This is not a bible It's a starting point. If something doesn't work, we change it. If we find better ways to work, we adopt them. What doesn't change is the intent: build product with judgment, respect everyone's time, and solve problems that matter.