Every week someone announces the end of a role. The end of the product manager. The end of the designer. The end of the engineer. After all, every day new AI tools show up that replace many of the tasks these roles perform, like discovery, prototyping, and coding.
But what is a role, really?
We often describe a role by its day-to-day tasks. That, however, isn’t the most effective way to do it, because tasks change as new techniques (Agile, TDD, etc.), new technologies (internet, mobile, AI, etc.), and new tools (Hotjar, Figma, Cursor, etc.) come along.
The most effective way to describe a role is by its mission, its purpose, its objective, not by its tasks.
Take a CEO, for example. Their mission is to lead the strategy and long-term vision of their organization, and they do that through many tasks such as defining and communicating vision and strategy, hiring and leading people, establishing and nurturing the organizational culture, attending meetings, sending emails, visiting customers, and so on. The tasks change over time. The mission stays.
When we look at a product development team, there are three essential roles.
Each of these missions is a responsibility for questions someone needs to answer, and those questions don’t go away when the tool changes. That’s why no technology eliminates these roles.
What technology changes, and AI is changing fast, is the cost of each step along the way. Prototyping got cheap. Implementing got cheap. Anyone on the team can spin up a working version of an idea in hours. The bottleneck moved from building to deciding. With dozens of explorations happening in parallel, someone needs to decide what deserves to become product, how the pieces fit into a coherent whole, and what to discard. The questions stay the same. What changed is where the people answering them spend their time.
This also explains why “let’s get rid of role X” is usually a mistake. When a company eliminates the role, the mission is still there. The question still needs an answer, now with no one responsible for it. And along with the role, the company abandons the accumulated discipline of that function, the practices already tested, the mistakes already made and learned from.
The result of killing one or more of these roles is usually the return of an old acquaintance: the feature factory, that way of operating where the team ships feature after feature without anyone asking whether they should exist at all.
The boundaries between roles, those are indeed getting more porous. A product manager who prototypes, a designer who writes code, an engineer who talks to customers. This is welcome, because it makes the team more cohesive, and AI tools have accelerated that cohesion. But “porous boundaries” is different from “abandoned mission.” Each person can move between the three missions, as long as there’s always someone responsible for each one.
In 2025, I experimented a lot with vibe coding tools. I used to say I was back to programming! I built a to-do app and then a virtual astrologer with a conversational web interface. I was covering all three missions. Late last year, in a conversation with Anderson Borges, whom I’d worked with at Conta Azul, he as CTO and I as CPO, we decided to join forces to explore this disruptive moment we’re living in product development, thanks to the many AI tools showing up.
Even though I have a degree in Computer Engineering and coded a lot early in my career, I ended up focusing more on product management, on the mission of creating products that solve people’s problems the right way while generating results for the business. Anderson always focused on engineering and engineering leadership, on the mission of building products that work, scale, and can evolve.
It was with that clear division of the three missions that we evolved the virtual astrologer from web to WhatsApp, and then created ReveLumi, a research agent on WhatsApp capable of running qualitative research autonomously.
The three missions are still there, whether it’s a single person, like when I started exploring vibe coding, or ReveLumi today, where Anderson and I split the three missions. With Anderson owning the engineering mission and splitting the design mission with me, I’m freed up to go deeper on the product management mission.
Tools change the way we work. But as long as there’s product to build, the three missions will keep existing and will need to be fulfilled. Making sure the team builds what drives results. Making sure the solution solves the problem the right way for whoever uses it. And making sure the solution works, scales, and can evolve.
In a world where AI levels execution, deep knowledge of your customer is the one asset your competitor can’t copy. ReveLumi was built exactly for that. Check it out at revelumi.com.
Netflix knows everything about us. And we can’t find anything to watch.
That’s this week’s topic on my new newsletter, Listen to Decide, where I write about the importance of listening to customers, techniques for doing it better, and what we’re learning while building ReveLumi. All with one goal: making better decisions from real conversations.
I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.
At Gyaco, we believe in the power of conversations to spark reflection and learning. That’s why we’ve created “Produto em Pauta” podcast, with new episodes every Thursday.
The main series is called Mentorias: coaching conversations with product professionals, built on the idea that one person’s questions are often the questions of many others. We explore concrete challenges and turn experience into practical insights you can apply in your own context.
Available on YouTube and Spotify. Recorded in Portuguese, with English subtitles on YouTube.
Do you work with digital products? Do you want to know more about managing a digital product to increase its chances of success, solve its user’s problems, and achieve the company objectives? Check out my Digital Product Management books, where I share what I learned during my 30+ years of experience in creating and managing digital products:
