How to harmoniously develop and market products

Every company I consult with has a version of the same problem. The marketers want a flashy new feature, but either they don’t know how to communicate it to the developers, or they don’t understand the terrible effects it could have on the site functionality or usability. Or, conversely, the development team wants to implement new functionality without understanding how it can impact the brand, the organic search traffic, or other marketing efforts.

Often, it speaks to a disconnect in priorities, in knowledge and, obviously, in communication. Developers favor solving a problem and getting changes implemented with minimum debate and without disruption or change. Marketers often are abuzz with ideas for “flash” (not Flash), for the hot new technology or functionality, and for having changes implemented for the user “now”. Infinite scroll is an example of just such a technology. When it first came on the scene, both marketers and developers began using it to display large quantities of content without having to load all the data at once or having users click through to a series of many pages. Unfortunately, many who didn’t consult with the other team saw a decline in traffic; one team or the other might have known that Google spiders can’t “scroll down”, and because of it a lot of their content was rendered invisible.

Both teams are obviously crucial to the long-term health and growth of a company, but often each group does not fully understand the importance of the other. Although technology companies can often launch without a marketing team, they usually won’t go far after the launch without one. Although many marketers believe that the brand is more important than product, creating that “minimum viable product” in the online space can’t be done without a development team, and having a site that does actually work and satisfies the consumer is always going to be essential.

In many cases, solving these problems requires training and significant effort that many companies don’t believe they have the time or money for. In my role as an SEO, it has frequently fallen to me to be the “translator” between departments. By nature, a search engine optimizer has to be conversant in both the technical/code side and the marketing/customer side. However, I believe that if you aren’t making an effort to help your teams understand one another and to communicate effectively, you are squandering resources – wasted time, lost traffic, delays, and significant rework that could have been caught in the early in the process with effective communications between these teams.

Lay down the most important tasks

Google recommends sitting down with your core team and listing the main tasks of the site. What must the website user be able to do most effectively? Out of all of these tasks, which are the most common ones? The ability to perform these actions should be optimized accordingly. A common complaint that marketers voice about their developers is that they don’t understand the needs of the end-user. A way to remedy this is to list those needs, as simply as possible, and walk them through the list.

Have both teams involved in a new project right from the beginning. When wearing my SEO hat I recommend that clients have me consult on a new site or functionality right from the planning and wire framing stage. This can nip major potential problems in the bud, preventing the need to go back and make time consuming fixes after something is already built/coded.

Action Plan: Write down the main tasks users perform on the site. This could range from a few to dozens of desired actions, but should be limited to the most popular or important actions a site user can take.

Don’t waste time over-communicating

There is a subtle difference between communicating well and over-communicating. An onslaught of unnecessary communication can waste precious time and resources better applied elsewhere.

A study published in 2003 by IEEE Transactions on Engineering Management found that email communication frequency had a curvilinear relationship with goal achievement and project efficiency. Too much email communication between teams resulted in a significant dip in efficiency and milestone achievement overall.

So how do you find that perfect quantity of communications? Much of it comes down to mutual trust and respect. Respect the other team’s professional opinion, even if you don’t necessarily understand the reason behind it. Respect each other’s time. Make sure each meeting you schedule is actually necessary. Spend time preparing for any meetings to save time during the meeting; decide on a clear goal and agenda. If it helps, set up a schedule for updates. Don’t bog down email inboxes by asking for updates constantly. Instead, create a deadline and schedules for updates. When you lay down clear expectations, the feedback loop is faster and more efficient.

Action Plan: Don’t plan unnecessary meetings. Keep a clear schedule for updates, and stick to them.

How will something affect the other team?

Make the effort to understand the demands that a task will put on the other team. I’ve seen situations where the marketing team heaps an enormous amount of work on a development team and then get frustrated when the coding isn’t spectacular after their 3-day deadline passes. Your team of two coders can’t handle the same kinds of deadlines that Amazon’s army of coders can. Often, development teams can’t predict exactly how much time a task will take. As the project progresses, the team will invariably run into snags. And of course, bugs happen.

If you want a project to take less time, perhaps ask the developers what kind of changes to the project could be made that would require less testing and less development time. They probably have some valuable input on alternate solutions that you would have otherwise never considered. Alternatively, simply ask yourself if the feature you want is really necessary.

If you want the project to take less time, be decisive about the features you want. Likely, the latest feature request, if left out, isn’t going to make or break your site. There’s nothing that can throw a project off-schedule like constantly changing your design needs.

Action Plan: Make a choice about the feature you want implemented by the developer, and don’t stray from that decision unless an urgent problem arises.

Have marketers and developers meet and hash out the site features and changes

Companies often don’t understand how decisions made by one team directly affect the other’s ability to do their job. Before one team makes an important decision for the site, the other should be consulted and their opinion respectfully considered. Specifically, I’ve seen this happen with site navigation, “faceted navigation” for ecommerce, and site search. Although each can be helpful for the user, if they are not implemented correctly, each has the potential to create huge quantities of duplicate content or a confusing experience for the user.

Another significant concern can come when a development team makes a change to the site that seriously threatens user experience or search engine optimization (SEO). I have frequently encountered developers that have built site features with little to no oversight by the marketing department only to find that those features create massive duplicate content problems, or that they have built pages using code that cannot be crawled and understood by the search engines. Had they checked with marketing (in this case the SEO team), that issue could have been resolved. Another potential hazard is the development team deciding to create something via a solution or technology not previously discussed. Although to the developers’ minds, since the visible output is the same, the problem is solved, frequently how something is created for the web is just as important as the final output.

