Stay in your lane: Separating the “what”​ and “how”​ when building a website

No matter what digital marketing project you're working on, the Business needs to define what and Technology needs to say how. Defining these roles ahead of time allows everyone on the project to understand the responsibilities and duties that are required and expected of them. First in a five-part series on writing requirements, get some tips on how to set ground rules and have a successful project.

Humankind would not succeed if everyone was the same. Not only would it be boring, but if everyone was gifted with identical skills, talents, and abilities, we could not get anything done.

It would be like five people showing up to hang a large painting on the wall, but everyone bringing their own idea of where to hang it, how high it should be hung, and then everyone has a hammer but no one brought anchors and screws. In order for it to work, you’d need someone to:

  1. Bring the painting
  2. Know where it’s supposed to be hung
  3. Bring a hammer and drill
  4. Bring anchors and screws
  5. Clean up the mess made afterward

Not one job is more or less important, but each job is necessary to get the painting successfully hung. Each individual has to know their role in getting the painting hung. They need to know what they are responsible for doing and what they are responsible for bringing. If one person doesn’t understand how their role fits into the larger objective, the entire team fails.

A project in digital marketing (such as creating a new website, supporting an organization-wide digital transformation strategy, making website updates, developing an app, launching a campaign, managing social media, etc.) is the same as hanging a painting. It requires multiple types of people or groups, each with their own skills, talents, abilities, and responsibilities.

I’ve broken the two required groups into two general categories for the scope of this article. They are:

  1. Business: The “business” role can be filled by people in various parts of the company. It can be an entire marketing or communications department, an individual in marketing or communications, a company leader, or a company owner. Often there are multiple layers with sub-roles within the bigger “business” role.
  2. Technical: The “technical” role can be filled by an entire IT department, a third-party agency or consultancy, or a freelance developer. Most commonly, it’s a mix of these, as we can have both internal partners and vendor partners to bring the technical experience necessary to get things built.

Just like hanging a painting on the wall, if you don’t know who is responsible for what, your project is doomed for failure. 

Maybe you’ve experienced something like this:

  • You hire an agency to build a new corporate website and find out that images, content, and hosting is in addition to the price they billed you. (Which, aren’t words, pictures, and a live website necessary for it to go live?)
  • Your new website launched, but looks nothing like you envisioned it … And your leadership is NOT happy.
  • You spend a large portion of your budget last year on an app, but it gets a handful of bad reviews and hardly anyone is using it.
  • You ask for an analytics report on the campaign launched last month and your IT department isn’t able to produce it.
  • You spend a lot of your money on a new website, run it through a tool like Google Page Speed, and it gets a failing score.

I could go on and on, as these types of outcomes are unfortunately the norm, not the exception. The problem often lies not with the skills of the technology side, but with the business’ ability to explain what they want. The two different sides think they are building to the right thing, but they find out (too late) that the end product is not what the customer really needed.

This cartoon has been floating around since the early days of software development and is still as relevant then as it is now. 

So, how do you prevent these outcomes?

1. Admit you’re different, and that is a good thing

Each side comes to the project with their own experiences. Maybe the Business is aware of some financial issues within the organization or is getting pressure from Leadership that Technology isn’t aware of. Maybe Technology’s budget was cut recently, or they see how the current platform is so customized, that any new builds take three-times as long to get done.

Business isn’t aware of what is going on in Technology and Technology isn’t aware of what is going on with the Business. By default, we will know about “our world” than our partners.

We can’t all know *all the things* and that is a good thing. We all have our areas of expertise, areas that we are responsible for, meetings we go to that others aren’t a part of, have different goals that only apply to our area, and none of this is bad.

Admitting that we are different goes a long way in approaching a project with a healthy perspective.

2. Know you’re on the same team

No reasonable person wants to go into a digital marketing project wanting it to fail. The Business isn’t purposely describing ambiguous requirements and Technology isn’t purposely designing a solution that will fail.

I often see this back-and-forth take over the focus of the project. We are so worried about what the other side is doing or not doing that we get distracted from our purpose.

In the heated moments of frustration, annoyance, or any other emotions, it’s important to step back and look at each other and say, “Remember, we’re on the same team.”

3. Make sure everyone knows the ground rules

The purpose of ground rules allows everyone to know what you’re doing, why you’re doing it, and what everyone’s job is. It seems simple, but almost every time I engage with a client, the goals haven’t been written down and no one really knows how what they are doing impacts the larger picture.

Some example product team rules for the Business:

  • It’s my job to define the business goal of the project, which is how the project will bring more revenue to the business
  • It’s my job to define the scope of the project, which is what the project includes and does not include
  • It’s my job to define who the project is meant to impact (the target audience) and how it is meant to impact them (the buyer’s journey or patient journey)
  • It’s my job to ensure that branding and copy is in line with the overall story of the company
  • It’s not my job to say what design looks good or what technology to use*
  • It’s not my job to say how we need to build the project*

*You need to respect the team’s area of expertise. If you’re working with UX and UI professionals, no matter how tempting it is, they get to have the final call on design. For technology, your budget and vision might have a large impact on the website platform choice, but always rely on those who are in their respective roles to make the final call. You can hold the purse to the project but still trust the experts whom you’re paying.

Some example product team rules for Technology:

  • It’s my job to define how the project will be built
  • It’s my job to work with the Business to ensure project requirements are complete-enough for accurate, high-level estimates
  • It’s my job to openly communicate to the Business decisions we make on balancing time, budget, and resources
  • It’s my job to understand and care about why we are working on this project

4. Stay in your lane

No matter what digital marketing project you’re working on, the Business needs to define what and Technology needs to say how. Defining these roles ahead of time allows everyone on the project to understand the responsibilities and duties that are required and expected of them.

Once the project roles are defined, stay true to them. By “staying in your swim lane,” you give your partners on the project team the respect they need to get their job done, benefitting everyone.


Make sure you check out all five parts of our series, Writing website requirements:

  1. Part 1: Stay in your lane: separating the what and how when building a website (Current Article)
  2. Part 2: How to write a project brief for a website
  3. Part 3: Write high-level business requirements (Coming Soon)
  4. Part 4: Estimate the time and cost (Coming Soon)
  5. Part 5: Rank priorities (Coming Soon)

Leave a Reply

Close Menu