Read the opening of chapter 1
The opening of chapter 1, exactly as printed.
Chapter 1: What Is a Business Analyst, Really?
Picture this conversation. A bakery owner named Nadia wants an online ordering system for her shop. She sits down with a developer and says, "I just want customers to be able to order a cake for pickup, and I want to know when someone's paid so I don't start baking for free."
The developer nods and starts asking questions Nadia has never thought about. "Do you need real-time inventory sync? Should the payment be captured at checkout or authorized and captured on fulfillment? What's your refund policy for cancellations inside 24 hours? Do you want role-based access for your two part-time staff?"
Nadia has no idea what half of those words mean. She just wants to stop losing money on cakes nobody picks up. The developer, meanwhile, cannot build anything useful from "I just want it to work" — that sentence contains zero information about what "work" actually means in a system. Both people are smart, both are trying to cooperate, and they are still stuck, because they are speaking two different professional languages and neither one is equipped to translate for the other.
Keep readingShow less
That gap is where a business analyst lives. Not writing the code. Not running the bakery. Standing in the middle, making sure what Nadia actually needs and what the developer actually builds are the same thing.
A business analyst — usually shortened to BA — is the person whose job is to translate. Specifically: a BA takes what a business needs, in the business's own words, and turns it into something a technical team can actually build. Then the BA does the reverse translation too: taking what's technically possible, or technically difficult, or technically going to take six extra weeks, and explaining that back to the business side in terms they can act on.
That's the whole job, at its core. Everything else you'll learn about business analysis — the tools, the certifications, the meeting formats, the acronyms — is built on top of that one function. If you remember nothing else from this book, remember this: a BA exists to make sure that what one side of a conversation means is what the other side of the conversation hears.
Notice what the definition does not say. It doesn't say a BA writes software. It doesn't say a BA runs the business. A BA typically isn't the one clicking "deploy" and isn't the one deciding the company's five-year strategy. The BA's actual product is understanding — a shared, accurate, written-down understanding that both the business side and the technical side can point to and say, "yes, that's what we agreed on." That sounds modest. In practice it's one of the hardest and most valuable things anyone on a project does, because misunderstanding is the default state of any two people who don't share the same expertise, and understanding has to be actively built.
Before going further, it helps to clear out a few nearby job titles people confuse with this one, because the confusion isn't your fault — the roles genuinely overlap at the edges, and different companies draw the lines differently.
A business analyst is not a project manager. A project manager owns the schedule: who's doing what by when, whether the budget is on track, whether the team is blocked. A BA owns the meaning of the work itself: what's actually being built and why. A small team sometimes asks one person to do both jobs, which is part of why the titles blur in job postings, but the underlying skills are different. Managing a timeline and translating a requirement are not the same muscle.
A business analyst is not a developer, and doesn't need to know how to write production code to do the job well. A BA needs to understand technical constraints well enough to have an honest conversation about them — enough to know that "just add a login button" might mean building an entire authentication system — but the BA's job is to represent that constraint accurately to the business side, not to personally solve it in code.
A business analyst is also not just a note-taker or a report-writer, even though documentation is a real and necessary part of the job, which you'll see in the next chapter. Writing things down is how a BA makes the shared understanding durable — so it survives the meeting, survives someone forgetting a verbal agreement, survives a new team member joining eight months in and needing to know what was decided and why. But the thinking that goes into deciding what to write, which questions to ask first, and which stated request is hiding a different real need — that's the actual skill. The document is the output. The translation is the job.
You'll hear business analysts described as "a bridge between business and technology" so often in this field that it can start to sound like a throwaway phrase. It isn't, and it's worth sitting with the actual mechanics of what a bridge does, because the mechanics map onto a huge share of real BA work almost perfectly. It's worth being precise about what this framing is and isn't: the profession's own official definition is broader than software delivery — IIBA defines business analysis as enabling change by identifying organizational needs and recommending solutions that deliver value, not necessarily anything involving a technical build at all. Plenty of real BA work is pure process, strategy, or organizational-design work with no "technical side" in the picture. This book focuses specifically on the software-and-technology-delivery flavor of the role, because it's the most common entry point and the one this book's examples, tools, and interview prep are built around — not because it's the only shape the job takes.
