Is Familiarity Killing Your Project Before You Even Launch?
The blog post headline analyzer will score your overall headline quality and rate its ability to result in social shares, increased traffic, and SEO value.Test every headline before you publish. Try the Headline Analyzer »
Readers don’t like unfamiliarity, but unfamiliarity might actually help your team.
The developers here at CoSchedule had been working for a while on the multi-scheduler, a highly requested feature. I hadn’t been much involved in that feature like I had with some of the others. The UI design, the capabilities, how it worked–I only had a scant knowledge of what they were building.
The multi-scheduler was finally launched, and I was excited to use it. This feature was going to make things much easier. I had my notebook out and prepared to jot down any questions or bugs I might find and started to use it. I set out to use it with a blog post, sharing the post on all of our social networks with this new feature.
Any guesses on what happened?
The Problem With Familiarity
When you are too familiar with something, you don’t see what is right in front of your eyes. It’s easy for your mind to get set in a rut.
Familiarity is why it is more difficult to catch the errors or edits in your own writing (or code) than in the writing (or code) of others. You’ve become used to–and normalized–the mistake by repeatedly creating or seeing it.
“It isn’t a bad thing,” I said later, after testing the new CoSchedule features, “that I’m not always heavily involved in the development.”
It’s a question of familiarity.
The more familiar you become with your product or service or website, the more unqualified you become to judge it objectively. That doesn’t feel true, but it is. – Cliff Seal, Logos CreativeClick To Tweet
InnoCentive is a site where people who need problems solved make them available for “solvers.” These are complex problems that range from medical to engineering. A study by researchers at the Harvard Business School revealed something interesting about the solutions that came through InnoCentive: not only did problems get solved (33% on time, even), but they tended to be solved by people operating on the “fringe of their expertise.”
In other words, according to Sam McNerny on the blog Big Think, “[i]f a biochemistry problem only attracted biochemists it tended to remain unsolved. But if the same problem was tackled by, say, a molecular biologist or an organic chemist the chances were greater that the problem would be solved. Outside thinking was vital.”
Why does familiarity trip you up?
The non-expert speaks.
Familiarity feels a lot like expertise.
People who are the experts in their area on the team don’t always like being disagreed with by someone who isn’t an expert. It’s hard, when you know that you know what you are doing, to be told by someone who seems wholly unconnected and unfamiliar that they don’t agree with your decisions.
You get indignant, defensive. You have all kinds of reasons why you are right. How dare this outsider who has no understanding of context casually saunter by and say “that doesn’t work.”
Familiarity, on its own, is an expertise that is blinded.
You don’t want to kill your pets.
People who are unfamiliar with a project don’t have favorites in the project, while you, the creator, do.
Killing your pet is tough. We especially don’t like someone to come along and look at hours of work and say “that doesn’t make any sense.” Problem is, our favorite parts of a project are often the one we are most familiar with and we have no objectivity about this “pet” in regards to whether it works or not.
A fixation on that favorite thing can easily destroy a project.
We feed just the one thing.
Jack of all trades, master of nothing, or so the saying goes.
We’re a big fan of reading books here at CoSchedule, and often suggest books and resources that have helped us. The thing is, it’s easy to get in the habit of only reading a certain subject. If you’re big into startups or entrepreneurship, it would be easy to continually read books or blogs solely about those topics.
Are you so familiar with one topic, one area of expertise, that you’re missing out on the possible connections you could be making between it and other topics?
Expertise Is Still Valuable
So should we shun being an expert and hope ignorance and luck will bring about creative breakthroughs?
Geoffrey Colvin, in his book Talent is Overrated: What Really Separates World-Class Performers from Everybody Else, discussed a study by Dean Keith Simonton, professor from the University of California at Davis. In his study, Simonton looked at more than 300 “creative high achievers” who were born between 1450 – 1850. We’re talking da Vinci, Beethoven–heavy hitters, in other words. He then measured their noteworthiness by how much space was devoted to them in a variety of reference works.
What did Simonton find out?
Plotted on a graph, the most noteworthy creators had knowledge, education, and training, but not excessive. There was a peak in the middle. It might have looked a bit like this:
Does this mean you’d be more creative if you knew less?
According to Colvin, the most noteworthy creative people are those how have “immersed themselves utterly in their chosen field, have devoted their lives to it, amassed tremendous knowledge of it, and continually pushed themselves to the front of it.”
Expertise is still a valuable component; you need experts. You need an understanding. You need the skills and the knowledge. You need that 10,000 hours of work. To be creative (and productively creative), you need a high level of skill, practice and knowledge. These are the foundations you need to even begin to approach the problems that need solving.
Someone has to be an expert. And someone has to be able to approach a project as an outsider. If you can honestly assume the role of outsider on your own project, great. If not, you’ll have to find someone to do that for you. Keep in mind that the outsider may be an expert, too, but unfamiliar with your particular project.
Think back to my example at the beginning: I could be considered an “expert” on CoSchedule, but the specific project was new to me.
Introduce Unfamiliarity To Your Project
How do you introduce the power of unfamiliarity to your project?
1. Stockpile Newbies
Not everyone in your team has to be involved deeply in everything. There is value in keeping a “newbie” on hand to test a product or read a blog post for the first time.
If you are having a heavy planning meeting, don’t bring in everyone. Bring in only the ones that need to be there. Save some of your team to be the fresh eyes that you bring in once in a while to give that unbiased outsider opinion.
2. Be Less Stubborn
Consider the opinion of someone who doesn’t have the expertise you have.
Really consider it.
Are you unwilling to listen because you can’t get past your belief in your own knowledge? Are you letting arbitrary preferences or principles stand in the way?
3. Ask Non-Leading Questions
Ask relevant questions of people who are not deeply involved in a project. They must be non-leading questions.
“Wouldn’t you rather have feature A instead of feature B?” is a leading question. It indicates what you want the outsider to say. Most people will tell you what you want to hear.
“Do you prefer feature A instead of feature B?” is better. Or even “Which would you use more: feature A or feature B? Why?”
When the developers watch me work with a new feature or UI, it is important that they not speak up when they see me struggling.
“Just click that box on the right,” they might say as I fumble around. Immediately, my unfamiliarity is ruined as I understand how they want me to think instead of letting them understand how a new user actually thinks. Other users won’t have a developer standing behind them to help them out when they have the same problem.
So ask and observe, but don’t lead and direct. Consider the outsider.
Still wondering what happened once I started using the multi-scheduler?
Right away I found a few problems with how it worked. Some parts of the UI confused me. I made notes. It wasn’t long before customers were sending in emails asking some of the same things I had noted myself.
“We should have had Julie try this out before we launched.”
We learned something about the value of the outsider, and now I’ll try things out in beta before they go live. Before comprehensive new features are launched, I lend an unprejudiced mind while the developers look on. They watch where I click, where I get hung up, and if I have problems.
A fresh set of eyes is a good thing.
How do you guard against over-familiarity on your team? Do you have someone who isn’t in on the development of a project who can bring a fresh set of eyes?
July 28, 2014