Abhishek Roka
Abhishek Roka

My First Stakeholder Meeting Taught Me That Building Software Starts with Listening

Yesterday, I had one of the most memorable experiences of my software engineering journey.

My first real stakeholder meeting.

The meeting was with the Head of the Computer Science Department and the Placement Coordinator for the Placement Portal I've been building.

I walked into the meeting expecting to present what I had built.

I walked out realizing that I still had a lot to understand.

And honestly, that was far more valuable.

I Thought I Was Going to Discuss Features

Before the meeting, I had already spent a significant amount of time thinking about the Placement Portal.

I had built the student-facing experience and was already thinking about the next set of features.

So naturally, I approached the meeting with a developer's mindset.

I was thinking about:

But the stakeholders weren't thinking about database models or APIs.

They were thinking about their daily workflow.

That distinction became the most important lesson from the meeting.

The Student Experience Was Heading in the Right Direction

The first part of the discussion focused on the student side of the platform.

The feedback was encouraging.

The stakeholders felt that the student experience was moving in the right direction.

That gave me confidence that the foundation I had built was useful.

But then we moved to the administrative side.

And that's where my assumptions started falling apart.

The Admin Panel Wasn't Really an Admin Panel

I had designed what I thought was an admin interface.

The stakeholders needed something much closer to an operational dashboard.

That sounds like a small difference.

It wasn't.

The Placement Officer's workflow involves much more than simply creating jobs and viewing applications.

For example, different companies may have different eligibility requirements.

These could include:

Today, much of this type of work can be managed using spreadsheets.

The goal of the portal shouldn't simply be to create another place to enter the same information.

It should reduce the work involved in managing the placement process.

That changed how I looked at the entire administrative experience.

Recruitment Is a Workflow, Not Just an Application List

Another requirement that became clear was recruitment-round management.

The Placement Officer needs to be able to:

This sounds obvious when explained by someone who performs the workflow every day.

But from a developer's perspective, it is easy to initially think of an application as simply:

Student + Job + Status

The meeting made me realize that an application is part of a much larger recruitment workflow.

The software needs to represent that workflow.

Not Every User Will Work the Way I Expected

Another interesting requirement involved administrative staff.

The HoD may need to upload student resumes when necessary.

Initially, I had assumed that students would always be responsible for managing their own resumes.

That assumption made sense from the perspective of the system I had designed.

It didn't necessarily match the real-world workflow.

And that's exactly the problem with building software based entirely on assumptions.

Real organizations have processes, exceptions, responsibilities, and workarounds that aren't visible from the outside.

You only discover them by talking to the people involved.

The Spreadsheet Problem

One requirement particularly reminded me of something important about software adoption.

The stakeholders wanted to export application data into an Excel spreadsheet.

They also wanted the exported records to provide easy access to the student's resume so recruiters could review applications efficiently.

My first instinct could have been:

"Why do they need Excel? The portal already has the data."

But that's the wrong question.

The better question is:

"Why is Excel part of their workflow?"

The answer is that software doesn't exist in isolation.

Organizations already have processes that work for them.

A new system doesn't necessarily replace every existing tool immediately.

Sometimes the better product decision is to make the new system work alongside those tools.

Then I Realized I Was Thinking Like a Developer

As the requirements kept coming, something interesting happened.

I started freezing.

My mind was racing through possible implementations.

I was thinking:

"What model do I need?"

"How will I structure this API?"

"Do I need another table?"

"How am I going to implement this?"

And then I realized something.

I was trying to solve the problem before fully understanding it.

The HoD pointed this out during the discussion.

I was jumping directly into implementation instead of first understanding the actual problem.

And she was right.

Stakeholders Don't Describe Database Models

This might be one of the biggest lessons I've taken away from the meeting.

A stakeholder isn't going to tell you:

"Create a new Django model with these fields and add a foreign key relationship."

They're going to say:

"I need to quickly find students who qualify for the next recruitment round."

Those are two completely different levels of abstraction.

The first describes an implementation.

The second describes a problem.

As developers, our responsibility is to understand the second before deciding how to build the first.

I Started Listening Differently

Once I recognized this, I stopped trying to design the solution in my head while the stakeholders were talking.

Instead, I started thinking about the workflow from their perspective.

I asked myself:

That shift changed the conversation.

We weren't simply discussing features anymore.

We were discussing problems and possible solutions.

What This Means for My Placement Portal

The meeting didn't just give me a new feature list.

It changed the direction of the product.

The Placement Portal isn't simply a system where:

Companies post jobs → Students apply.

It needs to support the people managing the placement process as well.

That means the platform needs to consider workflows such as:

The architecture will evolve as I understand these workflows better.

And that's okay.

In fact, I think that's how real software should be built.

My Biggest Takeaway

Before this meeting, I thought building software meant writing code.

Now I realize that coding is only one part of the process.

Before the code comes:

Listening.

Then:

Understanding.

Then:

Problem definition.

Then:

Solution design.

And only after that:

Implementation.

It's very tempting as a developer to jump straight from requirement to code.

But a requirement is not necessarily a solution.

Sometimes it's simply a description of someone's frustration.

Our job is to understand the frustration first.

Final Thoughts

My first stakeholder meeting didn't go exactly as I expected.

I went in prepared to demonstrate a product.

I came out with a better understanding of the problem I was actually trying to solve.

And that might be more valuable than any feature I could have demonstrated.

The biggest lesson was simple:

Good software engineering starts with listening.

Because if you don't understand the problem, you can build a technically excellent solution to the wrong problem.

And that's probably one of the most expensive mistakes a developer can make.

— Abhishek Roka