Avoiding conflicts between marketing and development

Avoiding conflicts between developers and marketers
Bas van Essen, Wednesday, January 23, 2019

We should erase the battle lines that are historically drawn between development and marketing. Otherwise companies are simply not able to meet the needs of today’s fast-moving customers. A story about conflict management between developers and marketers.

It’s a dispute straight out of a Dilbert comic: the distressed engineer versus the unsettled marketing team. Throughout the decades, conflicts between software development and marketing (or sales) have led to numerous tragedies of failed co-operations, increasing mistrust, and postponed platform launches.

Looking to it very straight-forward, development and marketing’s biggest source of conflict seems to be rooted in a clear difference in prioritization. Building the product versus selling the product successfully. But under the surface, there’s a clearly more fundamental problem that have to be dealt with: the process of prioritizing problems is oftentimes not carried out in a collaborative way. Rather it is affected by a combination of negative factors, such as internal pressures, a lack of willingness or osmosis. This is shown by more classic examples of conflicts between development and marketing.

1. “You’re Not a Team Player”

Development and marketing can’t settle on a set of requirements and a timetable. Specifically, marketing urges that all the requirements must exist of a particular date or the product might as well not be built.

Mark: “Look, the window of opportunity starts in nine months. We know that the competition is planning to release similar products ten to twelve months from now. Since their products and our 3.0 release are so similar, the only way we are going to be successful is if we are the first to market.’

Development realizes that the mentioned date is completely unreasonable, looking to the collection of requirements, and refuses to work with it.

Dev: “I understand what you are saying. But I also know what is realistic. Just wishing for something is not going to make it happen. Read my lips: My team cannot produce all the features you want in Release 3.0 in nine months. It simply cannot be done.’

Notice that each team tries to meet the best interests of the organization. Being disappointed, marketing talks with the board and clarifies the importance to have all the requirements met at their proposed date, and then tells about development’s ‘obstructive attitude.’ Development is then seen as “not a team player,” and the board demands that it is. The manager of development agrees to the date even though he knows it’s impossible to meet. The project is not delivered on schedule. Notice that the development organization is able to be late and still say, ‘I told you so’.

Dev: “Look, Mark, remember a year ago when we were planning the 3.0 release? You demanded that I deliver it in just 9 months. I told you then that we had two choices: Build it in 9 months without an architecture that could support any additional features, or build it ‘right’ and deliver it in 12 months, in which case the architecture would be able to handle additional requirements. You chose the first option. So, it is your fault that we are in this mess now! The current architecture simply cannot support the new features. I need a full year in order to revamp the architecture and then add the new features.”

2. “You Don’t Understand Technology”

Development and marketing can again not settle on a collection of requirements and a calendar. Again, marketing insists on that all the requirements must be included by a particular date “or the product might as well not be built.” Development knows that the date is completely unrealistic, looking to the set of requirements, and fights back.

Being annoyed, in this case development approaches the executive management, explains how crucial it is for the organization to be successful, and then informs the board of marketing’s “death wish.” Marketing is seen as trying to let the company fail by insisting to accomplish the impossible. The marketing manager agrees to reduce the requirements or postpone the product release, even though she realizes that the product will no longer be competitive. When marketing fails to meet revenue goals, it has the perfect scapegoat: development.

3. “Over-Demanding”

Marketing realizes from past experiences that development is going to deliver late, no matter what is required. Therefore it deliberately communicates an earlier deadline to development for product delivery, hoping that when it’s delivered, although late relative to the deadline, it will still be on time to meet the market window.

This scenario may result in a successful product delivery. Unfortunately, the deception used in this case makes it impossible to repeat the process in a predictable way. No one involved learns anything about why it worked or how to improve it. The worst part of this scenario is that development gets an undeserved ‘bad rap’.

Now that consumer’s expectations have lately increased faster than ever before, not tackling these situations will guarantee that your organization is taking huge risks. The risk of satisfying the wrong requirements, the risk of promising to meet a schedule only to miss it significantly, the risk of agreeing to satisfy requirements for a given budget only to exceed it significantly, and so on.

Example of a solution:

What if you ask Dev to imagine that he owned a majority of the company’s stock, and that the project’s success or failure in the marketplace was key to his personal financial success? Clearly, promising to deliver something in nine months when it would actually take twelve is not productive. Nor is delivering it in a year to a stale market. So what would he do with the project? This question could be asked from the position of somebody that is the link between development and marketing, such as a product owner.

Dev: “Interesting situation—here’s what I would do. I’d increase my headcount so I could afford to staff two parallel development teams. One team would then work on incorporating as many of the 3.0 features as possible into the old architecture. We could release it seven-to-eight months from now. We could call it Release 2.5. The other team would start revamping the architecture and be ready to deliver the full 3.0 capability in a year.”

Mark: “Wow! Would you really do that for me?”

