Divyash Gupta
Hyderabad, India
I like understanding complicated problems, asking better questions, and turning ambiguity into something people can actually build.
I like understanding how things work, and more importantly, why they work the way they do.
My background is a little unusual. I started with Computer Science, moved deeper into Finance, and ended up working at the intersection of technology and business.
Today I’m a Business Analyst at PalTech in Hyderabad, where I’m learning how an idea travels from a business problem to something people can actually use, and how much careful thinking sits in between.
The work, described
honestly
- Understand
- I start with the problem rather than the solution: what is actually going wrong, who it affects, and what success would even look like. A surprising amount of the work is just getting that part right.
- Structure
- Conversations are messy by nature. My job is to turn them into something structured: clear requirements, user stories, acceptance criteria, and an honest view of what matters most right now.
- Connect
- A lot of the role is sitting between two groups who are both right. Business stakeholders know what they need, and engineers know what it will actually take. Keeping those two views in the same conversation is most of the value.
- Think
- I try not to stop at "what should we build?" The more useful question is usually "why are we building this, and what happens if we don't?"
- Learn
- Every stakeholder conversation changes my understanding of the problem slightly. I've stopped treating that as a setback and started treating it as the point.
Technology × Business × People
My interests sit somewhere in the middle of these three things. I don’t think any of them is interesting enough on its own.
Technology
Technology gives me the ability to understand what can be built, and a sense of where the difficulty is actually hiding.
Business
Business helps me understand why something should be built at all: what it costs, what it displaces, and who benefits if it works.
People
Working with people teaches me who it actually needs to work for. That's the part you can't derive from a document.
A slightly
unusual route
Computer Science first, Finance second, and a role that needed both.
Computer Science
B.Tech in Computer Science
Amity University
Computer Science gave me the technical foundation. More than any specific language or framework, it taught me to think logically, break a large problem into smaller ones, and understand how software actually works underneath the interface.
Finance
PGDM in Finance
IMT Hyderabad
Finance added a completely different lens. I started thinking about businesses rather than systems. Decisions, numbers, incentives, trade-offs, and how organisations actually create value. It rearranged how I evaluate whether something is worth doing.
Now
Business Analyst
PalTech · Hyderabad
Business Analysis turned out to be the role where both of those become useful at the same time. The technical side tells me what is feasible; the business side tells me whether it's worth building.
This is where those two sides started coming together.
My journey 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.
It’s the part before the requirement: the questions, the disagreements, the slow work of making sure everyone is describing the same problem. That part turned out to be the job.
Notes from
the first stretch
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.
I’ve never been very good at sticking to one area of curiosity
Curiosity that doesn't stay in one place
I've never been very good at sticking to one area of curiosity. Technology led me to AI. Business led me to Finance. Work led me to product thinking. Each one keeps pulling on the next.
Learning by building
I understand things much better once I've tried to make them. Reading about something gets me halfway; putting a rough version together usually shows me the part I'd misunderstood.
AI and where it's going
I'm genuinely interested in AI and emerging technology, partly for what it can do and partly because it's a good test of the question I keep asking at work: is this actually the right tool for the problem?
Travelling, and perspective
Travelling has probably taught me more about different perspectives than any classroom could. It's a reasonably direct education in the fact that your way of seeing something isn't the only sensible one.
Thinking
out loud
What I Wish I Knew Before Becoming a Business Analyst
Six things about the job that nobody really explains to you until you are already doing it.
How I Think About Requirements
A requirement is not a description of a feature. It is a description of a problem, plus an agreement about what counts as solved.
Why Asking Better Questions Matters
The quality of what gets built is limited by the quality of what got asked.
Connect with me
If any of this overlaps with what you're working on, I'm easy to find on LinkedIn.