The understanding of not understanding

Working for a product company brings certain problems in an agile project: who to build for. It's easy to say that 'Just make it configurable and flexible and all will be well', but I don't believe that's the case: software should be created to support processes and increasing flexibility and configurability might not do the trick all the times. And it's not about possibility to change labels: our sales manager firmly believes that the changing of labels do the trick: the reason for us not being successful in certain lines of business is that we don't use the right words. Well, that is partly true, but I also believe that different words means different things in different lines of business and even if you use the right word you might not do it in the right context.

For example, working in the service management area we have something called 'make rounds'. In a facility management company that means that a customer pays you to walk around in a building, checking stuff out. But in the security line of business it means that different customers pay for different parts of the route: the security guy has his route that is to be completed during a night. The needs are often very different and if you were to say to the security company that make rounds is to be supported the way they were to be supported in facility management, the security guy would know that you don't know anything about his business. So how could the product support his processes? Hey, no thanks!

The use of personas can often do the trick, but they should be used by all in a company to enable knowledge of our customers. But to make our salespersons understand that they don't understand is probably our greatest challenge right now.