Should developers get involved in engaging with customers?

And what we can all learn from Mort the mouse lemur

Read time ~ 4 minutes. TLDR; yes, they should.

After my last blog, the area that got the most attention was around whether to put our creators (be it developers, engineers or designers) in front of customers. This prospect might seem frightening to both our developers and commercial teams, but let me explain through a laboured analogy. Bare with me.

I love to watch the film ‘Madagascar’ with my young son. In it, there’s a scene where the castaway animals from the New York Zoo (including our protagonist “Alex the Lion”) land in Madagascar and happen upon a petrified bunch of Lemurs, led by King Julien. How does King Julien know that these new giant animals are not “fierce savages”? Well, he takes the most cute and lovable mouse lemur called ‘Mort’ and dropkicks him in front of the animals to see if Alex the Lion eats him.

So at this point, Mort is our developer, Alex the Lion is our customer, and King Julien is someone who wants to see what happens. Usually me. Sounds pretty brutal right? Just to give you an idea of how commercial teams (certainly in the business-to-business product world) envisage this interaction going, here is Mort in this situation:

If the story ended here then this would be a horrifying way to engage with our customers. However, Gloria the Hippo soon scoops Mort up into his arms and assures him that everything’s OK. Alex befriends him too, although he’s a Lion so he’s still a bit scary. After a while, they’re all best of friends and sailing together in boats crewed by penguins and monkey powered biplanes </analogy>.

Kay…

Surely it stands to reason that if we as creators take the risk to build up a rapport with the people we’re designing for, it allows us to understand their pain points and motivations which are the reason we’re building their products in the first place. Understanding our customers’ pain points gives us that intrinsic drive that pushes us so much further than carrot / stick models, knowing that our work is actually helping human beings make their lives easier. Taking that initial first step is crucial in fuelling that drive.

Commercial teams need not worry – your customers and users will respect you for trying to understand them and treat them as humans. Your products will be better because your creators haven’t got pre-biases on what they’re thinking, and will have asked some interesting questions. And yes they might not know everything about your field and look a bit bewildered, but if they never get the opportunity, they will never get better or create that empathy.

Caveats

It is not the sole responsibility of developers to understand their customers and the user journey. A good Product Owner should be the primary contact with customers and users. However, they should be facilitating this interaction with the development team so that they get the best possible product.

In great organisations, especially those business-to-consumer models, there is a whole team dedicated to user/customer experience and product design that will integrate and facilitate these activities with all teams. If you don’t have this, to get started you should at least get in touch with some of the fantastic agencies dedicated to customer experience that the region has to offer – I can put you in touch with a few if you like 😉

And finally, four easy things developers can do in the short term

1. Start conducting usability tests if you don’t already. There are reams of literature on good test strategies including in “Don’t make me think”, however if you’re looking for a cheap hit here are some basic rules.

2. Find an easy going customer to practise on. Maybe a Gloria the Hippo, rather than an Alex the Lion. That latest bug that was filed? Call the customer to see what the problem was. If you’re nervous like Mort, you can always lead up to interactions through email, then phonecall, then face-to-face, but always remember there is immensely more value to be had gauging body language and tone of voice (Albert Mehrabian’s views are well documented – and cited – on importance of non-verbal cues)

3. Talk to your commercial teams about how best they can facilitate customer-developer interactions. They might have just never thought of the idea before.

4. Volunteer for customer visits. Commercial / product teams seem worried that developers will embarrass the company by not knowing anything about their domain or staying quiet. I’ve outlined above how this seems counter-intuitive.

And that’s it. Thanks for reading, as always interested to know who’s reading this, what you do and any comments you have on this or any more of my content. Thanks beautiful human for reading.

July 2020 Edit : I just felt that my wonderful experience of taking part in a Design Sprint last year should be noted as an excellent way to get closer to the customer. Whilst developers might not end up talking to the customer, it’s an intensely customer focused 5-day workshop that uses design thinking to produce a prototype of your idea directly to the customer at the end. Empathise, test assumptions quickly, and get that feel-good feeling after slogging a great idea out for a week.

<span>%d</span> bloggers like this: