Time to stop drinking your bathwater!

woman with half her face submerged in a bath with rose petals

Wait … what?

Who drinks their bathwater?

What has this got to do with websites and planning?

This topic is as much about marketing as it is about website planning, but before you switch off, all website planning is about marketing. You realise that, right?

Over many years I have used this expression, creating much shock, to highlight how easily we become accustomed to our own BS* inside our organisations.

The best way to look at your organisation’s marketing is to get an outside perspective. No matter how good you are, it is almost impossible not to become part of the inside culture.

It’s not impossible, because the very top 1% of marketing gurus are capable of doing this. Most of them, though are guns for hire, so technically they aren’t inside any more and are looking outside-in.

When you first join a business, you have fresh eyes, and you can easily see opportunities for change. You see it as an outsider sees it, because you are.

“If I were them I’d drop this, or change that tone of voice etc.”

Give it six months, maybe twelve, and you’ll be dropping acronyms, industry shorthands, internal business terms and attitude like everyone else.

Before long, it seems normal, your internal-speak detector has changed its filters, and you find it harder to see what outsiders do. You also have to report to your boss and their boss. They have been inside this bubble forever, and they’ve been drinking the bathwater for so long they don’t even notice.

Wait. What? You did it again. 

So think about the analogy. You get into this clean hot bath. It is likely bubbling with lovely fragrances, and you ease your achy body into it. The relief is almost immediate – the freshness of it.

After a while the bubbles have disappeared, the water is a bit murkier, but it’s ok it’s only me that’s in here. You top it up a bit with some fresh hot water (read some blogs, learn something new) and are feeling pretty good.

Before you started your bath if someone told you to get into a vessel filled with tepid dirty water to get yourself clean, you would have laughed them off as crazy.

And yet, here you are, chin-deep in dirty tepid water.

Wait I hear you say (in self-justification mode), “It’s my dirt, so it’s ok.

black and white puppy all dirty after playing in the mud

The facts remain, the water is dirty, and you are immersed in it, almost like human soup.

Extrapolate this out, you have been in here for an hour, or so, you forgot to bring refreshments, you’re a bit thirsty. How long until you take a sip?

Before you feel too ill, let’s head back to your marketing. How long until you are drinking your company’s bathwater. Are you just sitting in it or making your coffee with it?

To be your most effective at marketing you need always to be looking outside-in. This is the essence of user-centered everything:

  • design,
  • content,
  • UX,
  • everything.

How do you do this?

  1. Ask your customers
  2. Ask people who aren’t you’re customers
  3. aka. Research
  4. Look at the data. What’s working and what isn’t.
  5. Then go crazy digging into why (4) is and isn’t working. Don’t just mimic it without a depth of understanding.


How does this relate to website planning?

When you dig deeper into our method, almost all of it is focused on the user and helping them get what they need.

We set your business goals first, so you don’t lose sight of what it is you are trying to achieve, but the rest of it then is all about building something for the users.

Make it easy for the right users and your goals will be much easier to achieve.

You can’t be drinking your bathwater when planning your sites or improving them. Doing it because that’s how you like it, or because you ‘think’ it’s best without knowing who it is you are serving, and their needs is exactly like that.

Stop drinking your bathwater. It’s wrong. And your users will thank you for it. 

*BS = Bullshit, you knew that. 

Handling change in a scope

sign of the words "change" in orange

What do you do after agreeing on a scope but then realise changes are needed?

It would be easy to think that, having invested time into preparing a proper scope for your new website, that everything will run to plan and nothing will change. 

That is unlikely to happen except possibly on small sites. 

It’s more likely that there will be changes and that they can come from both sides of the process, Developers and Client. 

Why do Client changes happen? 

There are several reasons this can happen, and despite all the best intentions, some are unavoidable;

  1. Overlooking needs
  2. Rushed or incomplete process
  3. Other influence
  4. Committee based decisions
  5. Changing business

(1) Overlooking needs and (2) Process. 

If the client prepared the scope, then it’s possible their lack of expertise in this area could create some missing needs.  

The fact they prepared a scope is fantastic, and for agencies or freelancers, this is a big deal. Having a detailed brief makes your life much more comfortable. Be careful when you first receive the brief to make sure it still gets a thorough review. 

You’re the person with the industry expertise, which doesn’t mean you know everything, but it does mean you should clarify it with them.


Ensure you go through their scope with them in-depth. 

The process of reviewing it with your client can often bring up forgotten items that can be added to complete the scope.

(3) Other influence.

Whenever your client mentions to people they know that they are undertaking a new site development, they will receive ‘advice’ from many different people. Not all of that advice is qualified.

The information they receive can be from online sales systems, courses, ‘helpful’ friends and colleagues or possible competitors.


When such an issue is raised, try to understand the source of the problem. First, discuss the pros and cons to see if they do want that change or if they need a better understanding of it within the context of their new site.

(4) Committee based decisions. 

Committee run projects can be a complicated issue to overcome. You’ve dealt with one person throughout the project so far, and they’ve been approving things and keeping the process moving. Then you receive a significant request that is outside the previously agreed scope. 

Ideally, you’d know about a committee-based process at the beginning. 

If you can’t work around the request, then you need to invoke any out of scope process you have in your contract. Handling this calmly and professionally is essential, and you should allow your client the time to discuss this with the committee that will have to accept that. 

Often the additional cost implications remove the ‘need’ of the request as other committee members challenge the person requesting it. 

You need clarity around what is part of the scope in the contract to handle this easily.


Ask at the beginning of the process who will be signing off on the final project. Have clear terms and conditions for your projects. They should define what the scope is and the cost of out of scope work. 

(5) Changing business

Sometimes the business needs change. The time from initial scope to commencing the project might have been long for the client, and their needs have changed since then. 

Like (4) you need to have a clear definition of what is in the scope and how you handle out of scope work. 


Always discuss out of scope work as soon as it comes up. Don’t surprise the client with a bill they didn’t expect. Discuss the request with them, determine if they need an additional quote or contract for it or if it will just be added on, confirm it in writing and keep going.

cartoon artwork of a businessman negotiating with someone over the phone while waving money around in his other hand

Why do Developers changes happen?

If you are the client and suddenly get a call or email from your development team with a change issue, it can be concerning.

There are several reasons why this can happen and understanding them will help you in managing the way your project continues.

  1. Missed specifications
  2. Changing technology
  3. Team changes
  4. Capability

(1) Missed Specifications

While the teams working on projects aim to be as thorough as they can mistakes can happen, or misunderstandings.

It is as crucial that the client meets with the development team as is the opposite. You need to make sure what you have documented is understood the same way you wrote it.

The providers you choose might have rushed over a section of the specification and missed it as well. 

Contracts are there to protect both parties. The consequence of out of scope should be clear to the client and equally the what the quote should deliver needs. If they agreed it was covered, then they need to meet that, and the onus for the mistake is theirs.

If it is ambiguous and the true meaning of the requirement only came out later during the build, then accommodation should be made by both.


Spend time upfront on clarifying what is in the brief documents. Amend them, add extra diagrams or examples but make sure both parties can agree on what is included and how it will be delivered in plain English.

(2) Changing technology.

Web sites use a series of technologies that are continually changing — both the underlying languages as well as the content management systems. Web standards and security also influence how sites are created and managed.

In a build cycle, it is conceivable that quoted methods might become obsolete or new opportunities might appear.

The development team should be able to explain to you what is changing and the impact on you. There might be a change in how something will work, perhaps for the better, or a change in costs.

It is normal, and it shouldn’t concern you as long as the explanation is reasonable and the cost not prohibitive. 


Always ask for as many alternative options to a problem as you can. It allows your developers to think broader, and also you don’t feel railroaded into one pathway.

(3) Team Changes

If your developers’ team changes, it shouldn’t affect how your project gets built unless they lose technical skills. You should have a contract, and they should be obliged to complete it to the agreed standard. 

This falls into the category of their problem, not yours.

