Website development battles: Marketing Vs Engineering

Kartik Rao

Kartik Rao

Head of Engineering

There will always be website development challenges with marketing and engineering teams due to the very nature of their roles. Marketing has a world-changing new product idea, but engineering says it can’t be produced for less than a small fortune. Or engineering receives a brief from marketing without the full requirements of the design and with limited time constraints. 

So how can both marketing and engineering come together to understand each other’s position? How do we address the handover of expectations from one team to the next?

The website idea vs practical execution

Marketing teams are generally an excitable bunch. They love to explore new ideas that have the potential for new leads. To adapt to changing market trends, marketing will often brief the development team for a feature they feel will make an impact.

Web comic – xkcd

Marketing: “Why is this so complicated?”

Let’s say you have an HR consulting business. The marketing team have noticed that customers are getting confused with the pricing scheme. They decide that to give customers a more accessible way of understanding their pick-and-mix style services and decide an online quote calculator would be the best option. 

They want a simple and intuitive design, where users can compare and customise the type of consulting services offered. Marketing has noticed that their competitor already has an online quote calculator installed, so they need to move quickly. 

A brief goes into development. How hard could it be? 

Web developer: “Why don’t they understand that this is more complicated than it looks?”

You can’t just judge a book by its cover. 

A simple user interface may often hide complexity underneath. In the case of the online quote calculator, the website development team has to assess the existing infrastructure, deployment processes, security and accessibility. 

They need to consider the following technologies based on what is currently on the website, including:

  • PAAS or On-Premise? (AWS/Azure or physical server)
  • C#/.NET or Java? 
  • React or Angular?
  • Custom UI/UX or an open-source framework?

From an engineering perspective, it is essential to acknowledge that the quality of the development, will mostly depend on what has been developed 1, 2, 3+ years ago. A new feature isn’t like building a new house, it’s usually like building a house on top of an existing house.

Project Manager: Remember me?

No matter what project or feature you are working on, the two teams must try to compromise. One person needs to understand the business goals and break these down into technical objectives. Bridging the gap between the two teams requires a shared understanding of the timeline, technical complexity of each item and effort needed to produce a minimal viable product. 

Marketing can improve their results by identifying longer-term plans and communicating these to developers. This will ultimately enhance the speed at which they’ll get new features in the future.

So in the case of the online quote calculator, a better way to phrase the online quote a calculator would be; “We’ve identified that on-page calculators are a good way to boost conversion, and typically these calculators behave as follows: search capability of services, timeframe outlined and indicative pricing. Please create a way to make and insert a calculator on the page, allowing for modification in the future.”

First to market Vs realistic timeframes

The delivery date. It can mean a lot of things to different teams. Is it the release to the quality assurance team? Or the tactical marketing team? Or is it a release to the customer or end-user?

Marketing: “If we can’t get this to market in a month, the product might as well not be built.”

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. 

The reason that time to market is so important is that being late erodes the market that you have to sell your product into. For example, if you initially target a market segment of ten million units, with a market lifetime of 18 months and then you are six months late; the addressable market will likely be in the range of three million units. There may also be changes within the market, that your product has to react to, such as legislation changes, new competitors or shifts in consumer behaviour. 

In marketing, timing is everything. You want to catch buyers in the moments that will impact their purchasing decisions. For most marketing teams, the date of delivery means when it is released to the customer. Hitting tight deadlines and requiring development teams to move quickly to meet business targets is a consistent occurrence.

Engineering: “How can we commit to a delivery date when we have no clear requirements? 

With website development, the adage “Garbage In, Garbage Out” often applies, an adequate level of detail lowers the risk of overly optimistic/pessimistic deadlines and consequently slippage in delivery dates. Experienced development teams and supporting roles such as Business Analysts and Project Managers should provide clear guidelines to marketing on an acceptable level of detail where requirements are concerned.

How many engineers does it take to change a lightbulb? Just because you have five more people doesn’t mean it will take less time. Some tasks may depend on the completion of other tasks, whereas others can run in parallel. It is also essential to take into account competing priorities and their impact on the availability of development resources.

Marketing should try not to pre-decide on a delivery date when technical complexity and dependencies are not apparent. Consequently, engineering should surface detail when asserting a complex requirement.

There is a common thought that development teams often think of ‘delivery’ as the date they are no longer responsible for the product. This could mean the product is released to the independent testing team within the business or back to marketing for the campaign launch. It is crucial to agree on a definition of done that is suitable for the product and its audience.

When development and marketing cannot agree on a realistic date to get a product released, problems will always ensue. It creates a blame game within the company as each team can use each other as scapegoats. 

Web development scope changes

Our top four tips  

  1. Use data as a starting point to find common ground. It is vital to use data around customer engagement as a trigger point for communication between both teams. Factual evidence will give more gravitas to marketing decisions and will lead to the right technology being put in place by engineering.   
  2. Work collaboratively to define and agree on scope, including the business priority, technical complexity, and dependencies of each item. Scope changes are allowed, but when we add something, then something else must be removed.
  3. Communication is key. Both teams should avoid using absolute statements when conversing with each other and allow time for making decisions. Look to project managers and business analysts to aid in bringing engineering and marketing together, as their role types assist in constructively translating perspectives. 
  4. Set expectations between both teams. As a general rule of thumb, marketing owns and defines the product, whilst engineering owns and is accountable for delivering the product.

If there’s one thing common to all productive exchanges, it’s humility. Good things can happen when both teams believe that their collective intelligence is higher than that of the individual.

How can we help?

Our team can help provide a timeline with scoping requirements for your next web development project. We can also help project manage between internal teams and align technical requirements to business objectives. Whether you are in marketing or engineering, if you have any concerns about an upcoming website development project, contact us today to see how we can help.

About The Author

Related Articles

Engagement models comparison

Not sure which engagement model to choose for your project? Here are some key points to help you decide.

Project sizeAnyAnyLarge
Project typeOne-offOngoingOngoing
Project requirementsDefinedFlexibleFlexible
Project management4mation4mationYou

About The Author

Think we could help you?

Contact us