Customer Obsession — A developer perspective.
We constantly hear about these terms like “Customer Obsession”, “Customer Delight” and “Customer is the King”. As an organization, we do brag about the extra mile that we had gone to do the same.
But, as a developer, I used to wonder what these are and what do they mean in my routine. Even If I understand, how do we incorporate them into our day-to-day activities. By far, developer’s routine is to fix bugs or implement features based on the defined priority set by their hierarchy.
This is intriguing on how we deliver values to our customers. I would like to share a few experiences of my own that changed the perspective of how I look at this trait.
The first instance was that I was on a customer call to support one of the products that I’m working with. Been with the product for 3 years or so. It was supposed to be a routine call and the customer was supposed to share the screens and explain the issue. Though I was able to relate to the issue, but not with the screens, I just reiterated that I work with such and such product and we are here to solve the issue with the SR####. Yes, indeed and the customer re-iterated the issue with the same screens. It took me a good 5–10 minutes to understand that it was a complete customization on their looks, which we supported as customization along with some localization.
Learning: The product you develop is not being used just the way it’s been tested internally. You really need to understand the business usecase of the customer and that is more than the actual requirements document (if you had one to start with)
I had been stumped several times on these aspects, that our product was potentially solving use-cases which had not been intended. It’s a by-product and can be viewed either ways.
The second instance was I was working on a deep technical product where the users had to be DBA’s (Database Administrators). I was working on a bug that’s technically complex to achieve in that version of the Database, whereas it was addressed in the subsequent release. But it was a blocker in their production instance, and we explained the issue to them technically and asked them to raise a patch with the DB vendor to get them fixed on the existing version or to move on to the next subsequent minor release. It was indeed a huge effort from their side, but they agreed to do so.
At the same time, I was working on a product which has too much of a functional impact and doesn’t need much of the technical depth. The users of the product are classified as business users rather than the technical users. The issue was a User Interface issue where the users might need to drag a little more on the vertical scrollbar to keep them working on the widget immediately after the deliberate save operation. This was classified as a P0 (Priority zero) and we went into a call to understand the nature of the issue given that it’s a P0. I was surprised to see a lot of people including one of their CXO’s had joined in to understand on what we had to say.
Learning: Know your customer and the impact of the issue. The priority is not just based on the depth of the technicality of the issue. It has a lot of other factors to it. I had faced numerous instances of these incidents that could be stated as examples.
The third instance was on the way while delivering enhancements into one of our new products. It’s bit unfortunate, but it’s true that we didn’t had any requirements document for this. We started with a one line requirement and was supposed to deliver a Proof-Of-Concept (POC), with none to clarify. Got accepted by the team and On Beta release, we figured out that this wasn’t the intended ask by the customer and had to back out the entire feature and it never made it to our product after then.
Learning: Understand the use-cases behind the feature development or even the simple bug fix. The question is not always about “how do you reproduce the issue or just looking for a reproducible environment”. The question is always about “why did the customer hit this issue in the first place”. A sequence of why’s to yourself would help you analyze the use-case, validate, and eventually provide better ways to solve them using your own product roadmap.
I had seen umpteen number of times, that the bug was solved, but not the actual use-cases. It had taken a series of tickets to get their use-cases delivered from the products.
Last but not the least, there are multitudes of deployment scenarios and multiple different restrictions in the customer end, that would really take that extra effort in supporting them. For example,
- Geographic/Policy Restrictions to share screens or logs or data.
2. A restriction on the data residuals and data movement across organizations/geographies.
Ask why? and what If? questions equally with the how? An important trait that you should inculcate to call yourself as “Customer Obsessed”.
1. It always helped me to go that extra mile for every bug fix. (i.e.) Along with the patch, the workarounds, and alternate ways to achieve the functionality with the product can be sent as customer notes, and it had really solved some major hiccups. Basically, the right recommendation at the right time can save you multitude of efforts as a team and as an organization.
2. When you don’t understand the usecase, it is highly probable that your solution isn’t going to work out magically in the customer’s instance. Raise questions to the persons involved and this might not be taken well.
a. One reason, they don’t have an answer to your question, and you have a reproducible environment to fix the issue.
b. Second, the most important is the customer commitment on that issue is been done and we need something to go with.
3. Always better to start with the use-cases -> requirements -> design -> implement and a fail-fast approach would be awesome.
At the end, all you need is to be customer-obsessed to deliver a great product rather than the good product and you can attune yourself by asking simple “Why” and What If ? along with How? questions to yourself…
