Real Professionals Communicate in Use Cases!
“Can your system do Task A and Task B together?”, I asked.
“No, it’s one or the other” the trainer answered.
The trainer’s answer was 100% accurate. The system does not allow the user to do Task A and Task B simultaneously. It is designed to do only either Task A or B at a time.
But the answer didn’t really tell me what I needed to know.
Actually, it was a bit worse than that – the trainer’s answer nearly caused me not to use that system and to look for another one.
Two problems.
There were two problems.
Firstly, I asked the wrong question. My mistake was that I didn’t communicate to the trainer what I needed the system to do to solve my business problem; instead I asked the trainer about how the system worked and that’s exactly how he answered.
The trainer’s response did truly answer my question. His response correctly told me what the system does as defined by the question I asked. But it wasn’t what I needed to know.
Secondly, the trainer didn’t ask the critical clarifier: “what are you trying to achieve?”. Or, put another way, “what do you need the system to do?”.
Let’s try again.
Fast forward two weeks. This time using Use Case language.
“I need to achieve ‘X’ – any suggestions as to how I can achieve that?” I asked in a follow-up email exchange with the vendor’s first line support.
“Yes! If you use Task A in our system, then migrate to Task B with this method (they sent me a link to a very helpful video), you can achieve ‘X’.
And it worked! In fact, it worked extremely well.
A real situation.
If you can look past my use of A, B and X, this is a real situation that happened to me in the last four weeks.
The vendor has a brilliant system and I went on to use it for an event with great success. The trainer (actually the CEO of the vendor company!) was pressed for time and answered my question honestly and correctly during our first conversation.
When I followed up with their first line support with a Use Case-style question, I achieved my ‘X’ effectively and efficiently and, in all truth, to a standard better than I had hoped.
It’s fair to say that the trainer and I were both ‘at fault’. I should have asked questions based on my need, and he really should have sought clarification before answering directly.
Use cases
Most people reading this article will know what a ‘Use Case’ is. For the uninitiated, Use Cases are usually associated with system design. It is a method especially used by Business Analysts to capture requirements from users to describe what they need a new system to do. Use Cases are passed on to all those various clever system developers and designers and technical people to build a system to an agreed and thorough specification.
A skilled Business Analyst will work with a system user to distinguish between their ‘wants’ and their ‘needs’ and record those ‘needs’ in a Use Case form. This is a key point, as explained below.
A slight stretch of the meaning
Ok, ‘Use Case’ might have a more specific meaning in the discipline of system design, but the value remains the same. It helps us to find a language that transcends organisational and professional boundaries and address a thought-through need, not a whimsical want.
Practical value and benefits
When we work in a functional group, we possess a level of shared knowledge with our colleagues. We can convey meaning with each very efficiently using the technical language of our profession or occupation. Accountants communicate efficiently using the language of accountancy; every profession and occupation will have examples.
It’s different when communicating with organisational colleagues across functional boundaries, professions and occupations. In these cases, it is unlikely that you will be able to communicate using the same specific, technical language. I need my mechanic to explain technical detail about my car in very simple terms. No point trying to explain the operation of hybrid-vehicle power systems to me!
And so professionals may be well served by using Use Case language as a default means of communicating with each other.
Think of it this way: a trip to a retail store might be much more fulfilling or beneficial if the sales person asks you about how you will use the widget you have just asked for. By reaching in to their deeper knowledge of widgets, the sales person might advise you to buy a slightly different product that will be a better fit for what you need. That’s real service. That’s highly practical professionalism.
Benefits beyond the obvious.
Value and Respect: I well remember the delight when I asked my then-employer’s Management Information team to answer a question for me. Yes, ‘delight’. It surprised me!
Managers like me usually simply asked them to send them ‘XYZ’ data. They would then extract those data, pop them in to a spreadsheet and send them to the requesting manager.
This time, however, I asked them to help me answer a question; in other words, respond to a ‘need’.
The MI team set about using their admirable higher skills to deconstruct the question, identify and assemble data and then present their response in a meaningful way to help me find an answer. They examined the relevant data, interpreted the meaning and added valuable insight.
I received from them what I really needed; they felt valued and respected. Who knew that would happen? I learned my lesson that day! I didn’t realise it at the time, but Use Case language meant that the MI team and I were able to work across an organisational boundary using plain, common language to understand and respond to a management need.
When we use this sort of language, we are not ‘dumbing down’ our language. Quite the opposite. We are conveying a tacit respect that our colleagues will be able to deploy their higher skills to help us.
Empathy. It is also true that professionals are displaying empathy by taking this approach. We are respecting the fact that our cross-functional colleagues deal with nuance and complexity in their own work, even if we don’t see it or understand it.
How often might you hear someone say that ‘oh, Marketing can just whip something up’ or ‘how long could it possibly take Engineering to build a prototype’?
There is no thought or respect given to the work done by colleagues.
Clear Expectations. Communicating in Use Case language as a default forces you to think through issues. It means that even before you seek input or support from cross-functional colleagues, that you have distinguished your wants from your needs first. It means that you will communicate your needs clearly and supported by objective rationale. Ideally it means that your colleagues can seek clarification from you, or perhaps advise you on a better path to achieve your needs.
Your colleagues will have clarity about your expectations. They will not need to make tacit (or default) assumptions about what you want or the purpose you are looking to fill.
Your ‘Try Again’ Opportunity
When next you are having to communicate with cross-functional colleagues, pause, and ask yourself how best to communicate your need.
It might just speed things up, make for better outcomes and even cement good working relationships!
