I started my career as a developer.
Like many fresh graduates, I was obsessed with building good solutions - clean logic, efficient code, elegant designs. If there was a problem, my instinct was simple: How do we solve this?
About a year in, I unexpectedly found myself filling in for someone who didn’t officially have the title of Business Analyst. Looking back, though, they were absolutely doing BA work. That’s when my transition into business analysis really began
At the time, I assumed the shift would be seamless. After all, I “knew” what BAs did. They wrote functional and non-functional requirements. They created process flows. They handed specifications to design and development.
Easy, right?
I was wrong.
The Report That Solved Nothing
My first real BA-style assignment was to facilitate a workshop to build a business report. Coming from a development background, I felt confident - too confident.
I ran the session exactly how I knew best:
- What fields do you need?
- How frequently do you need it?
- In what format?
- What are the business rules?
- Who will use the report?
- Who will own the report?
- Is this a scheduled report or adhoc?
I documented everything neatly in the Excel requirements template we used back then. The stakeholders signed it off. The design and development teams did a brilliant job building exactly what was specified.
The report went live in production. And… the business problem was still not solved.
A few weeks later, the business came back asking for another report. That’s when something didn’t sit right with me.
The Question That Changed Everything
I remember speaking to a senior stakeholder and asking a simple - but uncomfortable - question: “Why are we building report after report when no one seems to be using them?”
That conversation changed everything. What we uncovered was confronting:
- The original business problem was never clearly articulated
- The why behind the report was missing
- The issue wasn’t the report at all
The real problem was upstream. The data feeding into the report was incomplete and poor in quality. No matter how many reports we built, the output would never support effective decision-making.
We had done an excellent job solving the wrong problem.
Slowing Down to Go in the Right Direction
This realisation made us pause and approach things differently.
When the next reporting request came in, we deliberately slowed down. This time, we did not start with report specifications. Instead, we focused on:
- Clarifying the problem statement
- Understanding the current state and pain points
- Identifying the decisions the business was actually trying to make
- Defining what would change if the problem was truly solved
Only after that did we talk about solutions.
The outcome surprised everyone. Instead of building another report, we raised a change request to fix the data issues in the upstream systems. We defined clear success criteria and measured it post-delivery. The existing report - once fed with quality data - finally became useful.
That’s when it clicked for me.
The Mindset Shift I Wish I’d Made Earlier
As a developer, my default mindset was: “How do we solve this?”
As a Business Analyst, the real value came from asking: “Why do we need this?”
That single shift - from solution-first to problem-first - completely changed the direction of conversations, priorities, and outcomes.
And this is where I wish someone had told me this earlier: Business analysis is not about documenting solutions well. It’s about making sure we are solving the right problem.
A Pattern That Still Shows Up
Almost two decades later, I still see this pattern - especially with professionals transitioning from technical roles like developers, architects, or testers into BA roles. They are smart. Capable. Experienced.
Yet they jump straight to:
- System design
- Fields and business rules
- Screens and workflows
All before uncovering the real business need. It’s not a skills gap. It’s a mindset gap.
The Lesson I Carry Forward
If I could go back and give my younger self one piece of advice, it would be this:
''Your job is not to be the fastest person in the room with a solution. Your job is to be the person who ensures the team understands why a solution is needed.''
Because once the why is clear:
- The right solution often looks very different
- Business value becomes visible
- And rework drops dramatically
Sometimes the best thing a BA can do is to slow the team down, so they don’t confidently head in the wrong direction.
It’s a lesson I learned the hard way - but the one I’m grateful I learned early enough.
