Having worked with tens of teams, both technical and non-technical, this is what I’ve learned about helping things run smoothly between marketers and developers.
First though, let’s define a marketer as any team member who has a goal to increase the quantity of users/clients or the quality of the user experience. That means designers, content marketers, sales people or UX specialists.
Developers? Developers write code.
So with that important distinction made, here are five things developers wish every marketer knew:
It sounds harsh, I know, but it is one of the main issues that raises a wall between marketers and developers. You don’t need to know the difference between TCP and UDP (though this would impress a developer!) but you do need to know how a browser is able to display a website by just typing its address, what a cookie is and what HTML is good for.
It’s like a person trying to sell a car without first knowing how an engine works, what the difference is between diesel, gas and electric or what electronic systems are included in the car.
You don’t need to know how to set DNS rules or write advanced code but when you ask for a change it’s important you understand what that change implies, if it is possible and what the consequences of it are.
For the love of hacking, check out five coding hacks every online marketer needs to play with.
Many developers will consider colleagues who don’t know how the Internet works as being disrespectful and they’ll simply ignore them.
Going Pro
Learn a few techie jokes and use them from time to time. They’ll make you look like a part of the team. This is my favourite for when I want to break the ice:
“At a meeting on the UX of a new revenue reporting interface, the dev guy who was about to start implementing it had just one question: Does the K in 5K refer to 1000 or 1024?”
Marketers have lots of ideas and projects that they want to implement and they often believe that each one of them is the key to accelerated growth.
Dev people love saying that “everything is possible”. Nothing is too difficult or not possible, it just might take forever to do it.
This is a shortcut to big frustrations!
The first lesson I learned about scenarios like this is, instead of asking, “Is it possible?” ask “What will it take?” After all, to judge a project’s potential you need to be able to balance resources with benefits.
I also like make sure the dev team understand why it is important to do it.
Most dev people I know are more rational than emotional. You can win them easily with solid arguments and giving them a sense that the thing they are about to do is important usually gets them on board as partners.
A solid argument is not that you think or believe something, it’s an argument backed by data so yes, show them reports, show them statistical significant results and show them aggregated user feedback.
Never start a discussion with an idea you had the night before, unless you already made your homework and can back it up.
One of the sales managers in a company I used to work for was famous for his grimaces when the development team refused to do the “minor” changes he was asking for.
Oh yeah, never tell a developer you can write code for him, unless you are a developer, otherwise you just declared war!
“But it’s just a checkbox, why can’t we just add it there? It’s five minutes, I can even write it for you.”
Amused by the whole situation, after the meeting was over I approached a developer and asked what would it take to implement the checkbox. I did not expect the answer I got:
There were lots of testing scenarios that the checkbox would introduce which, in return, would delay each release cycle and increase the stress on the team. Oh yeah, and the whole team believed the checkbox was stupid anyway.
Pro tip
Don’t go with solutions to the dev team. First go with the problem that you are trying to fix. Let them give their feedback so they can tell you what the restrictions are (if any) and only then focus on UX and specs writing.
I learned this lesson the hard way. Not being thorough with documenting your needs means the developer will fill in the puzzle with his own elements, which you might not agree with or like.
Each user interface is in one of the following 4 stages:
- there is an error
- no activity on the page
- there is activity on the page
- action completed with success
When we build something new we usually only write specs for the “activity stage” or the “success stage” and forget about the others.
When the development team does the implementation they are usually forced to write the other stages as well.
If you are lucky, they’ll come to you for help.
If not, well, let’s just say that 10 different people will do it in 10 totally different ways!
As marketers gain more and more experience such issues happen less often. However, it’s always smart to ask: do you think there is anything missing? Is there any scenario that I forgot to consider?
Be very careful with this otherwise you might win yourself nicknames you’d rather not have! I remember very well “Miss Query” from financial who would often go to dev to ask for a query.
Ok yes, this is a rather emotive issue and one where dev teams could make a bit of more effort in order to get along nicely with other departments, but you can still do your bit and not use the wrong words!
How do marketers and developers get along in your company? Anything I’ve missed from this list? Tell us in the comments.
Looking for deep insights into how your customers use your product?
InnerTrends can help. You won’t have to be a data scientist to discover the best growth opportunities for your business, our software will take care of that for you.
Schedule a Demo with us and witness with your own eyes just how powerful InnerTrends can be.
