Empathy, Sympathy, and Compassion in Product Development

by Emil Ong — on  ,  ,  , 


Key takeaways

  • Empathy requires direct experience, sympathy does not, but both are valuable
  • Iterate to gain experience, being mindful to gain empathy and/or sympathy at the same time
  • Utilize sympathy in at least your first (or first few) iterations to get started
  • Empathy, if not rationalized in the business process, can lead to an overfitting solution with little business value


Empathy has lately become a popular word in a number of fields with which I interact, including design, data science, engineering, and product development/management. Its benefits are extolled as creating more meaningful products and services, and thus ultimately more successful and valuable ones. However little advice is given about how to acquire and employ empathy in your practice. This article will focus on product development, attempting to give a theoretical structure and practical tips on empathy, as well as the related topics of sympathy and compassion.


The definitions I offer below may differ from your understanding of these words, but I set them out to give a name to the topics I’d like to address.

  • Empathy is understanding the situation of another person via similar experiences in your own life.
  • Sympathy is understanding the situation of another person via imagination.
  • Compassion is caring about the situation of another person.

Reflecting upon these definitions, the common phrase I use is “the situation of another person.” What this usually means in world of product development is the problem that the person it trying to solve. However, there may be a number of components that we want to consider:

  • Demographics including age, gender, race, nationality, etc.
  • Limitations including economic, geographic, available services, etc.
  • Disabilities be they physical or mental
  • Personality types such as introversion/extroversion, creativity
  • Experience, especially as it relates to the problem they are attempting to solve

With these definitions in hand, let’s see how they fit into a product development process.

Product Development Process

Many different product development processes exist, so I’ll use my own (or at least my ideal process :D) as a template to talk about where empathy, sympathy, and compassion fit in. My process is akin to agile methodologies, though I won’t claim that it’s a capital-A Agile process. You may find similarities to Lean Startup, Customer Development, and simply the scientific process as well.

The process is as follows:

  1. Find and state a problem.
  2. Hypothesize a solution to the problem.
  3. Build your product.
  4. Measure the effectiveness of your product.
  5. Refactor and repeat.

Let’s dig deeper into each step and see how their tactical execution is affected by empathy.

Find and state a problem

This step is probably the most important for empathy, so I’ll be dissecting it quite a bit more than the others. Specifically, I’ll deal with the “find” and “state” parts of this step separately, as they each deserve their own attention.

Looking for problems

Let’s break down some of the different ways that you might discover a problem.

Discovery method Advantages Challenges
  • Encountering the problem in your own life or work
  • Noticing someone else in your life struggling
These examples are great ways to approach a problem because they have empathy built in. You are close to the problem and are thus trying to solve it for you or someone you know. These situations are classic and make a great story. You likely also have compassion for other people trying to solve this problem because it's one you face as well. It's easy to be too close to the problem in these situations. What that means is that your experience may differ from that of other people facing the same problem. Thus you need to be very careful either to limit the target of your solution to people in similar situations, sympathize with others in different situations, or gain experience to empathize with others in different situations. Moreover, if your experience is specific to you or a small set of people like you, your solution may not have much business value.
  • Being asked to work on the problem by someone you know who was already working on the problem
  • Sitting down to try to invent something or identify problems in order to start a business or find value
You have detachment from the problem, so you can approach it and the people it affects more uniformly. You must still have compassion (and ideally sympathy) to get started, but you have the opportunity to dive into the process and address the target group that presents the most business value. You might not have any experience in the problem you're considering solving, so you cannot have empathy (yet). So you need to have compassion in order to have any chance of success.

The second two discovery methods are, at least in my experience, more common ways of arriving into the development process. You might have joined a startup, been assigned a project at work, or just been looking for problems so you can make money. You often have to have the problem described to you for you even to understand its existence, much less its nuances.

Just to sum up compassion in these examples above, you need to care about solving this problem for people, even if you don’t share their experiences. If you don’t, your ability to gain empathy or sympathy is heavily diminished and along with the chances of your success. You don’t have to care about every problem, but you also do have to work on every problem either; you might look to solving something else.

Problem statements

The statement of the problem is highly related to finding the problem. My technique for this is user stories which take the form of:

    <persona> wants to <goal> so that <reason>.

User stories are a key part of the process where empathy and sympathy play a part. First, defining personas is important because you need to know who you’re talking about to empathize and therefore understand that person’s wants and reasons. A former colleague of mine used a process with sticky notes where we actually drew a face and gave a name to help make the persona real and relatable. Be as specific as is reasonable to start, then group later.

From strong personas, especially those with whom you empathize or sympathize, the goals and reasons often flow easily. If they are defined in such a way that you can identify with them, you can usually see the problems from their vantage point. One thing to note is that the outcome of the story should always end in value for the persona. This should be objective value in the form of money (e.g. in the case of business products), time (e.g. reducing the end-to-end time in something they’re already doing), or something else measurable. A general feeling of wellness, reducing anxiety, et al. are vague and not provable.

