While a large portion of my communication with clients occurs indirectly through JIRA, emails, and calls, face-to-face meetings are incredibly important for deepening relations with clients and discussing large-scale changes to applications. Face-to-face meetings can distill hours worth of long email chains, ticket comments, and phone calls into a single discussion, but only if managed well. Here are some do’s and don’ts I’ve discovered to help make productive and useful face-to-face meetings.
Do: Repeat requests back to the client.
It’s easy to get excited and motivated during an in-person meeting and then start spouting off new ideas and ways to approach them. But often these ideas end up being misinterpreted when it’s actually time to develop them. As a developer, it’s important to use a key communication technique: repeating ideas back to the other party. Doing this ensures both parties are on the same page and agree on what is the desired end goal.
I personally try to do this twice for each request: once immediately after recognizing the request from the client, and again at the end of the meeting in a recap of the meeting as a whole.
Repeating the request early on can help smooth over miscommunications and can refocus issues while they are still fresh in everyone’s minds. It’s much better to catch problems or misunderstandings early in the process than hashing it out later remotely. Repeating the request as a part of the meeting summary at the end is very useful for making sure the scope, urgency, and necessity of a request are understood.
This kind of meeting rehash can also reveal that specific requests may not be necessary in light of hearing all the details of a project or feature said out loud all at once. A meeting summary of requests can also help highlight gaps in requests, pointing out spots where certain requests may require more work and effort to create than anticipated.
Don’t: Assume their level of technical knowledge
Jargon is a part of all careers and fields of expertise and programming is obviously no exception. While necessary when discussing issues with peers, it can be a major roadblock to communicating with clients.
I was guilty of this during a recent meeting with a client, where I commented that “we should not need to render the choices with Javascript, but could just pass them in directly when the page loads.” This ended up being an issue later, where the client did want options to change based on other options selected by the user, but at the time they didn’t understand that I was saying exactly the opposite.
If I’d have said something in more layman’s terms, such as “The options on this page should not need to change based on other options selected, so it should be a bit simpler to code and faster to load on the page”, it’s much more likely the client would have caught the misunderstanding between us during the face-to-face meeting, instead of much later during QA.
I’ve found asking “Do you understand what I mean by _____?” to be very effective at defusing this kind of problem. Initially, I was nervous asking this question as I didn’t want to sound insulting. I can’t think of a time where a client seemed off-put by that question, but I can definitely remember several instances where a client answered ‘No’ and I was able to better explain the whole situation!
Do: Have the site or application visually displayed on a screen to demonstrate any potential features that are discussed.
Having a version of the application itself up on a screen during an in-person meeting is a fantastic tool for making sure all parties are talking about the same thing. It also acts as a reality check on feature scope and potential implementation techniques. Once you are familiar with a project it is easy to talk through the flow of the site without visual aids, but our memories are not perfect.
A particular mistake I am prone to make is confusing where and when certain functionality occurs. Once I understand how an application as a whole handles data, I sometimes will muddle up exactly when and where data is received, changed, and rendered. This can be a problem when meeting face-to-face with clients.
They make a request, which I would quickly respond to saying it would be possible and easy to implement, only to discover later that the feature does not fit well into the current data flow and will be much more complex than expected.
Walking through the actual site with the client can be a great reminder of how the application actually works and can help keep everyone’s expectations and estimates realistic.
Don’t: Assume your level of knowledge of their business
The flip side of our previous don’t, being honest and realistic about your knowledge of the client’s business is essential to making face-to-face meetings (and general client communication!) work well.
When speaking in person with a client, the most common way to avoid this problem is not being afraid to ask questions. It can be intimidating to ask a client a question in certain circumstances, especially because it’s natural to want to impress clients! But assuming you understand certain aspects of a client’s business or their jargon can lead to serious miscommunications.
One specific question I like to ask during face-to-face meetings is, ‘How would you use this feature during your workday?’
Obviously not applicable to all circumstances but often their response can be extremely enlightening. It can give you insight into how a tool is actually being used, what the client’s overall intention is vs what the feature request actually is, and give you a better understanding of the client’s business logic.
Sometimes interrupting a client to ask a question is necessary as well. From personal experience, I know there have been times a client has started speaking at length about a topic or feature where there is a term or idea I do not understand but was nervous to stop them and ask for clarification. Asking for clarification much later often requires the client to repeat themselves again, as you now have to try and understand the whole request from the client again with the new insight of that particular term or idea. This is a waste of everyone’s time and can is often frustrating for everyone involved.
Never be afraid to admit when you are ignorant of a client’s business or intentions!
Do: Create actionable items immediately after a meeting
Face-to-face meetings can be a glut of information. Ideas, features, deadlines, priorities, and more are often discussed and agreed upon. All this information is fantastic but can get muddled and become less valuable if there is not timely follow-up.
I’ve started getting into a habit of creating applicable tickets as soon as possible after a face-to-face meeting. This ensures that the meeting has actionable and trackable goals that are being implemented and helps you extract the most meaningful information from the meeting.
It also means the meeting is fresh in the client’s mind and having the ticket available for comment can be beneficial for them as well. In instances where I haven't done this, I’ve often found myself rifling through notebooks and legal pads weeks later to find specific notes from a face-to-face meeting. Creating tickets, retyping notes, or some other way of making action items immediately after speaking with a client is a great way to ensure the maximum amount of information from that meeting persists and is shared with peers and the client.
These tips should help you hold more productive face-to-face meetings with your clients. When you're able to make the most of your in-person time, you'll leave with more actionable takeaways and less confusion in your communication going forward.
Tags: