One of the best parts of my job at LinkedIn is responsibility for a world-class User Experience & Design team. It’s a new and rapidly growing team, and with the addition of new people and new voices, I’ve really enjoyed the thoughtful discussions and debates that have been occurring.
Recently, an article featured on the Silicon Valley Product Group site spurred quite a bit of debate internally, and I thought it would be interesting to share some of those thoughts here. The issue, as per the title, was the merit of the old product stand-by of “eating your own dogfood”.
What does it mean?
If you aren’t familiar with the phrase, it dates back to the 1980s, and was one of the core elements of the Microsoft software development philosophy. (How many people in Silicon Valley realize that they are espousing a Microsoft-based software principle I don’t actually know…) It’s an oblique reference to old Alpo commercials, where Lorne Greene would say that it was so good, he feeds it to his own dogs. You’ve likely heard hundreds of commercials that make the same equivalent endorsement.
In software, this concept served at least three purposes:
- Convince customers that their products were good enough for general use, by providing an empirical example. For example, “We’ve been running our operations for the past year on this software, and the results are phenomenal!”
- Ensure that software developers and other employees “feel the pain” of their customers. The idea is that it is easy to ignore bugs, or miss simple problems with a product if you yourself don’t feel the pain personally. This is one the reasons, for examples, many companies actually try to use new products internally first before release.
- Ensure that software developers build applications and software that they themselves would use. This theory holds that if you can put yourself in the shoes of your customer, so to speak, then you’ll have more insight into the ideal features and design of your product.
The Argument
The article in SVPG aggressively staked out a position that focused on that third bullet point in particular, and several members of our design team rallied around the critique. This paragraph summarizes the problem well:
But the real issue here is not the importance of running your own software. The real issue is that this is just another symptom of a big problem we have in our industry, but especially here in the valley. We tend to believe that our customers and users are much more like ourselves than they really are.
For many designers, one of the most important reminders to begin every project with is the mantra, “The user is not like me.” For several members of our team, this reminder is crucial to great customer-centric design, because it forces you to do your homework on the actual needs and characteristics of your target user and use-cases. Too many designers, product managers, engineers and executives take the short cut of assuming that because they personally find a feature useful or annoying, that their personal experience will map directly to their customers.
For this group, the call to “eat your own dog food” potentially exposes the team to the danger that they will mistake their own personal reactions to the software with those of their customer. If you are immersed in LinkedIn, Facebook and Twitter on your iPhone, it’s easy to lose sight of the fact that most of your users, in fact, are not. In fact, the most extreme version of this argument says that by exposing yourself to heavily, you cannot avoid personally biasing your product decisions toward your own needs rather than the needs of your customers.
For others, the importance of using your own software on a regular basis is fundamental to building great product, for many of the reasons outlined above in the three bullet points. Needless to say, it’s a great debate if you are passionate about building customer-centric product and organization.
The Answer
Personally, I thought the SVPG piece was well balanced, but understated the reasons why companies who “eat their own dogfood” tend to outperform those that don’t over time.
It is very easy to “de-prioritize” and undervalue problems and issues that face users of your products if you don’t depend on them yourself. It is very easy to get attached to theoretical frameworks, market research, testing, and all sorts of valid means of evaluating how things work and what gets fixed.
But if you don’t use the product every day, chances are, you will undervalue real problems that your customers have, and overvalue ones that they don’t. More importantly, you’ll be lacking the context to see the patterns & causal factors in the research. The biggest problem with all forms of research is the issue of differentiating correlation from causality.
In our case, LinkedIn is a site for professionals. Every person in this company is a professional. Are LinkedIn employees representative of the entire span of professionals, or even the majority? No. Are LinkedIn employees a valid subset of professionals that should be able to use LinkedIn daily? Yes.
We are actively working to open up as many channels as possible to listen to our customers: usability, focus groups, customer service, email feedback, LinkedIn Answers, community commentary on this (and other) blogs, and of course site metrics & testing. At the same time, we are constantly using LinkedIn internally, as we endeavor to use the site on a daily basis to make ourselves more effective professionals.
I’m committed to finding balance between the two poles. The risks of poor product & design decisions on both ends of the spectrum are too high.
