What Business Analysts Can Teach Product Managers About Stakeholder Alignment
When people talk about what makes a great Product Manager, the usual suspects show up: product sense, customer obsession, prioritisation frameworks and so on. All important, no doubt.
But having worked as a Business Analyst for a few years now (often side by side with product managers) I’ve realised there is something else that makes or breaks product success: alignment. Quiet, behind-the-scenes, and often overlooked alignment. And it’s something BAs do really well.
Product Managers and Business Analysts tend to be in the same rooms, working side-by-side and talking to the same people but when it comes to stakeholder work, the line between them gets blurry very fast.
Here are a few key lessons in stakeholder alignment that I believe Product Managers can benefit from.
Make the implicit, explicit
When disagreement arises within a team, its usually rooted in misunderstanding. Most of the time, your teams are not arguing - they’re operating on totally different assumptions alltogether.
What does “done” mean? What does "success" look like? What are we not doing in MVP? Why is that feature suddenly considered a priority when no one asked for it? I can't tell you how many times I’ve sat in meetings where people were nodding along, only to discover weeks later that we were all thinking completely different things.
As a BA, you learn to get very good at surfacing that which is unspoken. Beyond the surface level meaning of whatever the Jira ticket say to what it actually means. This skill in particular - asking (sometimes seemingly obvious) clarifying questions, reflecting back what you’ve heard and checking for gaps - is vital for Product Managers.
Yes, it risks making you feel like the least informed person in the room. But it saves time, prevents tech debt and spares your team endless rework. Sometimes, the death of your ego is a small price to pay for avoiding the sunk cost of a misunderstanding.
"Sometimes, the death of your ego is a small price to pay for avoiding the sunk cost of a misunderstanding."
Alignment isn’t a one-off thing
There is this notion that once you have set the correct expectations, asked all the right questions and got the sign-offs, alignment is done. But this couldn't be further from the truth.
Alignment isn’t a one-and-done checkbox - it’s a rhythm. It shifts constantly as people’s priorities change, as new stakeholders appear, or when half the team quietly forgets why they’re building what they’re building in the first place. Without ongoing effort to keep teams aligned, momentum can be lost fast.
I have learned to think of alignment not as a milestone, but as a continuous process - one built around feedback loops, regular check-ins and small adjustments as new information comes in. Like birds flying in formation, each person moves individually and also in sync with the rest of the group. Daily and weekly clarity on both short-term goals and the bigger picture is what keeps everyone flying in the same direction.
It sounds obvious, but this kind of steady re-alignment is what keeps teams from drifting completely off course.
“Alignment isn’t a checkbox. It’s a rhythm.”
What you do not build matters as much as what you do
In almost every project there will be more ideas, opinions and potential rabbit holes than your team is capable of chasing. How you chose to handle the ideas that do not make the cut is just as impactful as how you engage with those that do
As a BA I have often found myself politely shelving side-quests disguised as urgent requests and as I am pivoting into product I see this skill as essential. Beyond simple time management and practicing backlog hygiene, the ability to say "not right now" helps project teams focus, manage expectations and maintain the clarity needed to deliver what actually moves the needle
Speak both languages
One of the most underrated parts of my role has been acting as translator: between business goals and technical constraints, between high-level strategy and the backlog items that drive each sprint. Although I'm not a language translator in the traditional sense, but it often feels like the same job. The language of the business and the language of the tech team can differ - sometimes drastically - and bridging that gap is what keeps things moving.
It’s not always easy. But being able to jump on a call with developers, then turn around and explain the trade-offs in plain English to stakeholders, who aren't concerned with the latest tech stack but just want it done, is a superpower.
Product managers need this too. In fact, some of the best PMs I’ve worked with are the ones who know how to listen carefully, translate clearly and keep conversations flowing both ways up and down the workstream.
Final thoughts
Stakeholder management doesn’t get as much attention as roadmaps or OKRs — but without it, none of those things land.
The truth is, business analysts spend a lot of time doing exactly what product managers need to do: making sense of competing inputs, finding clarity in chaos, and helping people row in the same direction.
As I transition into product, I know I still have plenty to learn. But I’m also bringing a toolkit which is already shaped by that alignment mindset and I genuinely think it is one of the most overlooked assets in effective product work.
