What a Business Analyst Does (And Why Your Business Probably Needs One)

by Jean-Eric Plamondon | 11 Nov, 2025 | Business, Streamlined Processes

The short answer: A business analyst helps you understand how your business truly works, then helps you build a better version of it. That means mapping the current state, designing how you want things to run going forward, translating that into clear requirements for developers, and testing that the solution actually works.

If you look at the official North American industry codes for what my firm does, the closest designation is “business analyst.”

But I almost never use that term, because most people don’t know what it means.

Most business owners have heard the term business analyst, but very few could explain what one actually does.

And honestly, I don’t blame them. The title sounds technical, abstract, and painfully dry. It brings to mind corporate IT departments, not the day-to-day realities of an established business trying to grow without breaking.

So let me explain it in a way that’s practical, grounded, and useful for you as a business owner.

A business analyst helps you understand how your business truly works. Then they help you build a better version of it.

Not in theory.

Not in PowerPoint.

But in real life, where customers are waiting, employees are tired, and the machine has to keep moving.

Here’s what that looks like in practice.

We Help You See What You Can’t See from Inside the Business

When I walk into a company, I’m not looking for who’s doing what wrong. I’m looking for how the system behaves.

Most businesses don’t struggle because of bad people or bad intentions.

They struggle because:

• Processes evolved in strange, “Frankenstein” ways over time
• Everyone is doing what “works” (but not the same way)
• Tools and software were added as Band-Aids
• Workarounds quietly become “the way we do it”
• No one can see the entire system, only their part of it

Our first job is to map the current state.

We ask questions like:

• What are you really doing today?
• What depends on what?
• Where do things break or get dropped?
• What exists only because something upstream doesn’t work?

People often say, “It’s complicated… well, it depends…”

And they’re right. That’s exactly why a business analyst is valuable.

We make that complexity visible.

Once you see the system clearly, you can finally fix it.

We Translate Chaos into Clarity

Most operators explain their work like a long sentence with eight side-comments and three exceptions.

Our job is to turn that into something simple and visual.

We do that through process mapping – using a whiteboarding program to sketch out how your business operates.

This means taking every “it depends” and turning it into a clear decision point.

When I show a finished map to an owner, the most common reaction is:

“Wow. I wish I had explained it that clearly.”

This clarity creates alignment.

Your team finally speaks the same operational language.

We Help You Design the “Future State” of Your Business

Understanding today is only step one.

Our real value is helping you define how you want things to run going forward.

This includes:

• Streamlining workflows
• Eliminating unnecessary steps
• Improving handoffs between departments
• Clarifying roles and responsibilities
• Fixing or replacing broken systems
• Automating things that should have been automated years ago
• Designing operations that can scale

Think of it as architectural work for your business.

Before you build anything, you need a blueprint.

Otherwise, you’re just digitizing chaos.

Don’t automate chaos.

Fix the system first.

We Bridge the Gap Between Owners, Operators, and Developers

Most software projects fail for one simple reason:

The business wants one thing.
The developers build something else.

A business analyst sits in the middle so that doesn’t happen.

They take the future-state vision and translate it into crystal-clear requirements that technical teams can build without losing context, intent, or nuance.

We do this by translating it into what we call “user stories.”

A user story is simply a short narrative that explains:

• Who is doing something
• What they’re trying to do
• When they are taking these actions
• Why they need to do it
• And what the outcome should be

This prevents costly misunderstandings, rework, and the dreaded “but that’s not what we meant.”

It also helps ensure that developers don’t reinvent workflows, miss critical edge cases, or optimize for the wrong thing.

We Make Sure the Solution Actually Works

Once something is built—whether it’s a new workflow or a software feature—we test it against reality.

We look for:

• Does this solve the real problem?
• Does it create any new ones?
• Is it intuitive for the team?
• Does it deliver the business outcome you actually want?
• Will this still work when you’re 3x or 10x bigger?

Then we train your team, help them adopt it, and support you through the transition.

And once the dust settles?

We look for the next bottleneck, and we do it again.

Common questions

What does a business analyst do first?

They map the current state. That means asking what you’re really doing today, what depends on what, where things break or get dropped, and what exists only because something upstream doesn’t work.

Do businesses struggle because of bad people?

Most don’t. They struggle because processes evolved in “Frankenstein” ways, tools were added as Band-Aids, workarounds quietly became “the way we do it,” and no one can see the entire system, only their part of it.

What is a user story?

A user story is a short narrative that explains who is doing something, what they’re trying to do, when they’re taking these actions, why they need to do it, and what the outcome should be. It turns the future-state vision into requirements developers can build without losing context.

Why do so few business owners know what a business analyst does?

The title sounds technical, abstract and painfully dry, and it brings to mind corporate IT departments, not the day-to-day realities of an established business. That’s why I almost never use the term.