Advanced friction logs: Empathy Sessions

In 2018, I wrote a blog post about Friction Logging. Friction logs are one of my favorite DevRel tools, and I share that post with mentees regularly. If you haven’t read that blog, I recommend reviewing it since this post assumes familiarity with the friction log format.

But what do you do if a friction log isn’t convincing your stakeholders or they need to urgently address developer pain points? That’s when I set up an empathy session.

Empathy sessions, or empathetic engineering, aren’t one of my ideas. I learned this technique from Ray Tsang, Kelsey Hightower, and Kim Bannerman. When executed well, it is one of the most effective ways I’ve found to influence a product roadmap. I’ve seen well-done empathy sessions cause launches to slip while aspects of the product were redesigned to improve the developer experience.

What is an Empathy Session?

An empathy session is a group friction-logging activity for the team that builds a product or feature. Traditionally, you gather all the engineers, product managers, and others in a room and ask them to complete a realistic user task with their product in small groups. While they work on the task, they track their progress and feedback in a friction log. After an hour or so, each group shares some notes from their experience and identifies what they think are the most urgent friction points to address.

Seems simple, right?

A good empathy session can be simple to run. And many companies do similar activities. However, to get the most impact from a session, there are many subtle details to optimize. Let’s dig into the ones I believe are most important.

Important things to consider

For a successful empathy session, the most important thing you can do is ensure the right people are in the room. You need to make sure that at least a few decision-makers are present. I also want all the folks who write the code and design the product to participate, but the group needs to be empowered to act on what they learned. And usually that requires a decision-maker or two in the room. I also like to secure a promise from the decision-makers that the team has the capacity to address the top friction found.

The second most important thing to a successful empathy session is task selection. Your chosen task should highlight specific developer friction you already know about and want to draw attention to. The task also needs to be something that attendees agree should be doable in the time available. If participants think the task is unreasonable, they won’t be as receptive to making product changes.

Third, you need to set the rules of engagement. I set a rule for the sessions I run: “No internal resources.” That means no internal docs, no internal accounts with allow-list access, no checking internal reporting when you get an error, and no messaging the person who built the feature when you get stuck. The goal is for the participants to get an accurate understanding of the experience of external developers. And external devs don’t have access to internal docs. For some sessions, I’ve even had teams use loaner laptops so they don’t have access to their editors and any product-specific customizations they’ve made.

Tips for running effective empathy sessions

I learned a few tips through trial and error that can help you run effective empathy sessions that folks enjoy and want to repeat.

First, an empathy session isn’t a bug bash. Bug bashes focus on a particular feature or product. Empathy sessions focus on a single user story that likely uses multiple features and products. Bug bashes are usually open-ended, with people exploring different parts of a feature. In an empathy session, everyone works through the same task. But mostly, bug bashes are focused on finding bugs and technical issues. At a good empathy session, you are just as likely to identify missing documentation, UX improvements, or entirely missing functionality.

Second, it is essential to let folks get frustrated. An empathy session aims to develop empathy for user pain points by experiencing them personally. Frustration is by design. But it is tough for most folks to watch their co-workers struggle and not jump in to unblock them. After a couple of less successful sessions, I now remind any facilitators and TAs to offer advice or hints but do not prevent attendees from feeling friction.

However, you also can’t let folks get too frustrated. Folks only stay engaged if they feel like they are making progress. The best way to control frustration is with the task you select. I know I’ve hit the right level of frustration if folks ask for ten more minutes when I call time. You also need to make sure folks get frustrated in the right places. Consider doing any necessary setup ahead of time if the setup isn’t part of the user story. That way, attendees can get right to the task and not waste time running through setup steps. And pick technologies your attendees are comfortable with. If the attendees only know Java, don’t choose a Python task because they will find friction with Python instead of with the product.

Finally, keep it short and fun. I think the sweet spot for sessions is between 2 and 3 hours. A 2-3 hour session usually gives 60-90 minutes for running through the user story. The rest of the time inevitably goes to intros, sharing, breaks, and logistical hiccups. It is also easier to keep the energy high with short sessions. To make the experience fun, you can also provide snacks, play upbeat background music, or even offer not-so-serious prizes like “most obscure bug.”

Variations for remote teams

I much prefer to do these activities in person. I’ve worked with several teams that will work an empathy and friction session into an offsite. But I know that’s not always possible. So, if you want to run one of these sessions virtually, you have a couple of options.

Option one is to do the activity all together on a call. A good format is to do the intros and share on a single call, then use the Google Meet breakout rooms feature to divide people into teams of 3-4 to work through the task. TAs and facilitators can pop into different breakout rooms to check on folks and help as needed. In my experience, this works, but engagement is lower than in-person sessions. It is easier for someone to get distracted by other things. It also is hard to have teams use loaner hardware in these sessions.

Another option is to have folks work through the task independently during a specific week. Doing a session asynchronously like this gives participants much more flexibility in scheduling the empathy friction log around their other commitments. It also allows you to choose a task that takes more than 60-90 minutes to complete. The downside is that your TAs have to be available during the entire week to assist with issues. And there are usually more issues since folks work independently instead of in a team and can’t ask a teammate for help.

Closing thoughts

While empathy sessions aren’t as easy as standard friction logs, they can change product roadmaps. I’ve found them especially useful for calling attention to setup/installation issues and integration issues between products. These tend to be things that product teams don’t look at often but are crucial to a solid developer experience. If you end up running an empathy session at your company, let me know how it goes, and share your tips for having an effective session.