I graduated over a month ago as a software engineer (equivalent to masters degree), I'm pivoting to a Technical Business Analyst, I only have a 6 months software engineering internship as a relevant experience that I framed the BA side of it and also I made a BA personal project to enhance my profile a little bit more.

How is it possible to be hired for a remote BA or similar role as an entry-level? Is it very difficult? What strategies should I pursue?

I feed Claude meeting transcripts, data analysis and lots of information on the projects I work on. It outputs incredibly detailed and well formatted business requirement documents. They are better than what I would create, even though I’m the one that fed AI all of the info.

Is this necessarily a bad thing? It almost gives me impostor syndrome even though I provided all of the context. Does anyone else feel the same way about any documentation AI generates for them?

PM here. A few months ago I got handed a 17-page functional spec that "looked fine". Instead of asking AI to rewrite it, I tried the opposite: I told it to interview me — closed multiple-choice questions only — about every gap, contradiction and ambiguity it could find.

It generated hundreds of questions. I answered ~300 in one afternoon (just picking letters: "Q12: B", "Q13: A but admins only"). Then the AI rebuilt the document with every decision integrated. Result: 60 pages, and the dev team basically stopped asking clarification questions.

The insight: AI is mediocre at deciding for you, but really good at detecting what hasn't been decided. The multiple-choice format is what makes it practical — answering 300 open questions would take a week.

Here's the full prompt I use (works with Claude, ChatGPT, Copilot — whatever your company allows):

You are a senior functional analyst with 15 years of experience
turning ambiguous documents into executable specifications. Your
specialty is finding the decisions the document does NOT make.

I will paste a draft functional specification. Your job is NOT to
improve or rewrite it: it is to INTERVIEW me to extract every
missing decision.

RULES:
1. Generate CLOSED multiple-choice questions (options A/B/C/D +
   always an option "E: other — specify"). Never open questions.
2. Each question must be answerable in under 10 seconds by someone
   who knows the business. If a question needs paragraphs to
   answer, split it.
3. Cover at least these categories:
   - Edge cases and boundary values (what if zero, empty, duplicate?)
   - Undefined states and transitions (can it go back from X to Y?)
   - Permissions and roles (who can do this? who explicitly CANNOT?)
   - Errors and exceptions (what does the user see when it fails?)
   - Data: required/optional, formats, limits, uniqueness
   - Concurrency (two people at once?)
   - Internal contradictions in the document itself (quote verbatim)
   - Terms used without definition or with more than one meaning
4. Number questions globally (Q1, Q2…) and group them by document
   section, quoting the exact phrase that triggers each question.
5. In each set of options, propose REALISTIC and genuinely
   different alternatives — not one good option and three fillers.
6. Do not invent requirements: if something is not in the document,
   ask; never assume.
7. Work in batches: give me the first 40 questions, wait for my
   answers, and continue until the document is exhausted.

FORMAT FOR EACH QUESTION:
Q<n> [Section — "quoted phrase"]
<question>
A) … B) … C) … D) … E) other — specify

Document:
<<<PASTE YOUR DOCUMENT HERE>>>

