I spent my first two years at Integrated Units as a business analyst, which mostly meant sitting in customer calls, writing down what people wanted, and turning that into documents other people built from. I was good at it. I also had no idea, for most of that time, that I was already doing half of a product manager's job. I just didn't have the authority that was supposed to come with it, and nobody had told me the other half existed.
The part of the job that isn't in the title change
The actual shift from analyst to PM didn't happen the day my title changed. It happened months earlier, the first time a stakeholder asked "should we build this" instead of "can you write this up," and I answered instead of escalating it. Nobody assigned me that moment. I just didn't say "let me check with someone," and the thing I said turned out to be right often enough that people kept asking me directly instead of going around me.
That's the part nobody tells you: the title is a lagging indicator. By the time Integrated Units called it a promotion, I'd been making product calls (what to build, what to defer, which customer request was a symptom of a bigger problem) for months without the word "manager" attached to any of it.
Nobody hands you the authority. You take small pieces of it, quietly, by being right about the decisions nobody else wanted to own, until the title just catches up to what you're already doing.
What actually changed, once it was official
- I started owning outcomes, not documents. A requirements doc is done when it's written. A product decision is done when it ships and works, a much less comfortable definition of finished.
- I had to defend "no" out loud. As an analyst, saying no to a stakeholder request meant someone more senior said it for me. As a PM, it was my sentence to say, in the room, to someone's face.
- The customer calls stopped being about capturing requirements and started being about testing whether my own assumption about the problem was even right.
Moving Integrated Units toward subscriptions and taking Vodlix to enterprise clients both started as "just writing up what the customer asked for," and both only worked once I stopped writing up the request and started arguing with it.
What I'd tell someone making the same move now
Stop waiting for the title to grant you permission to make product calls. Start making small ones, visibly, on things nobody else wants to decide (which bug gets fixed this sprint, which feature request is actually three different requests wearing one ticket). Be right often enough, in public, and the title stops being a gate you're waiting behind and starts being paperwork that catches up to a job you're already doing.