(4) Capability

Capability refers to the ability to deliver the functionality in the method that had been agreed on. I can be technology related, and in most cases would fall into that bucket.

It could, however, be anything, e.g. legislation might preclude you from being allowed to implement a method.

Both parties should discuss this, and where they will need to make changes, the developer should be able to outline the saving from the work that will no longer be able to get done and the new costs that will be required to complete an alternative. 

This should simply become a commercial negotiation about how to handle it. 


Always carry a contingency amount into a development project for unexpected events so that you have a budget to cover it.

I’ve covered several reasons why changes can occur despite creating a detailed and complete (or so it seemed at the time) website plan. 

The key is that the scope that was written was ultimately a snapshot in time. Events will occur once that project commences, and while both developers and clients can cause problems (be at fault) in many cases, it can be a lack of understanding that creates conflict. 

If you take time to understand the process will require small amounts of flexibility, and also you put in place sensible agreements, then your project and your website plan should be able to be completed without significant issues. 

For the question “So why bother creating a plan if it’s only going to change?” my answer is, imagine how many problems you would have without a plan. 

Managing small events along the way is normal, and you should expect some variance. 

Understand that, and you’ll remove a lot of the stress in completing your next project.

Why are website goals so important?

Have you every wondered why some websites are cluttered full of content and buttons?

You probably find those same sites difficult to use and requiring extra effort to figure out “their system” so you can complete the task you want to do.​​

And then there are the sites that are easy to use and look at, they seem to guide you effortlessly through a pleasing experience.

What’s the difference?

You can easily say, “They have a bigger budget” or that “They must have a kick-arse team.”

While that may be the case, there’s usually something else underneath that drives the two scenarios.

In scenario 1, whoever is driving those types of sites, is driven by FOMO (Fear of missing out) and thinks that not providing every opportunity on every page is going to leak inquiries or sales.

​​​​​​​​​​This fear comes from a lack of courage and not realising every single page on your site is a landing page, and a page that has it’s own goal.​​ They don’t realise they lose as many people as they gain. No one raves to others about their experience.

In Scenario 2 the people behind these sites, have clear intentions. They set goals they want to achieve and then step back and look at what that means. It shapes everything that they do moving forward on their site. They might do this subconsciously but it’s there in the end result, clearly showing they cared enough to create goal driven experiences.

How does it impact your plan or the end site development?

Think of a traditional WordPress, or similar CMS site, that offers up a themed approach to pages and posts. When you create a new page or post it will conveniently for you throw in the default sidebar options you’ve added to the site.

With it comes all the extras, images, ads and other inclusions.

Within the pages themselves you will see many different calls to action added in. Buttons, links and other distractions to the user.

These pages lack any sense of direction. They are typically the lazy persons way to create content in the least amount of time and comply with corporate guidance.

A page, post or entire site that thinks differently about the purpose it has both individually as well as collectively has a much better chance of providing something useful.

Seth Godin repeats often, ‘who do you seek to serve?‘ and within that simple sentence he challenges everyone to dig deeper, to do the harder things that others won’t do. That’s how you make a ruckus, or a unique point of difference. That’s how you don’t just copy another site.

It starts with a goal.

What’s the goal of the site. Refer to the book to get into detail on setting goals, but understand you need primary goals and lesser important goals.

Then extend that into the individual page.

What is the goal of the page. Not what are ‘the goals’ of the page, but what is the singular goal. Choose one, then once you can lock that in as your key driving point for the page, then you can list any lesser goals.

When it comes time to wireframe and scope out the functionality and then ultimately the look of the page, you can always reflect back to the primary goal. Are you doing everything in your power to make the primary goal easy for the person you seek to serve. The key word is service. Use the goals to create sites that aren’t just like everyone else. Make them the best they can possibly be.

Goals are the umpire that decide what’s in and what’s out between competing departments or bosses. They allow you to stay focused on what you are really looking to achieve, and ensure you don’t just take the easy route.

How do you use goals in your website planning and development? I’d love to know.