Tips from using it a lot: never let the AI answer its own questions (what it silently assumes is tomorrow's bug), answer in batches of 25-50, and keep the Q&A log — it becomes your decision record for when someone asks "why was X decided?".

Full transparency: I've also packaged the complete process (this prompt plus a rebuild prompt, a verification pass, a 40-item ambiguity checklist and a worked example) and I want to know if it holds up outside my own context before I do anything with it. If you write specs regularly and want to try the whole thing on a real document, DM me and I'll send it over free — all I ask is you tell me where it broke. Limited to a handful of people so I can actually process the feedback.

Happy to answer questions about the process here either way.

Hello all, I am 26 with a Bachelor's of Science in Business Management, and I graduated in 2020. I am having a late start to my career path as I went to work for the family business instead of starting my career. After researching a career path, I have decided on pursuing a career as a Business Analyst. Currently, I am starting from the beginning as far as experience. I am on SQL Bolt learning the basics of SQL. I also have went through the Wiki on this subreddit to learn and see what all I can do for now to prepare and have a shot at landing a position as a Junior Business Analyst.

My question is, what real world advice can you guys give me on how to save my career path and ensure a solid path to this career while I am currently learning and doing everything myself from home? Is there an entry-level job that you guys would recommend I start with for now since I have absolutely no experience at all? Maybe a remote data entry or customer service position?

I currently work for my family HVAC business, with my dad being the owner, however its very unorganized and everything I do is very surface level. I tried tying my current job and responsibilities in my resume as best as I could for a junior data analyst position and have applied everywhere I could so far.

What I currently do, for the family business is run the social media accounts, create ads on canva and post, run Facebook ads and Google Local Services Ads, generate leads and either sell on the phone or set-up those leads for technicians. I handle the vehicle registrations and civil suits of the company, pay toll tags and bills etc. I also handle my dads property taxes, business personal property taxes, website and google business profile, respond to all customer reviews. Pick up payments from customers in person, and several miscellaneous other things. As you can see, it is not a clear set of skills for me to get better at since I can get pulled in many directions and am not able to really grow in one specific area.

HVAC gets slow in the winter so i plan to use the extra free time to study and learn as much as I can to be able to qualify and be hired for an entry level position asa Business Analyst.

Hi,

I've been working for legacy company and they developed their own version of chatgpt that we can use freely, and it has many different "agents" so to speak that specify in certain areas like power query or internal regulations etc. Out team already use it extensively to optimize things, correct dax, rebuild models etc and work is way easier now.

Recently I've seen Bas Dohmen video how he generated the whole report (etl, model, visuals and layout) just using AI, VS Code and some excel files as source. It wasn't perfect but still very impressive expecially that he didn't input anything himself. If it is possible now then it's just a matter of few short years before it will be good enough to cut BI teams in half at least.

On top of that we all hear AI is coming and we either get on board or get left behind. I'm wondering what "getting on board" actually means in case of BI/data/analytics. Assuming we want to stick to the broad "data" field, what would be smart decision to make to stay ahead.

I've researched job market and currently there are some jobs that required only "interest in AI" and some require specific like LangChain or LlamaIndex, RAG, vector databases, Semantic Kernel, LangGraph, MCP, CrewAI, AutoGen,etc. Good thing is that it's farly new tech so rarely they required years of experience.

It seems like we are now at the "aliens are coming" moment and have very limited time to prepare for them properly.

I have always been a squad BA (4 years) and I need help understanding how to start creating BRD/FRD/ other BA docs. I start a new job in a few weeks and want to upskill on my understanding before I join in case they throw me into it

I'm looking for perspectives from experienced BAs who have changed domains during their careers.

I currently have around 3 years of BA experience in BFSI, specifically cards and payments, and I'm trying to think strategically about whether I should continue building deeper domain expertise or deliberately switch to another domain.

My understanding is that the core BA skills are fairly transferable — requirements elicitation, stakeholder management, process analysis, documentation, UAT, Agile delivery, etc. However, many BA job descriptions still ask for specific domain experience, particularly as you become more senior.

So I'm trying to understand the actual career trade-off.

I’m currently working in government and I’m looking to transition into a Business Analyst or Project Management role. I’d love to hear from people who have made a similar transition especially if you came from a role that was BA/PM-adjacent rather than having the official “Business Analyst” title.

For the past 2+ years, I’ve been involved with an Agile project and have experience with things like:

• UAT and testing
• Creating and working with user stories
• Participating in user requirements meetings
• Working with Jira/Confluence
• Working with stakeholders and development teams
• Supporting a product after going live
• User onboarding and ongoing support

The product has now been live for about two years, and my current work is more focused on user support, onboarding, and administration. I feel like I’ve gained a lot of relevant experience, but I’d like to move into a role where I can be more involved in the actual analysis, requirements gathering, process improvement, and project work.

I have a Bachelor’s in Business Administration, and I also completed a full-stack web development bootcamp, so I have some technical knowledge as well.

My plan right now is to spend the next few weeks filling in some of the gaps in my knowledge, things like:

• Advanced Excel
• SQL
• Business analysis methodologies/frameworks
• Process mapping and requirements documentation
• Wireframing/mockups
• Building a small portfolio of BA projects

I’m also considering starting to apply for BA/PM positions while I’m doing this rather than waiting until I feel completely “ready.”

For those of you who are currently Business Analysts:

What helped you make the jump into the role?

Were there any courses, certifications, portfolio projects, or skills that actually made a difference when applying for your first BA position?

And based on the experience I've described, would you consider me ready to start applying for junior/intermediate BA roles, or would you recommend getting more experience first?

Any advice would be greatly appreciated!

Hi everyone!

I’m relatively new to Anaplan and I’m trying to better understand how requirements gathering / discovery workshops are actually conducted on real Anaplan projects.

I understand the general idea: meet with SMEs/business stakeholders, understand the current process, identify requirements, document them, and eventually translate them into things like user stories, functional requirements

But I’m more interested in the practical side of the workshops.

For those of you who have done a lot of Anaplan implementations:

1. How do you prepare before a workshop?

• Do you already have a list of questions prepared?
• Do you prepare questions based on the business process, or do you mainly let the SME explain the process first?
• If you're hearing the process for the first time, how do you know what questions you should ask?

1. What questions do you typically ask SMEs?

Do you have a generic framework/checklist that you use for almost every discovery workshop? Or do you approach it differently?

3. How do you take notes during the workshop?

This is something I struggle with. If I try to write down everything the SME says, I feel like I stop listening and lose the bigger picture.

Do you:

• Take detailed notes?
• Write only keywords and important business rules?
• Use a predefined template?
• Draw the process while they explain it?
• Record the meeting (when permitted)?
• Have someone else take notes?

And how do you make sure you don't forget important information after the workshop?

4. How do you distinguish a requirement from just information?

For example, an SME might spend 20 minutes explaining how they currently perform a process. How do you identify which parts are actually relevant requirements for the Anaplan solution?

5. How do you handle things you don't understand during the workshop?

Do you stop the SME immediately and ask for clarification, or do you note the question and continue so you don't interrupt the flow?

6. What happens after the workshop?

How do you go from workshop notes > process understanding > requirements > user stories/acceptance criteria

I'd especially appreciate advice on the thinking process of an experienced Anaplan consultant/BA during these workshops.

I'm trying to understand what comes with experience/practice versus what can be learned through a structured framework.

Any advice, examples, templates, or lessons learned would be really appreciated!

Thanks!

I'm curious how other BAs are experiencing the impact of AI on their day-to-day work, especially in organizations that are actively encouraging ai tools like Claude/Copilot/ChatGPT.

I've noticed some pretty significant changes recently:

Senior management setting extremely aggressive delivery timelines, seemingly with the assumption that AI should make the work much faster. Expectations to produce 4–10 user stories within 2–3 days using tools like Claude. Test-case reviews and other BA activities are also expected to be completed much faster using ai. At the same time, the quality/complexity of the requirements hasn't necessarily decreased and since requirements are changing constantly, there isn't a source of truth that is completely capturing the requirement which ai can use, so there is a higher risk of hallucination.

I'm also struggling to understand where AI genuinely improves BA productivity versus where it simply shifts the bottleneck elsewhere.

I haven't worked in a very mature Scrum environment, so I'm also wondering whether some of what I'm experiencing is actually an AI-driven productivity shift or simply poor Agile/Scrum implementation being amplified by AI expectations.

How has AI changed the expectations placed on you? Are you actually expected to deliver significantly more requirements/work than before? What BA activities have become dramatically faster with AI? What activities have not become faster despite AI? How do you manage the increased workload when AI makes the organization assume everything should happen instantly? Has AI improved your actual productivity, or mainly increased the amount of work you're expected to produce? Have your teams changed their Scrum/Agile practices because of AI?

Has anyone worked as a Business Process Management (BPM) Executive? If so, I’d really appreciate your insights:

1. What do you do as a BPM Executive?
2. What are you doing now, and how has your BPM career journey been so far?
3. What was your starting salary, and what is your current salary?
4. Would you recommend BPM as a career path?

I’m in an environment where technical ability seems to be judged heavily by how familiar you are with the company’s business logic.

The problem is that a lot of this logic is specific business knowledge context held by a few senior people with 15+ years of experience in same organisation It isn’t obvious from the code or queries, and documentation is either missing or incomplete. Asking for documentation—or offering to document what I learn, doesn’t seem to get much traction.

At the same time, using an LLM to help trace code, queries, or reconstruct some of that context is frowned upon, and there’s an expectation that LLM usage should be tagged on deliverables.
So it feels like a strange catch: you’re expected to already know undocumented context, and not knowing it can be interpreted as weak technical ability, but the mechanisms for independently closing that knowledge gap aren’t really encouraged.

Has anyone dealt with this kind of culture? How do you distinguish actual technical competence from simply having years of accumulated company-specific knowledge, and how do you navigate it without constantly depending on the same gatekeepers?

I've been looking at where some of our calls are going lately and I'm convinced people have figured out their own shortcuts through our phone system

We give callers a bunch of options for billing / account issues / technical support / cancellations etc. and somehow people still land in completely different queues. Some hit 0 until they get a person, some keep saying agent and I'm almost positive others just pick whatever option they think will get answered fastest.

Can't really blame them either to be completely honest. If I already know why I'm calling, listening to a minute of options before I'm allowed to explain myself would annoy me too

Atp I’m wondering if the whole structure is backwards. Instead of asking customers to understand which department owns their problem, would it make more sense to let them explain why they’re calling first and route from there?

Has anyone worked on an IVR or intake redesign like this? Wanna know whether routing by customer intent actually improved accuracy or just created different problems.

For context, I have been working in the IT industry for over 6 years. I initially chose this path because I found genuine fulfillment in showing people how technology can help their daily lives, which eventually led me to my current role as a Business Analyst (BA).

Recently, however, I’ve felt completely burnt out and uncertain about my career direction. Below is a breakdown of my career history and the challenges I've faced. I would really appreciate advice from senior professionals who have been in the industry for a long time.

Career History

1st Job (2.5 years) – Small ERP Solution Provider

• Role/Scope: Started as a fresh graduate, learned the Software Development Lifecycle (SDLC), managed L1 and L2 support tickets, handled inbound/outbound calls, and gained exposure to implementing their proprietary ERP system.
• Why I Left: While the environment and colleagues were fine, management was disorganized. They frequently assigned fresh grads to handle client-facing issues without providing context, forcing me to handle escalations beyond my job scope. I left because I wanted to work in a company with a proper corporate structure and clear task delegation.

2nd Job (1 year) – MNC Manufacturing Company

• Role/Scope: Joined to gain exposure to an MNC and work with well-known systems to strengthen my resume. I was expected to assist with their migration from SAP to Oracle, but my primary focus ended up being data migration. I enjoyed this because I like writing SQL queries and transforming data to meet requirements.
• Why I Left: I realized the city was not somewhere I wanted to live long-term, and I felt my learning trajectory had plateaued. After passing my JLPT N2 exam, I was offered an opportunity at a well-known consulting/BPO firm.

3rd Job (3 years, Current) – Global Consulting / BPO Firm

• Initial Expectation: Hired to assist their Japan market team with Microsoft Dynamics 365 (D365) F&O implementations, but the firm failed to secure the project after I joined.
• The Struggles:
  • I spent 6 months on the bench while they tried to hold me for the client.
  • Eventually, I was placed on an Australian D365 Finance project, but I was only assigned administrative ADO/Jira ticket updates because they were hesitant to delegate core responsibilities to offshore team members.
  • Knowing how critical chargeability is in consulting and feeling this wasn't real BA work, I proactively requested to transfer to active projects.
  • Since then, I’ve spent 1.5 years on a Government-Linked Company (GLC) project and a D365 CRM banking implementation. However, because I joined during the build and testing stages, I missed out on leading core requirements gathering.
• Compensation & Growth: Despite receiving strong performance appraisals from my Functional Lead, I have received a <2% increment and no promotion in 3 years. When I confronted my manager, his excuse was that he couldn't even fight for himself, let alone me, and advised me to figure out a specialization rather than jumping between domains.

My Current Dilemma & Questions

1. Am I in the wrong industry? After everything I’ve been through, I still feel zero job satisfaction. How do experienced professionals handle these setbacks? Given the corporate friction and unsupportive management, I can't imagine climbing the corporate ladder here. Is this lack of fulfillment normal, or a sign I should pivot out of IT consulting?
2. What should I specialize in for long-term career growth? I want to switch companies, but recruiters tell me my background is too diverse (jumping across ERP, Oracle data migration, D365 CRM, Finance, and Banking) to push for higher positions or higher salary bands. Every project has its own set of problems, but based on my experience—SQL/data mapping, D365 ERP/CRM implementations, Japanese language skills (JLPT N2), and support/BA work—what specific domain or technology stack should I target to build a strong, high-growth specialization?
3. Vendor vs. In-House vs. Market Dynamics: The reason I’m asking about specialization and direction is that I’m considering either hopping to another vendor or moving to an in-house IT team.
   • Both paths require deep product or domain knowledge, which is where I feel stuck.
   • Banking environments can be super high-pressure, so I'm hesitant to jump into that sector full-time.
   • Going to another vendor might just mean repeating the same operational issues I’m facing now.
   • In-house IT roles expect solid domain expertise that I feel I still lack.
   • To make matters worse, most of the job offers popping up in my inbox lately are contract roles.

Given these constraints, what would be the best strategic next move for someone in my position?

I’m working as a requirmenets engineer in a public administration IT department. We do work agile, however in the bad meaning of the term.

Product owner is not engaged much in requirements solicitation and business analysis. but he doesn’t allow me to talk to stakeholders or the future users of the tools. he’s quite boomerish and wants to control the stakeholders. no meetings with them are allowed without his presence. so basically whenever I try to model requirements and have questions I have to rely on PO asking the stakeholders or wait for a common meeting to be set up.

this hinders effective requirements management. further, PO is not able to prioritize properly. Either everything is as important as everything else. Sometimes it turns out that there are is no business case for some use cases. Money is spent on fantasy tools which are used by nobody really.

at one time imitative A is important, next week initiative B is important. then, two months later we need to deploy initiative A immediately. even though we didn’t finish modeling the requirements the first time.

so what happens is that we do not finish requirements elicitstion for topic A, it is beimg left in an unready state for weeks or even months, and then suddenly it pops up and is super important and needs to be finished. since ita urgency, things get implemented and - oh wonder - do not satisfy expectations. and everybody is unhappy.

any suggestions? Anybody ever expected the PO obstructing your work.

I've seen this term a few times lately and I'm still trying to understand what it actually means in practice.

It first made me think of IBM's work around knowledge graphs and connecting enterprise data. Then I came across Skan AI using “Context Graph of Work” for something a bit more specific: connecting the people, systems, documents, decisions, and exceptions involved in getting work done. I can see the appeal. Most process maps look clean, but the real workflow usually involves email, spreadsheets, Teams, manual handoffs, and a few steps nobody bothered to document. What I'm not clear on is whether this is genuinely different from a good process model or knowledge graph, or just another way of packaging the same idea.

Has anyone seen it used in a real project?

Hi, I am doing interview preparation for Business Analyst role. Since I am making a career shift and have no prior background in this jobrole, I am looking for some good study resources and AI tools that can help solidify my preparation for the interviews.
Appreciate, if the Reddit community can suggest some tried and tested AI tools for mock interview practice. Thanks in advance

I’m currently earning around 30–40% below what I believe the market/pay grade should be for my experience, and I’ve been trying to move for quite some time. I’ve also been with my current organisation for 5+ years, so I’m feeling pretty stuck.
I have around 14 years of IT experience, with 6+ years as a Business Analyst, primarily in Life & Health Insurance. I’m currently a Lead BA in Bangalore.
The frustrating part is that I keep getting through the initial rounds:
Round 1 → Clear
Round 2 → Clear
Final round → “We regret to inform you…”
Over and over again.

I prepare extensively before every interview — company research, role, projects, BA concepts, behavioural questions, insurance domain questions, etc. And I’m self-aware enough to know when I’ve had a bad interview. But honestly, 8/10 times I come out feeling that I performed well.
My experience includes insurance product changes, requirements, claims, SQL, APIs, JIRA/Confluence, stakeholder management, impact analysis, working with Product/Operations/SMEs, and end-to-end BA responsibilities.
So I’m starting to wonder if there’s something fundamentally wrong with how I’m presenting my experience, particularly in the final/managerial round.
For those of you who are Senior/Lead BAs:
WWhat makes you reject an experienced BA at the final round despite them clearing the earlier rounds?
Is it communication? Storytelling? Leadership presence? Not demonstrating enough ownership? Being too technical? Not showing business impact strongly enough?
I’mq genuinely looking for blunt, constructive feedback. I’ve been preparing harder and harder, but clearly preparation alone isn’t fixing whatever the issue is.
Would really appreciate perspectives from people who have been on the other side of the interview table.

I’m pretty sure there must be at least one book written by an experienced Business Analyst that focuses specifically on requirements gathering, -

Hi all, I am in a bit of a dilemma here. I recently started a Senior BA position at a major bank and I'm going crazy with information overload, I will be supporting salesforce implementations across different tracks each with their own set of requirements, business rules, etc and I'm struggling to organize all of it. My team works in an Agile environment, so we use Jira for user stories, a lot of 365 apps since we're under MS umbrella and I personally found myself using OneNote a lot lately, to try and get some organization going. In my previous team, as a BA there was virtually no organization so everything was scattered all over the place between sharepoint documents, confluence, jira etc.

I want to know how all of you stay sane amidst the bombardment of information that comes your way when starting a project, how do you document, organize, etc. In this role, I'm expected to do data flow diagrams, requirements management, stakeholder collaboration (joint with PO), etc.

I appreciate any advise as well on Senior BAs already on the role, this would be my first ever senior role and I don't want to screw it up