They finally have a tentative agreement in principle. Then they work a few more hours to see if it is realistic. After that, ok, Mark becomes more hesitant about Dev’s proposal; because the requirements that he brought forward, do not make a quite impressive product. But then he has a great idea: the proposed Release 2.5 is not as good as the products the competitors were to release in the ten-to-twelve-month time frame, but better than anything else currently on the market. His plan is to offer release 2.5 to customers at a very low price—not even enough to recover the company’s development costs. This early introduction at such a low price could seriously decrease the market demand for the competing products that come out a few months later. And then when 3.0 comes out, the competitors’ products would not have already captured the market.

More in common than you may expect

Another challenge in accomplishing better prioritization, is the idea amongst engineers that marketers are totally ignorant about development and its technologies. Particularly for engineers that identify themselves strongly with their own profession, this idea leads to thoughts of marketing being a team for bumper stickers and tradeshow banners.

From the marketer perspective, there is this misconception that developers neglect the importance of appealing stories and an appealing appearance. Both misconceptions can lead to bias that prevents teams of working well together, and therefore a company developing software needs to fight these prejudices.

Emphasize the similarities. Firstly there are three reasons why marketing nowadays looks and behaves like engineering.

1. Marketing is a technical discipline

Today’s marketers make use of more and more advanced technologies to have conversations with their target audience. They must understand, for example, search engine algorithms, data analytics, marketing automation systems, spam filters, email marketing regulations, programming languages and platforms, and browser idiosyncrasies across multiple platforms. Even more knowhow is needed if the marketing team develops sales tools or mobile applications.

Today’s marketers also manage campaigns in supervisory software and asset management tools that centralize data repositories (similar to operations’ and engineerings’ product data management systems).

2. Marketing spends more time on development

Marketing funds aren’t expanded in proportion to revenue or profit. According to Gartner’s 2016–2017 Spend Survey, 14 percent of companies have anticipated budget decreases (the highest percentage in survey history). Companies now are counting on greater productivity and optimization, so marketers must spend less time on research and more time on development—a context a lot of developers can identify with.

3. Also marketing requires agility and fast iterations

Applying lean, Kanban or agile software development principles, today’s marketers conduct more and more A/B tests, “minimal viable product”–style demos, beta releases of sales tools, staged campaigns to accelerate time to market and maximize learning. Phased rollouts and pilots have also become a common approach. The stage-gate milestones typical in development environments are growing in marketing (often paralleling the product development cycle to create a more holistic and cross- functional product lifecycle picture).

Engineers’ jobs have also changed

Not only does today’s marketing have more resemblances with engineering, also development has more in common with marketing nowadays.

1. Engineers execute user research

Hearing first-hand customer feedback of their experience with similar products, whether through meetings, site visits, or taped interviews, is very beneficial for developers. This is especially true when expanding businesses to new customers and reacting to changing marketplace demographics.

2. Engineers make products more appealing

Throughout the years, the UX and the appeal of a site have become critical product characteristics. Customers more and more expect sophisticated design aesthetics for the product they buy. Function isn’t good enough; products must also be beautiful.

3. Engineers are telling stories

Whether they create the next architecture platform or develop a new sensor technology, engineers will have to ensure that employers can get the full benefit of their insights. Together with content marketers, engineers can bring their inventions to life through stories that illustrate the unique assets and features.

Date of delivery

Of course developers and marketers still have their own lingo, that’s why companies internally have to ensure they talk about the same thing. Again, this could be the responsibility of a product owner, or somebody from the board.

For example, a development organization often thinks of ‘delivery’ as the date they are no longer responsible for the product. In other organizations, this could mean the product release to the independent testing team within the company. But in most companies, marketing thinks of delivery date as the date that the company can ship the product to the first buyer. Here is a list of some of the events that various people think of as “delivery”:

• release to test
• release to quality assurance
• release to manufacturing
• release to (tactical) marketing
• release to sales
• release to beta customer
• release to revenue customer

Depending on the sophistication of a product, these dates could be many months apart. It really isn’t important which delivery date the teams are talking and negotiating about, as long as they are all talking about the same date.

Marketing teams are very aware of market windows, and often work hard to target a product’s delivery to the right place in that window. However, as features are added to a product, the following could happen:

The delivery date is generally delayed, so the product enters the window at a later stage.

  • Marketing should avoid making absolute statements, such as, “We cannot sell the platform if that requirement is excluded. Instead, make statements such as, “By removing that requirement, our expected revenues will be reduced from $20M to $14M .’ This helps create an environment of teamwork since nobody on the team wants to hurt the company’s revenue.
  • Development should avoid making absolute statements such as, We cannot build the system by the delivery date if you add that requirement. Instead, make statements such as, “By adding that requirement, our likelihood of delivering on time reduces from 73 percent to 27 percent. This helps creating an environment of teamwork since nobody on the team wants to deliver the product late.

We are Jexia and not so long ago, we have decided to launch of our platform in the spring of 2019. Please keep following us!

Tags: , ,

Categorised in:

This post was written by Bas van Essen


  • John says:

    The problem with the proposed solution from the developer point of view is still incorrect. An engineer would never (rarely) ask to double head count to meet a date. Only managers and sales think you can hire 9 women to make a baby in a month.

    Give “The Mythical Man-Month: Essays on Software Engineering” a read.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.