Divyash Gupta, Business Analyst at PalTech
I joined PalTech as a Business Analyst, and one of the biggest things I’ve learned is that Business Analysis is much more than writing requirements.
This is an independent personal website created by Divyash Gupta. It is not affiliated with, operated by, or endorsed by PalTech. Everything here is my own reflection on my work and contains no client, project or otherwise confidential information.
I’m Divyash Gupta, based in Hyderabad. I studied Computer Science at Amity University and then Finance at IMT Hyderabad, which is a slightly odd pairing until you end up in a job that needs both.
I like understanding how things work, and I’m more interested in why they work that way than in the surface description of what they do. That instinct is most of why I ended up here. More about my background.
As a Business Analyst at PalTech, I work between the people who have a problem and the people who will build something about it. In practice that means a lot of listening, a lot of clarifying, and a lot of writing things down in a way that survives being read by someone who wasn’t in the room.
On a normal day that looks like: understanding what someone actually needs, asking the questions nobody has asked yet, turning a messy conversation into structured requirements and acceptance criteria, and then staying close enough to the build that the details don’t quietly drift.
It’s an enterprise environment, which means real constraints, real dependencies and real consequences when something is misunderstood early. That has been a good place to learn.
Before I started, I thought of Business Analysis as documentation with extra steps. Someone tells you what they want, you write it down properly, engineering builds it.
What I’ve found is that the requirement is the last thing that happens, not the first. Before it there’s a stretch of work where nobody quite agrees yet, where the same word means two things to two teams, and where the problem someone described is not the problem they have.
One of the biggest changes in how I think came from realising that the first version of a requirement is rarely the final version of the problem. The more questions you ask, the more you discover.
I’ve learned that a good Business Analyst isn’t the person who has all the answers. It’s often the person who asks the question nobody else thought to ask.
Mostly not
what I expected
If I try to name what the role has actually taught me, very little of it is technique. Most of it is judgement: knowing when to slow down, whom to ask, and what to be careful about.
- Understanding a problem properly before proposing a solution to it.
- Asking better questions, and being comfortable asking the obvious one.
- Speaking to very different stakeholders and adjusting how I explain things without changing what's true.
- Turning ambiguous conversations into structured, reviewable requirements.
- Thinking about users rather than only features.
- Breaking large problems into pieces small enough to actually make progress on.
- Prioritising honestly, including saying what isn't important right now.
- Communicating with technical and non-technical people in the same week, sometimes the same meeting.
- Thinking through edge cases and being specific about acceptance criteria.
- Watching how products change once real feedback reaches them.
- Balancing what the business needs against what is technically realistic.
- Working inside an actual enterprise environment, with the constraints that come with it.
How the thinking
has changed
01
Ask before solving
I've become much more careful about jumping straight to a solution. Sometimes the most valuable thing you can do at the start of a problem is ask one more question instead of proposing one more idea.
02
Clarity is a skill
A complicated problem doesn't necessarily need a complicated explanation. A big part of my job is taking something messy and making it understandable enough that everyone in the room is actually talking about the same thing.
03
Requirements aren't static
What starts as a simple requirement can change completely once you speak to the people who actually use the system. I've learned to treat requirements as something to explore, not just something to document.
04
Stakeholders think differently
Different people can look at the exact same product and genuinely see different problems. Learning to hold several of those perspectives at once, instead of picking the loudest one, has been one of the most useful parts of the role.
05
Details matter
Small gaps in a requirement become expensive later. Thinking through edge cases, and being specific about what "done" actually means, has changed how I approach almost everything.
06
Technology needs context
Coming from Computer Science, my instinct is to reach for a technical answer. Business Analysis has taught me to first check whether technology is the right answer at all.
07
Good products start with good questions
I've started valuing questions almost as much as answers. The quality of what gets built is usually limited by the quality of what got asked at the beginning.
Right now I’m most interested in product thinking, the part of the work that decides what deserves to exist, not just how to specify it. I’m also paying close attention to AI and emerging technology, partly out of genuine curiosity and partly because it keeps testing the question I ask at work anyway: is this actually the right tool for this problem?
Alongside that, I’m still working on the unglamorous things. Writing more clearly. Asking better questions. Being more precise about what “done” means. Some of that thinking ends up written down properly, and what I’m doing now stays current.
07 · Find me on LinkedIn
My professional profile, including my role as a Business Analyst at PalTech, lives on LinkedIn.
This is an independent personal website created by Divyash Gupta. It is not affiliated with, operated by, or endorsed by PalTech.