Why user empathy is a product engineering skill & five tactics how to gain it
Why user empathy is a product engineering skill & five tactics how to gain it
Why engineers must use the products they're building, how to speak with their users, and what to talk about within their teams and others in the organization.
Hey folks, Ilija here! 👋 Welcome to the first issue of Captain’s Codebook, published on Substack. You are receiving this email because you signed up to receive my newsletter on my blog, or via Substack.
Captain’s Codebook, is my latest newsletter, where I will be paying respect to the unsung heroes of our industry - product engineers, who build delightful experiences for their customers. You can read more about it here.
To receive all the full articles and support Captain’s Codebook, consider subscribing 👇
Now, onto the latest issue…
BLUF1: Top product engineers use the product they are building and talk with their users or someone that talks with them regularly.
-
To be a good product engineer, you need empathy for your users. But the users' happiness doesn't stem from you fulfilling their wishes. It's not about them getting the features that they asked for. After all, product engineers don't sell ice cream - you are not in the business of making people happy. Instead, it's about understanding how your product solves your users' problems and how it fails to do so.
Someone recently told me: to learn to do something; you have to try to do the thing. Following the same thinking, product engineers must become users to build empathy for them. Or get really close to it.
Product engineers have an unfair disadvantage. Imagine you, a product engineer, suddenly lose all context you carry around in your brain. Stuff like "the DeductDicountsService class substracts the discounts from the subtotal." Product engineers must nurture the ability to look at their product as an outsider — a nobody. A visitor is deciding whether they should take that 14 days trial period or not. Looking from the outside seems challenging with all that context in your brain, doesn't it?
A few companies ago, I worked on an exciting product. As an auction website (like eBay), it had a two-sided marketplace dynamic baked in. I loved the built-in levers of the marketplace that we, the product teams, could pull and tilt the market in one direction.
For example, we noticed that our sellers were putting a markup on the shipping rates. So, instead of "redressing" these sellers, we pulled a few levers:
We integrated with shipping provider APIs, which gave sellers realistic shipping prices for the items they were selling.
We added a "Free shipping to me" filter to the search engine results page.
Added sliding facet on the search engine results page, e.g., the buyer could specify the range they're willing to pay for shipping.
While putting a new item for sale, we added a sliding indicator to what percentile the shipping rates were in the item category.
With the marketing team, we ran "Free shipping" campaigns.
A classic example of the centuries-old adage: the carrot instead of the stick. We encouraged lower/free shipping rates instead of reprimanding them for the high rates. We ran tests with each change we added - without a doubt, the data showed improvement. Shipping prices were dropping significantly across the marketplace.
Why am I droning on about this? It was a fascinating marketplace product, yet the company never figured out how employees (especially the product teams) could participate in the marketplace fairly and safely. The marketplace served a particular niche, requiring some expertise to be a successful trader. Sure, we did get an insignificant coupon every once in a while to attempt to buy something at the auctions, but product teams could never truly put themselves in the sellers' shoes. Imagine being on the sellers' product team but never being an actual seller. Bonkers!
The product management team started visiting sellers to try and understand their business. We learned that some sellers were enthusiasts or collectors, reselling stuff from their garages. But there were some advanced sellers - companies transacting as professional sellers on the marketplace. While helpful, seller visits were inconvenient: required preparation, scheduling, traveling on location, incurring expenses, being away for a day or two, etc.
It proved hard to get into the shoes of the sellers. And we couldn't put our boots on and visit them, too. Adding insult to injury, seller visits were exclusive for the product managers. Due to wrong incentives, to my knowledge, no engineers or designers ever visited a seller.
To do justice to any past colleagues reading this, there were attempts to change the status quo. Namely, one grassroots initiative: the company agreed to sponsor groups of 5-6 employees with a small budget (~€100 per group), so they would use it to start buying and reselling on the marketplace for a couple of months. While a significant first step, the success was spotty at best - most folks couldn't trade up after two trades. Therefore, their insight into being a seller was inadequate. There were a few exceptions where folks traded up to a human-size figure of a celebrity or some awkward taxidermy. But these items were never resold and remained as office decor after the initiative finished.
At the time, I didn't think that product teams were blind to their sellers' experience in the marketplace. It seemed like it was the standard way to do things. I accepted it as it's what the company decided to do. In hindsight, I think this was a massive loss for the company. No engineer ever understood how sellers worked or thought about the marketplace. They couldn't ask questions to them nor see the operational difference between large and small sellers or their differing needs and pain points. It was like building a product for a white rhino - you know they exist, but it's unlikely you'll ever see one.
How are you supposed to develop empathy or understanding for someone you've only heard exists? Though product metrics? Split test results? I think not. Ultimately, sellers were always underserved in this marketplace. And it all boiled down to the fact that the product team had an easier time getting into the buyers' shoes.
So, what can you, a product engineer, do to become more empathetic to your users' situation? I have some obvious advice to give you; you will be nodding while reading and yet still hate me at the end. I promise.
1. Use the damn thing
Like, seriously, use your product. It is paramount that you understand how it feels to use the product. If the product resides in a weird, perhaps regulated domain, then you have to work out with the others in the company how you all can use the product without giving the company legal exposure.
Maybe there's an employee-only instance you can spin up? For example, you could make it private only within the company's network. Or perhaps, use the roles system of the product so employee listings can be seen only by other employees, not users?
Some delivery services, like DoorDash or Instacart, have programs where every employee has to do a short stint as a shopper. Even Airbnb's CEO Brian Chesky tweeted at the beginning of 2022 that he will be "staying in a different town or city every couple weeks" and that "for now my home will be an Airbnb somewhere":
As you can see, every company does things a bit differently, depending on their product. Another example is Apple: back in 1981, Apple's then-president, Mike Scott, told the company, "NO MORE TYPEWRITERS ARE TO BE PURCHASED, LEASED, etc., etc." If they were to reinvent word processing, Apple had to move away from the old way of doing things.
As you can see, the examples vary wildly based on the product and industry the company is in. (If you need help with dogfooding ideas, drop me a comment here or ping me on Twitter.) But one thing is sure: the product team must use the product!
2. Talk to your users
In 2021, Shopify's engineering org published an article about "bridging the gap between developers and end users." They explain how they structured a program through which developers will communicate and connect with customers. It seems they agree with my thesis - there are many benefits of talking with your customers, i.e.:
Providing perspective on how customers interact with products
Creating new experiences from customer workarounds
Expanding domain knowledge
Developing valuable interpersonal skills
The easiest way to bridge the gap is to take on customer support calls. Many companies have internal programs where the product team can shadow a CS agent. One of my previous employers (Scribd) had such a program, and a friend who works at Instacart also shared that they have a similar program.
In the article, Shopify took the same approach as the companies mentioned above. They established shadowing sessions, where product engineers follow a Support Advisor for one hour as they take questions in real-time from merchants through chat, phone, or email. Participation in these shadowing sessions is voluntary but strongly encouraged.
3. Talk to your users, via proxies
Another instrumental tactic is to talk to your users, but via proxies. Be warned: like with reverse proxies, you might get packet loss or latency. But I'd wager that the benefits outweigh the deficiencies. Talking to users via proxies is excellent because they provide a synthesized or summarized view of a given topic or challenge.
The UX research team is usually a stimulating bunch to talk to. They typically study a set of users and their requirements to add realistic context and insights to the overall design process. Often UX researchers will sit next to the users or use screen-sharing software and observe how selected customers use the product. Such exercise provides invaluable insights into the product – use it.
Ask them about aspects of the product that interest you. For example, if you're building the invoicing software, discuss how users found the invoices' compatibility with their business, if there are any new/unknown use cases that you weren't aware of, and so on. Protip: you can always ask to join the UX research sessions. I guarantee it'll blow your mind.
Another approach is Shopify's internal podcast. This podcast focuses on merchant experiences and allows asynchronous learning at an individual pace. It contains clips from a support call and a discussion between the Support Advisor who took the call and the podcast host.
Last but not least, speak with your product manager. It's their job to be the users' ambassadors in the company.
4. Talk to people that talk to your users
There are a bunch of people in any company whose job is to communicate with and support customers. So naturally, these people have a treasure trove of insights and feedback they would love to share with you. Often, they might already have aggregated the feedback they've gotten, backed up with some stats.
Companies employ account managers to nurture and deepen their relationships with enterprise customers. While non-technical, account managers know what is top of mind for their customers because they have a good relationship with the customer company's founder or product manager(s). Their relationship gives them context on the strategy or bets that the customer might be taking.
For example, the account manager might know about the customer's internal launches because of the solid relationship. They might also know when they plan to finish the integration of your new API. During the holiday season (e.g., Black Friday/Cyber Monday), the customer will inform the account manager of the expected traffic and if they have any scalability concerns or questions. The insights into the customer's business are invaluable information for product engineers - it's context that's impossible to get through other channels.
Solution architects are another group that has even more exciting insights. A solution architect provides technical support and advice. Any solution architect worth their salt always takes the time to understand the customer. They dive deep into the business, the product, how they use your product, technical details, etc.
For product engineers, these are the perfect people to talk to - they understand both the customer and your product very well and can speak to where our product falls short. They are technologists and speak the same language as you, product engineers. Solution architects can also discuss the customer's tech stack and how they integrate your product. These insights can surface unforeseen shortcomings of the APIs, the documentation, or the product.
Last but not least - customer support agents. Unfortunately, these folks' job attracts a lot of negative feedback from customers. Customer support agents can speak to all the different problems customers are facing. They always have a library of workarounds they share with customers to get them unstuck. So, prepare to hear some honest criticism about the thing you've built. While the feedback might bruise your ego, you will gain a lot of empathy for your users.
5. Talk to people that talk to potential users
Sales agents are another group that brings in a different kind of insight. They can tell you how inferior your product is to the competitors'. Losing a deal to a competitor is a painful part of the sales agents' job, so they indeed have a laundry list of things that the competition does better. So hear them out - they can help you close the competition gap and advise the rest of the organization on better positioning for the product.
Similar to engineers, the best sales folks specialize in a specific domain. But in contrast to software engineers, the best sales agents have decades of experience in a particular industry. As a result, these folks are an asset: not only do they understand the domain, but they also know how the industry has evolved.
And that’s it for this week! If you liked this, consider doing any of these:
1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.
3) 🧠 Ping me — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Let me know what’s on your mind!
Until next time,
Ilija
Bottom line, up front.