Tech Engagement - Crafting Strong Client Partnerships

As creators and in support of mission-critical software, we are not just building software that supports our clients. We are designing layers of languages, which we like to call abstractions, system interfaces, and graphical user interfaces. Abstract too much, and the language becomes extremely terse, resembling jargon filled with acronyms. Such abstractions lead to lengthy onboarding of new engineering staff and clients. Abstract ineffectively, and the language becomes very verbose and gruesome to use.

Designing languages that are easy to read and can be used for daily interactions is a complex task that requires expertise. However, there is a simple yet crucial ingredient that can be added to every language design - involving the people who will be using it regularly. While we all understand the importance of including clients in the language design process, it’s often easier said than done. We treat it as a second-class idea, assuming that a coordinator can replace the client to some extent or that it can be squeezed out within an interview or two.

Let’s raise our standards on this. Let’s stop making this a nice-to-have and make it a must-have. I am not only suggesting the right thing to do with the immense responsibility we are given as creators of mission-critical systems people blindly rely on, but it is also the commercially most lucrative approach.

In this article, we will connect entire teams to the client.
We want to continue engineering user experiences and go further, 
going all the way and experiencing walking in our client's shoes. 
And when it makes sense to do so, their clients' shoes.

Connecting with our clients needs and pain

The whole premise of you building software to support your clients depends on your client seeing value in your help. If they don’t perceive that help, they will still use software, but not yours. You become the social project of your company’s investor, whether that is you or anyone else. If you don’t understand their pain before using your services, or their pain while using your services, you are going to have a hard time solving the problems they really need solved.

"Business people and developers must work together daily throughout the project."

-- Principles behind the Agile Manifesto

In my experience, teams can quickly be many layers removed from the client’s pain. It might be because it’s not enjoyable to feel pain, or it might be because the client’s problem domain feels specialized and inscrutable. Both are valid reasons to unconsciously avoid connecting with what your client needs. Doing so does put you at risk of only adding value on paper, if at all.

Rather than being a React, Elixir, [insert any technology name here], engineer, you might first be an expert in creating solutions for your clients’ problems, which presupposes an advanced understanding of them. Focusing on the right concern, the one that keeps them up at night or makes them cringe, is how you capture and keep repeat clients.

Beyond our standard tools to understand a client’s problem

Active listening matters, discussing potential solutions with the client matters, and going through user experience sessions are very helpful, … but you will rapidly become undifferentiated and experienced as an “on-paper partner” rather than a business partner your client knows they can trust with their money, time and as a critical part of their business processes.

Instead, seriously consider the very old-school but highly effective ways:

• Regularly use first-level support interactions to directly interact with your users rather than have them solely siloed into support roles.
• True Dogfooding, where you use your product as a critical part of your business processes
• If that is not possible, ask to go through some of your client’s apprenticeship or internship programs to walk in their shoes literally.
• As a last resort, if nothing else is possible, study their industry and create a mock company that is a simplified version of your client’s business. Expand that model over time to present your client’s business better and better over time.

Example in the worst case scenario: Mock dogfooding. Whatever you do, don’t delay getting into your client’s shoes.

Once upon a time, I joined a company that sold integrations to e-commerce sites, and while onboarding, I noticed something curious. The team I was taking over from had not dealt with any of the support tickets from clients. The support was unclear about how anything had to be setup. The integration teams struggled to onboard new clients. And somehow.. no one told me to do anything about it. It might have been because of how resilient these colleagues were who somehow made it work without it, so it was not even on the map to fix.

Despite knowing very little about the industry, the product, how to onboard clients or anything at all, I organized workshops at every global location. I included every team involved with this product. As I did so, I realized that not a single person in the company had gone through all the steps that we expected clients to do.

Armed with an extremely simple mock e-commerce app, I went through the theory and we implemented from start to finish for both iOS and android. Every person went through each step and discovered their issues. We mob-debugged each problematic piece. Only a fraction of the attendees were even developers. Product managers, product owners, business support, integration specialists, and every development team involved (happily) went through ALL the steps.

Got them! Maybe. Well, I know about some real pain points but not all.

Now, imagine you go through that same kind of process. You and your colleagues will experience pain. If this was the first time for all involved, everyone is likely to experience tremendous pain. That being said, nearly all the feedback we received was that we stopped making the product a black box.

Mission accomplished, right? All involved teams will have a better understanding of all parts, but be careful to connect the dots to what the client values. Refrain from assuming that what you found painful is what your clients will find most distressing.

Some of our clients needed help to hire iOS developers. Others found they needed help talking to their backend engineers. Now that we spoke the same language, we could dive very deep into their day-to-day perceived pain points.

Feedback into the sales process

Once you have gone through it, step by step, and tested every corner of your product, you learn about parts you disliked and others you liked. That’s a meaningful success, but we want to be fully aware that the people using the product are not always the sole decision-makers.

Once we factored that in, a significant next step is to update our knowledge by sitting with sales and understanding what decision-makers truly value and look for, as well as update the sales team about some points we believe we add even more value than we thought.

And now our teams are up-to-date as true business partners to the clients. We tell people to smile while on the phone with clients because they will notice. Will they notice it when entire teams experience this compact discovery process together, and who walked in the client’s shoes?

While in my story, we had not completed the loop with the sales team, we still doubled the number of customers we had the following year for this particular integration. Client onboarding took a tenth of the time. Our conversations with clients were much more profound about what they can do with the product and maximize the value they receive instead of just trying to get it to somehow work to check off a box.

Conclusion

Here, we took the worst-case scenario, where the interaction is minimal with clients, and made an effort to make it vastly more “real”. The pay-off was immediate, although we had to repeat the exercise at least once a year, so it is not just a distant memory, and to give the experience to newly onboarded staff.

As users, we often blindly trust our business partners to share common interests and incentives. We pay them, after all. But when they don’t actively try to understand our daily lives, we won’t treat them as partners. They become more of a commodity, and we won’t share the feedback they need to give us further value.

Keep your clients from being so far removed from your understanding that they have varying experiences with your team. When you say you are client-focused, follow up with actions to set up your team to walk in your client’s shoes.