In one instance the SEO consultant was not able to see the code for, nor even a functioning preview of, a redesign of a site section that drove the vast majority of the site’s highly converting traffic. When the new site section was finally presented to the marketing team and the SEO consultant, it turned out that the pages for this new site section appeared entirely blank to the search engines. The lack of communication in this case was exacerbated by the fact that the development was being done by a contractor outside the company itself. While a sub-optimal workaround was implemented to mitigate the damage, it took many labor hours to fix the site and to get back to a place where the site functioned effectively for both users and search engines.

A study done in 2001 published by the Academy of Management Journal found that the ability to express doubts seriously moderated the disagreements that resulted from task disagreement. Freedom to express doubts also had a negative relation to the amount of contentious communication between groups. Creating the kind of environment where people from all groups feel comfortable in asking questions and voicing concerns in a constructive way will result in greater rapport within the team, and because of it, a more innovative atmosphere that prevents problems on both sides.

Action Plan: Plan a meeting to discuss any site updates, technical or otherwise, and how they might affect site functionality. Make it a meeting goal to understand how the users and search engines will be affected. This should be the case for anything from small changes to a page template, up to and including site rebuilds from the ground up.

Encourage people to learn interdisciplinary skills

A fun way to get your marketers and developers communicating more is to reward your marketers for learning some coding. Or conversely, give your developers a small bonus for taking a course in user experience or reading a few books on marketing or SEO. This type of learning is just as valuable, perhaps more valuable, than reading a book in their own discipline. Treat it accordingly with raises, bonuses, or a few hours off.

Especially if you find yourself managing a group of developers, deeply consider taking a few coding classes. Anything that helps bridge communication gaps can make you a better leader, and can increase the likelihood that the developers will respect the choices you make for the product. Rightly so, because you’ll know more about what they are going through.

Action Plan: Set up a reward system for your marketing and development teams to learn interdisciplinary skills with bonuses or time off.

Send marketers and developers to conferences together

Have some coders go to a marketing conference along with your marketing team. Do the same with a development conference. This keeps your whole team aware of what is going on in current events of marketing and coding that might directly affect the work they do. This also promotes bonding between the two groups.

Often, I find that developers have a general sense of good practice of SEO because solid site design is an essential tenet of SEO, but there is usually plenty of “low hanging fruit” (please pardon the ‘consultant speak’) they could implement to nudge you past your competitor. That knowledge could be easily obtained through an SEO conference or workshop (e.g. Search Marketing Expo or Traffic Control). More than anything, this helps the developers build a site that is technically correct from an SEO perspective as it is built, rather than what is all too often the case where a site is built, then checked by an SEO shortly before launch, only to find there are serious issues with the site. At that point the management has to make the choice to launch as planned with a suboptimal site, or to delay the planned launch.

Action Plan: Offer a reward for marketers or developers to go to a conference outside their discipline.

Take a lunch

Management guru Tom Peters suggests going out for lunch with people of different functions. He actually measures it as part of an evaluation for managers. How many lunches are they taking with people of different functions? Make it a metric discussed when considering them for promotion, a new project, or a raise. The way he reasons it is when you go out to lunch with a person you don’t normally interact with, suddenly they become a person. You’ll find out that you even have some things in common. They aren’t just “head of marketing”, they are “Cynthia”, and Cynthia is much more approachable and easier to relate to than “head of marketing” is. Another great resource for this strategy is the book Never Eat Alone, by Keith Ferrazzi.

Action Plan: Encourage your teams to go out to lunch together. Designate a day of the week “Interdisciplinary Lunch Day”.

Take a personality test

This suggestion may seem flippant, but I’m not talking about the type of quiz you see in your Facebook newsfeed where you find out which movie character you drive like or the type of dieter you are. Instead, I’m referring to an in-depth personality assessment where you learn how your employees think, feel, and function. Believe it or not, providing the team with these personality insights can really make a difference in creating empathy in the workplace. Meyers-Briggs is industry standard and still a great option, but Dr. John Demartini also has a Values Determination Test that I highly recommend. His is based more on what each person considers important. When you can align your values to the project you are working on, you’ll find that the team members are far more motivated to make a great product. When a whole team’s values are aligned, magic happens.

Action Plan: Take the Demartini Value Determination test. If you are a manager, schedule a meeting with each of your team members to discuss their values and how to align them with team goals.

“Lunch and learn” sessions

Sometimes a free lunch is enough to get a group of people together, so what better cheap incentive for you than to get people together to learn a little bit of something that is out of their element. Get a person from the dev team to teach a few coding skills once a week, or try out a 2 week course of a more difficult topic. However, these should not be required, and they should not be info-heavy. Lunch can be a needed time for employees to unwind, and if they are expected to cram new skills in that period, they might not be interested, or they may burn out later in the day.

Action Plan: Offer a free lunch to any marketing staff interested in taking a lunchtime coding class.

Marketers and developers think/process information differently; of course they’re going to butt heads. Helping them understand each other can make all the difference in the world to the effectiveness of the team, and perhaps even team morale. Cut out the communication barrier by getting them to work closer together, and see how closely your work depends on one another. Take the time to plan changes rather than rushing in without input from the other side. Have both sides involved in all stages of a project from planning to completion. It may slow the process somewhat, a hard sell at times in the first to market world, but in the end, a small delay will deliver a better product for your users, save time and money for the company, and you’ll have a happier, more collaborative workforce.