Gaining sympathy and empathy

Until now, I’ve discussed how empathy and sympathy are useful (or dangerous), but not how to gain them during your process. Let’s look at some techniques and how they can help.

It’s common during the first step (finding and stating a problem) to do customer interactions to find out what customers are facing, their requirements, etc. This usually takes the following forms:

Interaction type Commonality* Gainable Empathy Gainable Sympathy Notes
Customer interviews in which you ask customers about their problems and current approaches. Enterprise & expert products Low Low One of the great benefits of interviews is that they offer the chance to ask how customers feel about approaching the problem. Their feelings are potentially less observable in the other two interaction types. However, there's the notorious problem that interviewees often say and do different things. In a sense, they can at best sympathize with themselves!
Customer observation in which you watch customers go about their business and you see what issues they run into and how they try to solve them. All Low Moderate You have a much better chance of actually seeing and relating to the customer's actions as he or she encounters the problem with this approach than with interviewing. There are the usual warnings here about observer bias, the subject changing their behavior if they know they're being observed, etc. For the purposes of this discussion though, note that you're still not directly experiencing what they experience. Considering sympathy however, you probably have a better chance of seeing something relatable than in an interview scenario.
Doing what the customer does to find out how, from a first hand perspective, what the problems and current tools feel like. Consumer High (with caveats) High If you do have the opportunity to walk in the customer's shoes you're more likely to gain insights as to the nature of the problem. Be careful that you're mindful and understanding what you're gaining during this experience however. If you're targeting skilled craftspeople with years of experience and trying to make a better tool for them, you will not gain the experience they have on a daily basis with tourist stint. You may however gain valuable sympathy.

There’s also the hybrid interview approach which deserves mentioning, specifically that of asking people how they feel and what they’re trying to accomplish while either observing or taking part in their activity. It especially may impose observation bias, but can get to both feelings and action simultaneously in the best case.

Commonality above is of course based on my experience and YMMV. The empathy and sympathy columns should not be taken to mean that you shouldn’t do interviews or observation if you’re also doing what the customer does. All have their place and contribute to a holistic understanding of the customer’s experience. Use as many as you can, especially if they’re not common in your market segment. For example, if you’re developing a product for enterprise users, your chances of doing their job may be small, but it’s likely to be hugely valuable.

Hypothesize a solution

This is the step where you take what you learned in stating the problem, combine it with your cleverness, ingenuity, and outside experience to produce the statement of a possible solution. But don’t jump right into building just yet. Building is expensive and you can use your learnings to do some sanity checks on your hypothesis. You will now usually go back to customer interviews mentioned in the previous section to see if it’s worth proceeding. You can also imagine yourself in the shoes of the customer, but now armed with this hypothetical solution. But be aware that both you and the customer are trying to sympathize with your future selves. Neither of you can have empathy with the solution because it doesn’t exist yet. That’s why you have to build it…

Build the product

Empathy and sympathy of engineers toward the customers is important, but if the problem and hypothesis are well-defined, their main function should be sanity checking during the building process. In other words, the engineers should be keeping their customers in mind the whole time and validating that the product meets the user stories and use cases and alerting the product management when things aren’t going as planned. Outside of that function, engineers should be focusing on solving the problem to the specification of the hypothesis.

Measure the effectiveness of the product

Now that you have your product, it should be possible to validate whether it solves the problem you stated in the first step. Again, you can go about this with the customer interactions mentioned earlier. You can provide the product to the customer and observe them using it and you can use it yourself.

The results of each are the same. You have a good opportunity for gaining sympathetic understanding with observation. You may gain empathy or sympathy by using the product yourself. The value is the difference in experience between when the customer didn’t have the product and when they do.

Note that the practice of “dogfooding,” using your own product before release, must be conducted with care and a mind toward the highest empathy/sympathy gains. All too often, we use the product like builders of it rather than as customers.

Refactor and repeat

By this point in the process, you should have gained some additional insight on the customer, their process, and the effectiveness of the product than at the beginning.


During this entire article, I’ve addressed you as a product developer, but using all of my own experience. To get a bit meta, I’m using empathy and sympathy about the product development process to give you a product (this article) to help you improve your process. Some of this may not apply to your experience, your team, or your product, but I hope it’s been helpful. I’d like to emphasize that sympathy is incredibly valuable, especially when shared experience (and thus empathy) is not available to you, for example in cases where you are in a completely different demographic than your customer and that demographic is relevant to the problem. However it’s key that you interact with the customers and potentially have someone who can empathize with them on your team.


To be honest, in the entire article I’ve taken it as given that empathy and sympathy lead to better products. There’s certainly an argument that they do not need to be present in all parts of a business to be successful, but I think an argument in favor of them in product development might look a little like this article anyway. I might address this in a future post.