In software product or project development, I have encountered several types of customers or corporate users. Customers are often in a hurry and expect everything to be completed ahead of schedule, sometimes even before the requirements discussion takes place.
There are different types of customers based on their roles in software development. Some are business users involved in requirement discussions, while others are IT support personnel. However, a common challenge is that they often do not understand the difficulties faced by developers or the software team’s project managers.
Even when the customer’s IT personnel are knowledgeable about software-related infrastructure, their perspective is usually quite different from the software development or deployment process.
I have faced situations multiple times where the IT support person managing the client’s infrastructure behaves as if everything should work flawlessly, like a plug-and-play system, with no room for issues. However, during deployment, hundreds of potential issues can occur within the infrastructure or the deployment environment, but they are often reluctant to accept this reality. They tend to push for on-time delivery, demanding that everything work perfectly on their laptop browser. Once they see it working, they feel at ease.
Customers generally do not want to hear about problems; they expect everything to work smoothly. However, in technical processes, anything can go wrong. Unfortunately, they seldom try to understand this reality.
I have encountered these situations many times with my team. In such cases, the team feels overwhelmed and pressured, which ultimately degrades the quality of their work. From my experience, I have had to manage customer managers or project owners through several discussions to explain the actual scenario. However, since most of them are business people without technical knowledge, they struggle to understand anything beyond a delivery date I commit to.
I’ve also experienced situations where the team could not meet the agreed timeline, causing the customer to become frustrated. To manage this, I let the customer express their concerns fully before calmly explaining the real issues and requesting the necessary time to complete the task. This approach has worked well for me.
In many cases, when the delivery is delayed, I arrange meetings with the customer’s project manager, who is typically a businessperson responsible for providing requirements. If the team cannot meet all requirements or deadlines, I sometimes escalate the issue and involve my boss. Even in meetings where the customer speaks loudly or aggressively, I try to convey the real scenario. Once they express their frustrations, they usually allow me the time needed to address the issues.
There have been instances where I had to explain to the customer that our team lacks experience in a particular domain and that we are learning as we develop the software. To ensure alignment, I clarify our understanding of their requirements and validate it with them. If the customer agrees that our understanding is correct, they tend to trust us and give us the time needed to complete the project. We also commit to aligning with their expectations throughout the development process, providing demonstrations of each completed part. This approach builds their confidence and encourages them to grant us sufficient time to finish the work properly.
Ultimately, there is no fixed rule for managing customers. Every user or customer is unique, and we must do our best with effort and flexibility. This is the art of navigating the software development life cycle.