Read the opening of chapter 1
The opening of chapter 1, exactly as printed.
Chapter 1: From Task List to Judgment Calls: What the Job Actually Looks Like at This Level
Dana has three tabs open before her second coffee finishes brewing. One is a Slack thread from the merchandising lead, who wants a checkout banner changed before a flash sale launches in six hours. Another is a Jira ticket from the fulfillment team, flagging that the return-authorization report has been quietly overcounting refunds for at least eleven days — nobody's sure exactly how long, or how much revenue got misreported to finance because of it. The third is a half-finished user story for a loyalty-points redesign that the VP of product asked her to "just get a first draft of, no rush" three weeks ago, and which is now, suddenly, on Thursday's roadmap review.
None of these are hard problems in isolation. All three are true at once, on the same morning, with a sprint that was already fully allocated. That's the part the entry-level version of this job doesn't prepare you for: not the individual tasks, but the constant, simultaneous demand on your judgment about which one actually matters right now, and by how much.
You already know the basic shape of the role: decode a business problem, optimize the process or system around it, document what you find and what you decide, communicate it to whoever needs to hear it in the language they speak. That framework holds up fine at this level; nothing here replaces it. What changes is that you stop moving through those four functions one at a time on a single, contained project and start running several of them in parallel, on unrelated problems, for stakeholders who don't know or care what the others are asking for. Decoding the refund-report bug and communicating the checkout-banner decision aren't sequential steps in one story anymore. They're two separate demands landing in the same hour, each with its own stakeholder, its own urgency, and its own cost if you get the sequencing wrong. The mechanics you learned are the alphabet. This is what it looks like to actually write sentences with them under pressure, and increasingly, to write different sentences depending on which specialization of the role you're sitting in.
Keep readingShow less
"Business analyst" is doing a lot of work as an umbrella term. In practice, once you're past your first year or two, the day-to-day starts diverging based on which flavor of the role you're in — and it's worth naming the split explicitly, because it shapes what "a normal day" even means for you.
A **business intelligence analyst** spends a disproportionate share of the day inside data: building and maintaining dashboards, validating data models against source systems, chasing down why two reports that should agree don't, and translating a trend line into a recommendation someone in leadership will act on. The requirements work is still there, but it's requirements about *what the business needs to measure* rather than what a feature should do. You're closer to the warehouse and the query than to the sprint board.
A **business development analyst** lives further from the codebase entirely. The day skews toward market and competitor analysis, evaluating partnership or vendor opportunities, and modeling out whether a proposed business direction (a new pricing tier, a market expansion, a channel partnership) actually pencils out. Stakeholder management here means executives and external partners more than engineering leads, and the deliverables look more like a business case than a backlog item.
An **enterprise or technical business analyst** sits closest to the systems side. You're working through integration constraints, system architecture implications, and technical feasibility questions in real detail — not just flagging that something might be hard, but understanding *why* it's hard well enough to negotiate scope with an engineering lead as something close to a peer. This is the flavor where the line between BA and product owner, or BA and solutions architect, gets genuinely blurry.
A generalist BA role, especially at a smaller company, can still touch all three in a given week. But if you're choosing where to specialize, or trying to read a job posting accurately, this is the axis that predicts your calendar — not the industry, not the seniority label, but which of these three centers of gravity the role is built around. A BI-analyst posting that lists "SQL, dashboarding, statistical literacy" first and "stakeholder workshops" fourth is telling you something true about the job.
The specializations aren't walled off from each other, either, and the friction between them is its own recurring source of work. A loyalty-points redesign like the one sitting in Dana's backlog needs a business-development read on whether the new tier structure actually improves margin, an enterprise/technical read on whether the points ledger can be rebuilt without breaking three downstream integrations, and a BI read on which existing engagement metrics will even tell you whether the redesign worked six months out. On a mid-size team, that might be three different people who each own one lens and need someone — often the generalist BA on the project — to reconcile their answers into a single recommendation. On a smaller team, it might be one person switching hats three times in the same meeting. Either way, knowing which lens a given question requires, and not answering a technical-feasibility question with a market-sizing instinct, is itself part of the judgment this level demands.
Back to Dana's Tuesday. The instinct at the beginner level is to treat every incoming request as something to triage by how loudly it's being asked — whoever's most upset gets handled first. That instinct gets you burned at this level, because volume and urgency are not the same axis, and neither one alone tells you what to actually do.
