(reposted from my Tumblrrrrr)
Most of the value created in digital today is from the perceived (and often overblown) difficulties in actually creating things.
Websites, ads, blogs, whatever. Acronyms like HTML, AJAX, PHP, FBML, etc are made to sound scary, especially by agencies who like to make a buck off of selling you services that prevent you from ever having to “get your hands dirty” with this “nasty code stuff”. This is a very large reason why digital agencies get business – because most business folks can’t “speak geek”.
This isn’t to say that there aren’t legitimate reasons for using agencies, especially when there really aren’t any people capable of doing things digital within your organizations, but even in those cases “speaking geek” you call “BS” when people claim they can’t do something you need them to do, because you can understand what goes into it.
Of the people give these things a try, 9 times out of 10 realize they aren’t as difficult as perceived, or whoever sold it to them says it is, and they all up more empowered over the success of their products and services. A lot of time they find it to be a fun exercise.
“Speaking geek” allows Product people/Marketers to become the glue that holds projects together.
In my 13 years of digital experience in just about every type of role imaginable, I’ve spent my time in the space between Marketing/Product and Tech. I’ve found dozens of really smart people who just couldn’t communicate what they wanted, and tried to help them reach their goals. In that time, I’ve found three things that remind the same no matter what the company is:
– Developers like to develop and build, but often have great ideas about better ways to solve problems that they can’t communicate (through political channels, or just not in a “non-geeky way”) to marketing/product people.
– The marketing/product people don’t always know what they want, and even if they do, this miscommunication makes it really difficult to explain in a geeky enough way to make it crystal clear to the developer what they REALLY want.
– This miscommunication ends up causing the deliverables to be different than expected, and requires a phase in the project where things are normalized. And this is where a lot of time is lost on projects and launch schedules.
I genuinely believe that people are too defined in particular roles to be extensible (You’re just a *project manager*, you have to do A, B and C. Or you’re an *analyst*, so you can only do X, Y and Z). At the the end of the day, GOOD IDEAS come from anywhere, and product people need to understand and embrace that.
Being able to understand the guts of the Internet really helps to solve this problem, because now you can (pardon the cliche) “walk a mile” in another person’s shoes. You can see in their mind the problems they are looking at, the issues they see during the project, and, most importantly, be able to communicate with the entire team on terms everyone can understand. Teams learn best from each other when small groups of different disciplines work closely together, and the more the non-tech person can get out of those informal conversations, the better everyone feels about their knowledge. When you’re on that level playing field. people are also more willing to give you the benefit of a doubt as a Product person, simply because they know you are trying to help.