Recently, I’ve had to interview candidates for a mid-level software BA (Business Analyst) role at my company. As I reflected back on the interviews, I was thinking about how the post-interview discussions about the candidates always come back to one thing: “Does he/she have the BA mindset?” Where the candidate went to school, what his/her degree is in, what internships he/she has had, how long they’ve been a BA, none of it seems to matter without the possession of a “BA mindset”. It’s nothing that you can put on your resume as a credential, yet it’s vital for landing a BA job. Here’s the “JMO” of what I look for as part of the BA mindset.
The ability to…
- Break down big problems into small pieces that can eventually be called “done”. Categorize these pieces into larger, underlying themes.
- Ask Questions – or, more specifically, ask the right people the right questions
- Question the answers to your questions. Repeat back your understanding of the answer to multiple stakeholders until everyone has the same understanding.
- Think through problems. This sounds so simple, yet this kind of critical thinking is rare. Think through every possible scenario/flow in your product and make sure logic/error handling exists to account for every single one of them. Even if you do this well, there are many that will be missed. That is OK – don’t let anyone make you feel bad for missing a scenario or two. We do the best we can and the quality of the product is the responsibility of the whole team, not just the BA.
- Be humble. Admit when you don’t understand something. It is your job to understand complex problems and come up with solutions. This absolutely requires that you admit when you don’t understand – shout it from the rooftops until you get a proper explanation.
- Draw upon QA expertise. When the BA has respect for QA, the relationship between the two creates a much better product. QA will come up with scenarios the BA didn’t think of. Don’t take it as a personal attack – instead, thank them for their critical thinking skills and be sure the use case is covered. Better late than never.