One thing that separates Assets on the Balance Sheet from our Customers is that our Customers have a preference, while our Assets don’t!
Has your Car ever woken up one morning and said – I don’t like this Red paint, I am going to get my owner to paint me White? Simply put, we own Assets, but I don’t think that we can ever truly say that we own our customers.
I know a number of businesses that think that way – that is my customer; what are they doing talking to my customer; why is my competitor’s coffee mug in my customer’s office; I took my customer to the IPL and so it goes. People are very protective of their customers, yet there is really no concept of ownership by the customer themselves. Because clients are not things – they are humans. And they always crave to be understood as humans. Not just a segment or an artificially defined sector or even a mass market. But humans.
And most importantly, how they crave to have someone solve their problem, and not just sell them things – be it products or services.
The importance of knowing our Customers is immense, the way they think, the way they perceive what we deliver and their expectations, in order to understand how we can make a difference in this epic legacy of client-vendor relationship.
Earlier when I was involved with one of the MNC Businesses in the HCM Industry into building and delivering both a Platform and a Product at an Enterprise scale to Global 100 Customers, I had to deal quite a lot with customer’s to explain them the technical challenges, fulfilling their commitments and so on. And a lot of times it was frustrating to believe the unrealistic commitments made at the senior level, compromising quality for quantity without clarifying their actual needs and I always felt that had it been in my hands, I would have done something different. Anything. The most important of all would have tried to understand them better.
So, here I am. And now, when I deal with customers every day of my life as part of my boutique, I make the most efforts in understanding them and their problems — and not just requirements.
Nowadays, WordPress as a CMS looks so easy, that customers also come up with specifications like I need so and so features in so and so hours — and that’s pretty much it.
However, before we end up committing, it is important to know but a bit more, such as:
What is their budget?
What are their expectations?
What is the feasibility of their requirements?
And most importantly — What is the main goal?
And at this point, we really need to involve our engineers – not for technical solutions at the moment but for assisting us on UX – with questions.
Because When vague requirements meet misaligned expectations, things will go wrong.
For example, these common requests from clients are easy to describe but can be complex to build or even test at times owing to their impact on the overall system like:
Third-party integrations, Content migrations, Ad implementations, Plugin Updates etc.
I think we all are technically doctors. Just like them, we are the ones who can bring life to technology or provide a medicine – in this case solutions to fix something. And for that, we need to understand the symptoms and patterns just like a doctor does. Because if the disease itself is detected wrong, it can prove to be a disaster for both the customer and the vendor – in this case the doctor. 🙂
As a service provider, our main goal is to solve the problem of the customer by giving reasonable solution after analysis. Not just rebuilt everything and reach the same point where a previous vendor might have stopped.
Most importantly, nothing should be build just because it looks good or looks different or is just pretty. Or just because the client has mentioned it as “part of requirement”. It is important for it to be useful. That it “needs” to be there. Someone’s pretty might be annoying to others if it is not useful to them or restricts them to do something. We need to explain these scenarios to the client.
So the thing here is that we need to spend some quality time before project implementation starts rather than spending double the time while implementation.
So, if we can discover the problem or/and the solution during the requirement phase – it is a win-win. And we will be able to balance both your engineers and clients. After all, engineers are the pillars of our company. Frustrating them can be pretty dangerous! Who would know that better than people like us who have been in their shoe time and again!
Let’s build something great, Contact us.