BA, PO and PM are three different crafts

The difference hit me in the first week, and it was smaller than I expected. As a business analyst, when I didn’t know something, I went to people and found out. That was the whole move. Now I’m the one people come to for the answer.

I’ve officially been a product manager for about a month. Unofficially I’d been stepping in and out of product work for a while before that, the way you do when a team needs someone to hold the thing and you’re standing nearby. Either way, I’ve spent most of that month nerding out about the differences.

People usually frame these three as a ladder, and the more time I spend looking across them the less that holds up. What I keep finding instead is three genuinely different crafts, each with its own kind of excellence, each attracting a different sort of brain. Here’s what I’ve got so far.

Analysis is where you get to go deep

The thing I loved about business analysis is that you get to go as far into a problem as it will let you, and problems usually let you go further than anyone expects.

You sit with the person who actually runs the process rather than the one who owns it, and find out what they do on a Tuesday. You trace a value through four systems until you understand why two dashboards have never agreed on it. You notice the field everyone swears is mandatory sitting empty in a tenth of the records, and then you go and find out why.

Do that for long enough in one area and something useful happens without you planning it. You become the subject matter expert, having never once decided to. Nobody sets out to become the person who knows exactly how the permissions model behaves when someone moves between teams. You just spend enough time in it, ask enough irritating questions, and one day people start routing their queries to you.

That expertise is worth a lot and it’s genuinely hard to replicate, because it can’t be read anywhere. It only comes from staying put and paying attention, which is also why time served and real experience come apart so easily. Depth accumulates for whoever is willing to go deep rather than wide.

Ownership is about the right things at the right time

Product ownership adds a dimension I hadn’t fully appreciated until I watched it done well, which is timing.

There’s a real craft in making sure the right thing happens at the right moment. Not just what matters most in the abstract, but what has to land before another team’s dependency arrives, what can wait a sprint, what gets pulled forward because six people will be blocked otherwise.

The moment it clicked for me was watching someone deliberately promote a small, boring piece of work ahead of something far more valuable, because three other items were sitting behind it. Nobody thanked them for it. A month later that team was still moving while a neighbouring one had stalled on exactly the thing that had been skipped.

What makes the role appealing is that you don’t have to leave the detail behind to do it. A good product owner is still in the requirements, still shaping what an item actually means, still arguing about acceptance criteria. You get to prioritise and stay hands-on with the substance, which is a rarer combination than it sounds.

The satisfaction is a team in flow, and the feedback comes back in weeks, which is fast enough to feel responsive and slow enough to think properly.

Product management runs on hypotheses

Then there’s the part I’m in now, which is a different sport entirely and I find it genuinely exciting.

Product management is research, then a view. You go wide across customers, market, data, competitors and whatever else is going on, and out of that you form a hypothesis about what’s true and a vision for where this should go. A lot of that work is refusing to accept the request at face value and going after the problem underneath it. Then you test it. It proves out or it doesn’t, you learn something either way, and you iterate.

That loop is the fun of it. You’re allowed to have an opinion about the future and then go and find out whether you were right, which is a very different pleasure from establishing what’s already true.

Which brings me back to the flip I started with, because the change isn’t that the research stops. If anything there’s more of it. What changes is what it’s for. As an analyst I gathered information to close a gap in my own understanding, and I knew I was done when the gap shut. Now I’m gathering it to build a position I’ll be asked to defend and then act on, and there’s no equivalent moment where it’s obviously finished. You decide it’s finished.

The uncertainty doesn’t fully resolve either, which took some adjusting to. A lot of it depends on what people do when they finally see the thing, and no amount of diligence turns that into knowledge in advance. So you commit on thinner evidence than analysis ever asked for, and treat being wrong as information rather than as a defect.

Scope nests, difficulty doesn’t

The one structural thing I’d say is that scope does nest. What each role decides about sits inside the next.

But scope and difficulty are separate axes, and the diagram gets misread constantly on this point. A business analyst mapping how an enterprise system handles access, where one missed rule exposes the wrong data to the wrong people, is doing harder work than a product manager choosing between two button placements in an app. The wider role only functions because somebody else is holding the detail, and the quality of a wide decision is capped by the quality of the narrow knowledge feeding it.

Worth noting too, since it gets used as a stick: when a company runs product owner and product manager as separate jobs, that usually says something about the operating model rather than about the people. It tends to appear where teams get handed features to build rather than problems to solve. That’s an org design question and it isn’t fair to aim at anyone holding the title.

A better question than the title

If you’re trying to work out which of these you’re actually doing, the title won’t tell you. Two companies down the road from each other use the same word for jobs with nothing in common.

What I’d ask is what you’d be held responsible for when it goes badly. It’s the same instinct as listening for whether someone leads with their reasoning, pointed at yourself. Whether the solution didn’t do what it was specified to do. Whether the team spent six weeks on the wrong thing. Or whether the thing shipped, worked exactly as designed, and nobody wanted it.

Those three failures land on different people, and which one lands on you describes your job better than anything printed on the org chart.

What I’m enjoying most is that none of this makes the old craft less interesting. It just turns out there was a whole other one sitting next to it.