Objectivity, Subjectivity, and Just Being Lucky in Product Development
If you’ve been involved in product development over the last few years, you’re likely to have encountered one of the many articles on adding empathy to your process to improve your products. While I certainly agree that we need more empathy in our lives in general, I’ve been noticing an inconvenient fact that there a lot of companies that have been successful, creating products that their users and customers love, without really being empathetic to them. This article will outline some of these different approaches, but ultimately come to the conclusion (#spoilers) that your best bet today as a product developer is to use an empathetic and subjective process.
Faster Horses
One of the things that’s different about the excitement around empathy in product development recently, especially tech, is that many industries operate on the assumption that they’re pursuing a “scientific” process which lionizes objectivity. In other words, the people in these industries ideally want to stand outside of a system and develop methods of observing it without changing it, only gradually introducing changes in a controlled way to determine the outcome. Empathy is about a subjective approach where we try to understand what users want and why by engaging with people rather than observing them dispassionately. There is a gradient here, but let’s use these as points on either side of the spectrum.
The subjective approach is particularly exciting in that it’s an acknowledgement by industries that their users are complicated and may behave in a way the product developers don’t understand because they cannot see what their users are seeing from another perspective. Thus the use of empathy, which we might reduce to “getting to know your users” or “becoming your users,” is an attempt to bridge this gap.
But why is mentioning empathy even necessary? Because a lot of the product developers are not like their users at all. Moreover, some very famous product developers have been successful in the past using the objective approach.
Let’s consider the “Faster horses” principle. Henry Ford probably didn’t say, “If I asked people what they wanted, they’d have said, ‘Faster horses,’” but he’s been quoted as saying for a lot time anyway. The takeaway of this quote is that users can’t always see what’s best for them and they sometimes need an outside, objective viewpoint to identify the right solution.
As a user of Apple products, I’ve certainly felt like they have taken this approach in the past as well. First they took away our floppy drives, then our CD drives, and soon all we’ll have is a single, USB-C connector. If they had asked me, I would have probably wanted the CD drive and loads of USB ports, but TBH my back and long battery life is thanking Apple right now.
These companies and their leaders are titans of industry for their forward thinking and telling us what we should do. But most people creating products are not going to have that same vision.
Letting your users tell you who they are
One category of product development that I’d like to touch on while we’re here is one where you don’t even know who your ideal user is. You may or may not be like them, but either way, you’re not accounting for them subjectively or objectively. I recently encountered an example of this seemingly odd kind of product while listening to the Startup Podcast on Twitch (Part 1, Part 2). They started out as a live streaming company, essentially trying to make the Truman Show IRL, but ended up as a massive company focussing on a market that (virtually?) no one would have predicted even existed a few years ago.
They provided a platform and their users told them where to go. To be fair, it certainly was not the obvious thing to do and spend time on, but they had already developed the product that their users wanted without knowing it. I think I’m safe in saying that they were very lucky in this happening, but platform development cannot be denied as a possible way to grow a huge company.
By X, for X
That leaves us with the “By X, for X” method of product development. When someone knows the problem they’re developing products for because they have that problem, they have more context and will likely develop a different solution than someone who doesn’t. The problem with many industries at the moment is that they’ve been filled with the same types of people for a long time and already solved many of their own problems. I’ll pick on my own industry, software development, as I know it best (#meta).
The software industry has only recently started publishing diversity numbers and let’s just say that there are many people with experiences that are not well-represented. We’re already well-covered for solving our own problems, e.g. coding environments, SaaS, APIs etc., but we’re not all Steve Jobs and we cannot all solve other people’s problems. Thus I’d argue that not only is it right that more under-represented people get involved in (at least) the software industry, but that there is a very reasonable hypothesis that we’re excluding an entire way of solving problems for many groups of people.
Many industries have already identified the subjective approach as beneficial in other areas of their business. The Toyota factory method, where any worker has the right to stop the production line and/or develop better tools recognizes the fact that workers on the line have a different and valuable perspective to contribute in addition to top-level management. If we could extend this principle to those outside our companies or current networks, we’re going to have a competitive advantage over those who do not.
Conclusion
None of the approaches I’ve outlined above are wrong. Clearly there are many ways to succeed, but some, like being a visionary or building a platform where the users discover themselves, aren’t easy to pull off. If you can do either one of those, go for it. If not, find a problem that you know and solve it or find other, thoughtful people who can tell you about their problems and support them in finding a solution.
