I love talking to customers. I really do. (Do you sense a “but” coming?)
One of the things I learned when I prepared to deal with customers is the old axiom, “The Customer is Always Right.” Now, while not technically true, the phrase intends to teach us that customers have unique points of view, and to understand their comments we need to understand their viewpoints. Customers don’t intentionally lie, so if they appear to be wrong they might be misinformed or they might have a strong opinion that differs from mine, and that opinion is based on their point of view and their experience. If a customer disagrees with me, it provides me a chance to learn their viewpoint. Sometimes, it takes a little work, but it’s easy compared to the situation in which I often find myself.
The situation: When customers disagree with one another.
I mention this topic because I’ve just finished a string of customer advisory councils and it’s amazing how passionately customers can disagree with one another. Should IBM i deliver functions more frequently, or less frequently? Should IBM provide more direction on how our technologies should be used, or less? Should new technologies be pervasive across all customer installations or only delivered to those who choose to use them? Which education material is most critical right now: that which is targeted at existing customers, or brand new users, or people who don’t know anything about the platform at all?
Oh, and before you make the wrong assumption, this is not about small customers all thinking one thing and large customers all thinking another. Small customers disagree with other small customers. ISVs disagree with other ISVs. Large companies have different opinions from one another, and even within different parts of their own organizations.
How do we deal with this? First, we examine the viewpoints of each side. Then, we try to find common ground. (Did you know software architects need to be diplomats?)
An example might be useful. Many customers don’t want us to increase the frequency of delivering new functions because they have a long “qualification” process to undergo (ensuring that their software runs just fine on the new release) each time a new release is rolled out, and they can’t afford the time and expense of frequent qualification. On the other hand, customers want new functions. Not every function completes at the same time, and there will always be something that’s not ready for a specific IBM i release. If we are able to complete a function three or six months after a major release is generally available, and we have customers who want the new capability and prefer not to wait for another major release.
Architecturally, then, we need to understand what forces a customer to enter a qualification phase. This can help us design delivery methods that don’t need to be consumed by customers concerned with qualification, and other methods that allow us to assure customers that requalification is not required.
Natural examples of this are more common than you might imagine. Each new model of hardware, for example, requires changes to the lowest levels of the operating system. We can’t always know the details of later models when the first models are shipped, and we certainly don’t want to ship support for those later models until we have had a chance to test that support fully. So we deliver new model support later, but since an existing customer is not affected in any way by the addition of a new model that they cannot possibly own, there’s no qualification required.
Each such disagreement between customers needs to be examined to find out if there is a core set of value that we can deliver to all parties, while appreciating their viewpoints. It’s not always possible, but it’s our goal. Because if You disagree with You, i still wants to satisfy both of You.
Comments