Becoming a Product Manager rarely starts with the title
Sometimes people ask me what they should study before moving into Product Management.
There are definitely many resources on the topic.
Books. Frameworks. Discovery techniques. Roadmaps. Prioritization. Those are all useful. But looking back, I do not think those were the things that made the biggest difference in my own transition. The bigger shift happened earlier, inside the work I was already doing.
I started my career as a software engineer back when I worked at U-Hopper. Over time, I found myself spending more time talking to customers, coordinating work, helping my teammates understand problems, and discussing priorities. In part, I liked it, and in part, it was necessary.
The title changed later, but the transition had already started. I only understood that later.
Product thinking starts with different questions
The biggest change was not learning new tools. I was becoming interested in different parts of the work.
What changed was where my attention went.
Over time, I realized I wasn’t spending less time thinking about implementation. I was spending more time thinking about the decisions that happen before implementation begins.
What problem are we actually solving? Why now? What makes this worth doing? What happens if we decide to wait? What are we choosing not to do instead?
The implementation still mattered. I still enjoyed it. But I was becoming just as interested in the decisions that shaped what should be implemented in the first place.
Those questions slowly changed the way I looked at engineering work. Not because implementation became less interesting. But because understanding why a decision was being made became just as interesting as understanding how to implement it.
Communication becomes part of the job
Another thing that changed was communication. And I’m not talking about presentations or product updates.
As an engineer, I was used to explaining how something worked or why a certain implementation made sense. Over time, the communication became different. It was more about making sure people were looking at the same problem, with the same constraints in mind.
That meant collecting information, connecting discussions that were happening separately, and making trade-offs explicit before the team moved too far into the solution.
It was not communication around the work. It was part of the work itself.
Product judgment develops before product ownership
One misconception about Product Management is that judgment comes with the role. But I think the opposite is often true.
One of the best ways to build product judgment is simply by talking to people already making product decisions. Not to learn the answers. To understand how they think.
What mattered was not only asking better questions, but observing how experienced product people answered them.
How they separated real requirements from preferences. How they weighed customer urgency against long-term product direction. How they decided when a trade-off was acceptable, and when waiting was the better choice.
Those questions can be explored from almost any role.
Engineers, designers, customer success, support, and sales all encounter them every day.
The title simply gives someone more responsibility for answering them consistently.
The title often arrives last
Becoming a Product Manager didn’t feel like switching careers. It felt more like formalizing a way of thinking that had already been developing for years.
Looking back, I don’t think the change started when I got the title.
It started when I became as interested in why a decision was being made as in how the solution would eventually be built.
I have seen the same pattern in Product Managers I’ve worked with and respect.
They did not suddenly become curious when they got the role. The curiosity was already there.
