Part - I of this blog series is here : From a Products to Services based Organisation : What I learnt...
If you have read Part - I of my blog about my transition from a product based to a services based organisation, you would know that I recently changed jobs from SAP Labs India Pvt. Ltd. to IBM India Pvt. Ltd. in late October, 2009. Currently working out of a client location in NJ as a system integrator and SAP MII architect, this blog series is a chronicle on the changes I faced on this transition, how I managed them and what I learnt...
In this part of the blog I'll try to present two of the most important lessons that I learnt while dealing with clients.
Those who've met me and know me will tell you how impatient I am and also the fact that I talk more than I listen. The one lesson that I learnt was to try and develop an ability not only to listen patiently while also trying to understand and interpret what your client is telling you and then be able to interpret these into functional and technical requirements. Most of the time your client might not be able to give you the exact technical or functional requirement he has in clear words. This maybe not because of the fact that he does not know clearly or isn't able to articulate these to you, but there may be a lot more reasons for this. Maybe the product is new and different and he is not quite aware of its capabilities yet. Maybe he has a very high level understanding of the business process he is trying to implement and he needs your help to flesh it out for him.
That's exactly where your listening and analysis skills will come to your aid. Since you know the product better and are aware of its extended capabilities, it would be very easy, armed with the information your client has given you to come up with a comprehensive solution that addresses his woes. So if you are planning on developing a functionality which involves screens, create a mockup and share it with your client so that he has a clear picture of what you have in mind and can match it to his expectations of the functionalities he is expecting. In doing so you have just created a sort of a sync between both of your thought processes and believe me this brings about wonderful results increasing the trust between you and your client.
The second thing that I learnt, that will deepen the bond of trust between your client and you is being honest. Your product just might be the ultimate solution, but it might not fit each and every requirement that the client has in mind. Other than present your product as one that is the cure for all diseases and say which all places it can be optimally utilised, you should also speak up if you think there are scenarios for which it is not the best fit. And remember that it is also very important to explain why you think it is not the best fit for a particular scenario and if you know, suggest what might be a better solution. This not only helps to avoid later heartburns and sleepness nights for both but also leads to a better optimal solution overall.
I remember a situation where I was discussing a possible solution involving SAP MII and another product which has mostly different capabilities and use than MII, with one of the client architects. When I mentioned that maybe the other solution is a better fit in the current situation though SAP MII can achieve the same, he looked at me incredulously and said "I thought you were here to work on MII, yet when I am giving you work involving it you say that it can be done better with the other solution ?".
I think, though it is my duty to advice in which scenarios a product can be best utilized, it is also my duty to speak up and inform if I encounter a scenario in which it is not a best fit.
At the end of the end of the day I am happy to see that I am able to help my client develop most possibly the best solution for his requirements irrespective the product or the technological area I am responsible for.
I'll be back with more....
