How do you think of your customers? Do you think you’re customer-driven? Or are you product-driven? Venkatesh Rao argues that you’re not customer-driven and has an interesting taxonomy for the ways in which you aren’t customer-driven. I think this hierarchy is really interesting, partly because of varying degrees of hubris in the ladder. It shows that the “expert vs layperson,” which I recoil from, is really only halfway down the ladder toward treating other humans poorly. Let’s look at the viewpoint of the expert vs. layperson in the context of application design.
I am expert, hear me roar
One thing that has always bothered me is the phenomenon of the expert coming in to fix a situation. The highly paid consultant, who knows precisely how to fix your company; the philanthropist who wants to fix the world; the well-meaning colleague who swoops in to fix a problem you’ve never seen before. All of these archetypes end up causing harm, despite their varying degrees of good intentions. Nevermind issues in the sociopolitical sphere; that’s a whole other ball of wax.
By playing an expert, you often rob the other part of a learning experience. Humans learn best from our own failures and examining the outcome. I make this mistake often; to help my teammates get over a blocker that they have, I swoop in with my expertise and solve the problem for them. Ultimately, I think that is harmful to their learning. Still, it’s a natural response. What does this have to do with product design?
Creator as the expert
As a creator, when you’re designing a system – whether that’s in user experience, visual aesthetic, or during construction – you’re the expert. You know exactly how the system works, what it should do, and why. You’ve thought about the corner cases, the happy path, and all the ways things can go awry. Because of this, it’s tempting to discount feedback that you receive from customers. After all, if there was a problem, you would have thought about it, right?
This attitude is the very definition of hubris. Yes, you are designing a system for your customer to use. But, at the end of the day, your customer is the one who uses it. It doesn’t matter how optimized you’ve made the user flow. The customer doesn’t care how carefully you’ve considered the communication in your app if it doesn’t do what she needs it do. Your expertise blinds you to the way that you communicate with your customer.
Learning on two fronts
As a tech lead, you must learn to lead your team without robbing them of the freedom to make mistakes and learn from them. Likewise, as a product designer or developer, you need to listen and learn about the mistakes your customers make. Don’t try to tell them that you know better; they know better because they are the ones that are using the product. If you allow your hubris to blind you enough, you will start to lose customers. You probably aren’t customer-driven, but you can at least become customer-informed.
I think these two fronts are two of the most important for tech leads to think about. You can’t know everything and at the end of the day, you usually do not use the system on which you work all day. You should learn to listen to those who do. In some cases, that will be the support team at your company; even though they are internal stakeholders, they are your customers too.
How do you fight against the hubris of being a creator? Do you find it hard to let go? Does your expertise impede your ability to lead your team?
