From Order-Taker to Stakeholder: The Importance of Asking the Right Questions

A developer's job is more than just translating the requirements into a computer program. They should be going one level deep and figuring out why we have these requirements in the first place.

I was once part of a call with a client and their technical advisor, where we discussed the tech stack for developing a mobile application for them. It's a typical technical conversation where most of the discussion was around choosing between Flutter and React Native.

During this conversation, I asked a simple question to the client. Why do you need a mobile application? He replied that most of the potential users of the application are on the move, and hence, it is required to be on the mobile.

Then I asked a follow-up question. Does the application need to be accessible from mobile, or must it be a mobile application?

Intrigued by this question, the client said, I want the application to be accessible from mobile, and I thought having a mobile application is the only way to achieve it.

They already have a web application usable only from a desktop. I proposed to make that web application responsive rather than building a mobile application from scratch.

The initial estimate for developing the mobile application was around three to four months, whereas the alternative, making their existing application mobile responsive, was just one month.

Just by asking a few simple questions, I saved two to three months' worth of effort and money.

If this situation had happened in the early stages of my career, I would have happily jumped into the solution mode with the excitement of learning something new (Flutter or React Native). But at what cost? Burning the hard-earned money of the client for this is not legitimate.

I see a similar mistake happen across the software industry, especially among junior and mid-level developers. Unknowingly, they became a "coding machine" and mindlessly implementing what is described in the JIRA(or any other product management) issue.

As a fellow journeyman who passed this path, I completely understand where they are coming from. I have been there and done that.

The software developers should move away from this "Order Taking" mindset to a "Stakeholder" mindset.

Product Management and development often suffer from XY Problem.

The XY problem is asking about your attempted solution rather than your actual problem. This leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help. - xyproblem.info

The client/stakeholder wants to solve the problem "X," and they have decided the feature "Y" is the solution for the problem. They talk to you about implementing the feature "Y."

Now, you, as a developer, have two options.

Option #1: Start developing the feature "Y" using the given specifications.

Option #2: Probe the client/stakeholder on why they are proposing the feature "Y" and what is the real problem ("X") it is trying to solve.

In a typical organizational setup, there will be a hierarchy between the developer and the customer. A business analyst or product owner will analyze the problem and develop requirement specifications. The developers get into the order-taking mode and mindlessly translate the specification into a working product.

Few organizations encourage developers to question the requirements. I firmly believe this is how software development should happen.

The developer building the system has more and broader visibility of the software product than anyone else. If they take control over this, we can avoid unnecessary efforts and save plenty of money and time.

Coming back to the "XY Problem," if the developer has the power/liberty to probe the actual requirement (solving the problem "X"), they may come up with the feature "Z," which can be simpler to implement than the feature "Y."

The developer has to know the "Why"s behind every code they are writing," and they should be encouraged to ask the right questions to know these "Why"s.

When you develop a feature, always see the big picture and visualize how the people will use it when it gets released. If you feel the requirements given to you don't align correctly with the end-user, get back to the client and have a conversation about it.

You are not an order taker; you are also a stakeholder. Remember, technical skills are just one piece in software development.