I started at Travelxp as a project manager. My job was to get the OTT platform live globally on schedule. I sat between leadership, engineering and design, took over the QA and release pipeline, and spent a lot of time clearing whatever was blocking the launch.
About a year later I moved into product. On paper the roles look close. Same teams, same tools, same meetings. In practice the question I was being asked changed, and it took me a while to notice.
The question changes
As a project manager, the question was mostly "are we going to deliver this, on time, at the agreed scope?"
As a product manager, the question became "should we be building this at all, and how will we know it was worth it?"
That sounds like a small shift. It meant that some of my strongest habits started working against me. A project manager who protects scope is doing their job. A product manager who protects scope without asking whether the scope still makes sense is shipping the wrong thing efficiently.
What carried over
A lot did, and I think people underestimate it:
| Project skill | How it helps in product |
|---|---|
| Running releases | You understand what's actually involved in shipping, so your plans are realistic |
| Managing dependencies | Roadmaps are mostly dependency problems in disguise |
| Talking to every team | You already know who to ask and how they like to be asked |
| Risk tracking | Turns easily into tracking assumptions and unknowns |
| Keeping leadership updated | Same skill, different content |
Engineers trusted me early in my product role partly because I'd been in the release trenches with them. I knew what a "small change" on the Smart TV app actually involved.
What I had to unlearn
Treating the plan as the goal. I used to measure a good quarter by how much of the plan we delivered. Now a good quarter can include dropping something halfway because we learned it wouldn't help.
Saying yes to keep things moving. In project work, unblocking people often means agreeing to things. In product work, a lot of the value comes from saying no and explaining why.
Waiting for requirements. Project managers usually receive the scope. Product managers have to go and find the problem, often with incomplete evidence.
Reporting status instead of outcomes. "Feature X shipped" was the end of the story before. Now it's the start, and the next question is whether anything changed for users.
How to show product thinking before you have the title
You don't need permission to start thinking like a PM. A few things that helped me:
- When a feature ships, look at the data a few weeks later and share what you see, even informally.
- In planning, ask "what problem is this solving?" politely and often.
- Sit in on support calls or read tickets. Bring one pattern to the product team.
- Write a short proposal for a small improvement with the problem, the evidence and a success measure.
That last one is basically a mini case study. If you're building toward a product manager portfolio, it's also exactly the kind of thing worth writing up.
Was it the right move?
For me, yes. I like the uncertainty of product work more than I expected to. But I'd tell anyone considering it that project management is a different job from product management, and in no way a junior version of it. The best project managers I know are very good at something I'm only average at, which is keeping complex delivery on track without drama.
If you're switching, keep that skill sharp. It will make you a better product manager, because a lot of product ideas die in delivery, and you'll be one of the few people in the room who sees it coming.