📅 A Day in the Life of a BA

Alarm goes off. Before I even get coffee, I'm checking my phone. Slack. Email. Any fires overnight?

There it is. A message from the Product VP at 11 PM last night: "We need to pivot the entire roadmap. Customer feedback changed."

My stomach drops. We're three weeks into a five-week sprint. The team committed to the current direction. Now this.

I draft a response: "Let me understand the customer feedback. I'll analyze impact and have a recommendation by 10 AM." Then I drink my coffee and think about how to approach this sprint planning call in an hour.

I jump on a call with the customer who triggered this pivot. 30 minutes of good questioning gets me to the real issue.

I document this and prepare to communicate it to the team and leadership. No panic. No wasted week pivoting. Just a refinement.

The team is gathered. I can see some anxiety—the Slack message about the pivot hit them too.

I start by explaining what the customer actually needed, why it's NOT a full pivot, and what we need to change (minimal). The relief is visible.

I explain: "This is part of building software in the real world. Customers don't always know what they want until they see it. Our job is to listen, adapt, and keep building. The customer isn't changing their mind— they're giving us clarity."

We reprioritize. Two of the current stories get modified. One gets pushed to next sprint. The team commits to the adjusted goals.

A developer pings me: "What does 'user should be able to manage their preferences' actually mean? What preferences? How many? Can they export?"

This is the moment where I realize my user story was too vague. My fault.

I spend 45 minutes clarifying this ONE user story. I talk to the product team, I look at similar features in competitors, I review the customer feedback. Then I rewrite the story with specific acceptance criteria:

The developer responds: "Perfect. Now I can build this."

I ordered lunch an hour ago but forgot to eat it while on back-to-back Slack conversations. Now it's cold.

I heat it up and eat at my desk while reviewing test cases for the feature going to UAT next week.

Finance says: "We need a new billing feature. Customers are asking for it."
Sales says: "No way. Billing is too complex right now. We need to focus on performance."
Product says: "Both matter. But we can't do both this quarter."

I'm in a meeting with all three. And they all look at me expectantly.

I don't solve it in the meeting. Instead, I say: "Let me gather data. Finance—how many customers asked for this? Sales—what impact is performance having on deals? Product—what's our technical runway?"

I commit to a detailed analysis by end of week. They agree.

A feature I worked on three months ago just launched to production. I get a Slack message from a customer:

I just stop for a moment. This. This is why I do this.

This moment is why I tolerate the chaos, the ambiguity, the conflicting stakeholders, the unclear requirements. Because sometimes—not always, but sometimes—you get to actually make someone's work life better.

I forward the message to the team and write: "This is what we built for. Great work everyone."

I review my list for tomorrow: UAT meeting with Support team, finance analysis completion, backlog refinement, two 1-on-1 calls with stakeholders.

I've got 5 Slack messages waiting for responses. 12 emails. One JIRA ticket marked urgent that I haven't looked at yet.

But that's okay. That's the job. That's why we exist—to navigate ambiguity, solve problems, and help teams build things that matter.

I close my laptop and think about the day:

On the surface, it was chaos. But when I look at it this way, it was actually productive chaos. I moved things forward. I prevented mistakes. I helped the team be effective.