Bill Gates is quoted as saying. “I will always choose a lazy person to do a difficult job, because he(or she) will find an easy way to do it”.
Great Salespeople are inherently “lazy”. This is a good thing. Salespeople are time poor and good at identifying the fastest way to complete something. When it comes to designing software to improve the productivity of Salespeople. Their ability to find the fewest number of steps to complete a task can be relied on.
All too often I find a CRM environment that is technically working. It's been built as designed, 100% to spec. It does “exactly” what the users “asked” for. But the users hate it. The sequence in which things need to be done is no easier than before. How software solves something is as important as what it solves. It is the "how" that drives user adoption.
Ask a Salesperson how they would like their CRM software to best support their Sales activities. There is seldom any shortage of suggestions on what features and functionality they would need to reduce the number of steps to complete an activity.
Responses typically focus on labour saving functionality, like the need to duplicate and modify rather than reinvent. The ability to quickly record and retrieve details of Customer interactions, for example meetings, phone calls or email. This list goes on and inevitably covers off Opportunity Management and Quoting along the way.
Over time I have come to place a high degree of reliance on Salespeople to correctly identify the most valuable bits of CRM functionality. The bits of functionality that will actually save them time. The bits of functionality they would actually use, should the opportunity arise. These are the bits that are most likely to drive adoption. These bits need to be interwoven with all the other functionality that is required of the overall solution by the organisation.
Here is the difficulty for the Solution Architect. A Salesperson explaining how they would like to work in Utopia does not constitute a detailed system design. For the most part, few Salespeople would be able articulate in precise detail how this would look in practical terms on a computer screen. Nor exactly what sequence stuff needs to captured or exactly how they things needs to work, under the hood. Nor do they need to.
I have found simple prototypes are a good way to show people how things could work for them. Prototypes are a great mechanism to quickly identify what will work and highlight those areas that need to be improved on.
Steve Jobs was quoted as saying “You’ve got to show me some stuff, and I’ll know it (the solution) when I see it.” Salespeople know a viable solution when they see it.
To be clear. I am not advocating that every Salesperson in the organisation needs to be canvassed, but rather a smaller a group, who would well represent what functionality would be required in the field.
Translating requirements into functionality, in my experience, is a process. It’s not a one off activity. It's a process of ongoing validation and education. It's a process whereby I “mockup screens” and build mini “proto types” of what might be. Demonstrating these to my intended users for the purposes of evaluating how it would hold up in the field. Bear in mind that what may appear intuitive and easy to a software developer, may often appear cumbersome and difficult to an end user.
Validating a solution with users early achieves several things:
An upside to this design validation process is that salespeople, quickly become educated as to capabilities of their soon to be adopted technology. What this means is that they will often assist you in finding the inevitable compromises often needed when a desirable bit of functionality may cause time or budget conflict during delivery.
When it comes to designing great CRM Solutions Salespeople are your friends. They fill you in on the How. It's the How that drives adoption.