Going from being a developer to a product manager seems, at first glance, a logical change: you already know the product, you know how to build it, you understand the logic behind the system… How difficult can it be?
Spoiler: it’s difficult But not for the reasons you imagine.
For years, I worked as a developer, solving technical challenges, focusing on efficiency, architecture, and code quality. Until one day, the opportunity to become a Product Manager (PM) arose. It sounded logical: I knew the product, the team, and the stack. Why not?
What I didn’t imagine was that this change would change not only my routine, but also my way of thinking.
Think about the problem before the solution
As a developer, your day revolves around solving technical problems: performance, bugs, architecture design. As a PM, your day revolves around finding out what the correct problem is and that can be disconcerting.
Suddenly, it’s no longer about writing code, but about asking questions like:
- Does what we are building really solve anything?
- Is it worth investing weeks in this functionality?
- Is the problem technical, business, or perception?
As a dev, I often received tickets that were already defined: “this is what needs to be built.” As a PM, my first big change was realizing that The solution is not the beginning, but the end of the processNow I have to start by understanding what problem we are solving and, why it matters.
This meant talking more with users, with business, with support… and realizing that often, the problem that seems obvious isn’t so obvious.
Change the language (and the silences too)
In development, many of us understand without speaking. A good PR or a comment in Jira or Github is enough. But as a PM, you need to talk, negotiate, explain, justify. Your job now is to be the bridge between technical teams, design, stakeholders and users.
As a developer, you talk in tickets, commits, and endpoints. As a PM, you need to talk to users, stakeholders, sales, support, marketing, and then translate that into a coherent story for your technical team.
And not everyone speaks “tech.” Learning to Translate technical context into business value, and vice versa, was one of the greatest and most valuable challenges. I learned that it’s not about simplifying, but about finding a common language among all.
Prioritizing is a mix of art and strategy
As a developer, I assumed prioritizing was a matter of logic: more impact, less effort. But as a PM, I learned that prioritizing involves:
- Negotiate limited resources.
- Understanding business timing.
- Knowing when to say no (even if there is a beautiful Figma or Canva waiting).
- Align many different voices without losing focus.
In practice, prioritizing is:
- Decide what NO It is going to be built (although it is “almost ready”).
- Decide what is worth doing even if it is risky or unpopular.
- Justify those decisions with data, context, and vision.
Spoiler 2: Sometimes you don’t have any of those elements. Still, you have to decide.
There isn’t always perfect data, and often you have to make decisions with what you have.
Learning not to have all the answers (and that’s okay)
As a developer, I was trained to provide technical answers. I felt uncomfortable when I didn’t have an immediate technical solution. As a PM, I had to learn to live in constant uncertainty. I discovered that Living with uncertainty is part of the role. And that’s okay.
Not knowing is normal. The important thing is knowing how and with whom to discover the answer. Make informed decisions (even if they are not 100% certain).
It’s worth it?
A lot. Switching from developer to PM taught me to see the product as a whole. It’s allowed me to see it from a more comprehensive perspective. To think about impact, business, real users, growth, and sustainability. I stopped measuring success in lines of code or closed sprints, and started measuring it in value delivered.
It’s not an easy change, but it’s deeply rewarding.
In conclusion
This shift isn’t for everyone, but if you’re interested in understanding the “why” of what you build, working with multiple perspectives, and leading with vision rather than code, it can be a transformative step.
If you’re thinking about taking the plunge, my advice is: Do it with an open mind, lots of questions and zero ego. And if you’ve already made the leap, you’re not alone. Many of us, even after more than 11 years in the role, are still learning as we go.
At ITJ, there’s room to explore. And there are also experienced people who, despite their experience, continue to learn every day, in case you need someone to talk to. ✌️
And you? What did no one tell you when you changed roles?
Indeed body teach u to think like a PM. But from where I see it, it seems to me that not just any programmer can be a PM because there are skills and competencies that have to be worked on to optimally achieve objectives. The analogy of thinking of it not as a product but as a process and a whole is very interesting.
Good entry. I relate, as I also faced the challenges of being a PM / PO in the past.
I really recommend you to read Marty Cagan collection.
*Inspired
*Empowered
*Transformed.
Marty is a seasoned product professional, who also set many pillars. Well.. he was able to put many notions PMs normally live into words and concepts.