Why Projects Fail, Hot Potatoes, Why SEO Documentation Fails
Why Projects Fail, Hot Potatoes, Why SEO Documentation Fails
Edition #18- Monday 3-2-1
Hello 👋,
Welcome to the Monday morning ideas newsletter ☕️.
Every Monday morning, receive 3 ideas on how to work more effectively in product and dev teams.
To receive articles like this, please subscribe to The SEO Sprint 👇.
💡 3 Short Ideas
Short ideas on how to improve working with devs and product teams.
#1 - Why Your SEO Projects Fail
A whopping 86% of IT and software projects fail to deliver on time or within budget.
So, it’s no wonder SEO specialists run into execution challenges when working in businesses.
It’s inevitable that tech projects fail. Just like Google algorithm updates, Nick LeRoy lunch in his newsletter or Barry Schwartz reporting on something John Mueller Tweeted.
But is resistance futile? Can you do anything to reduce the chances of failure?
The answer is YES!
I’ve worked inside product and dev teams for years now. I’ve seen projects fail for various reasons, but they can usually be grouped under three factors:
🤖 Poor requirements - A lack of defining exactly what you want the development team to build.
🗣️ Poor communication - A breakdown in communication between different teams working on the project.
🥅 Unclear goals - A lack of clear objectives or goals to help teams understand when a project is successful.
But how does understanding project failure help you get SEO projects executed?
Easy. Avoid the same traps everyone falls into that cause projects to fail.
I’ve been using these three factors (goals, requirements, communication) to spot when a project is in danger of going into the failure zone. Think of them as failure points.
As an SEO professional working in any team (particularly in-house), you must own these three factors. Why? Because if you don’t, you’re going to end up in the 86% of projects that fail.
So, how do I make sure that my project is delivered on time and within budget?
First, you need to accept that your SEO project has a high chance of failing if you aren’t aware of these three failure points.
Next, I want you to read the next few points, bookmark the newsletters I’ve recommended and read them.
It might help you avoid project failure.
Requirements
Requirements seem easy. I mean, you just write down what you want the dev to implement.
The problem is that many focus on telling developers exactly what to implement. Not provide them with a problem to solve. Which, from my experience, causes more problems than it solves.
The best way I’ve found over the years to communicate requirements is by using examples. Lots and lots of examples. These help show clear pass/fail criteria. Give the dev and designer wiggle room. And help everyone build the same mental model.
I’d recommend bookmarking the following newsletters, which provide more detail:
Specification by Example (I’d start here)
Communication
I could write a whole book on communication. But this is a newsletter. So I’ll keep it short.
The goal of communicating with developers or product teams is to get on the same page about what you are building and why you are building it.
Not just once, but over and over again. Consistency is key. Otherwise, team members will forget what you were working on and why you were working on it.
I’d recommend bookmarking these newsletters as they provide a lot more practical advice about communication:
Conways Law (I’d start here)
Shared Understanding (And here)
Goals
When teams think of goals, it’s usually SEO traffic or rankings. But when you work within product and dev teams, you need to identify and agree on what success looks like.
Agreeing on these metrics is key because you might need their help to actually pull the data into a report. And these reports can help you tell if a project is successful. Or if further work might need to be done.
I’d recommend bookmarking and reading these newsletters, which provide more detail:
#2 - Hot Potato Handoff
The biggest misconception in companies is believing handoff goes one way. An SEO hands off requirements to a designer, who then sends designs to a developer.
This means the SEO and designer need to get the requirements right on the first pass. Yet, this usually results in rushed and poor requirements.
In my experience, poor requirements are one of the biggest reasons SEO projects fail.
Instead, Brad Frost and Dan Mall recommend trying the Hot Potato Process.
The process helps pass ideas back and forth between team members. It allows them to iterate on ideas throughout the project life-cycle.
But how does this process help reduce the chances of failure?
Well, The Hot Potato process actually helps teams to:
🧠 Build Shared Understanding
👥 Work in a Triad Team Structure
When iterating on ideas, the team prioritises conversation over documentation. This stops the SEO, designer and dev making assumptions that can lead to complexity. They also work together as a problem-solving unit. Updating requirements as they build on ideas.
When teams work in this way, it helps:
😠 Reduces misunderstandings
📡 Reduces unnecessary complexity
🔧 Reduces the need for rework
🐞 Reduces unnecessary defects and bugs
🤖 Highlights if the requirements are doable
Building shared understanding helps turn complex projects into simple, realistic release plans.
But do not think simple means easy.
Simple plans are complex. That is what I've learned after years of working with developers and designers. There are always assumptions and questions when building new functionality into a system.
So, how can you use this method to work better with developers?
Simple. I want you to do three things:
Don't rely on passing off SEO documentation to other team members (Slides, Word, Sheets).
Book a call with devs, designers and product to talk through SEO requests (and get feedback).
Try to form your own problem-solving unit around SEO projects (dev, designer, product, etc.).
#3 - Why Your SEO Documentation Fails
As an industry, we rely on documentation to present our ideas to developers. And it might be causing our SEO projects to fail.
Think about it. We send SEO action lists in Google Sheets. Write SEO tasks straight into Jira or Asana. And deliver SEO training via a slide deck.
The problem is that when we rely on SEO documentation to present ideas to development and product teams, there are four possibilities:
😃 Read and understand what has been written
🤔 Read and interpret what you’ve written or,
😠 Skim-read the document without actually taking it in
😡 Don’t read the document at all.
I’ve spent years working alongside dev and product teams. Most seem to choose options 🤔, 😠 or 😡.
I’ve experienced devs, designers, and product team members nod along in agreement when asked if they have read its contents. Only a few weeks later, to not understand the task and do the opposite.
For example, this happened to me a few months ago for a simple title tag change:
“Developer: The change has been implemented on staging.”
“Me: I’m testing the changes and it seems the h1 tags have been updated, not the title tags?”
“Developer: Oh, I thought the ticket was about h1 tags? I’ll make the change.”
“Me: Not a problem, yep I can see the title tags have been updated, thank you”
For small tasks like this, it is an easy fix (especially after building good dev partnerships).
But with more complex projects, this can become a nightmare.
The larger the project, the more complex it becomes. And the easier it is for misunderstandings to happen within the team. I’ve seen this happen many times. What seems like a “simple” request, starts to turn into a larger and larger project. As devs, designers and product team members need to turn around and fix issues caused by misunderstandings.
Alright, but how can you, as an SEO, avoid these common pitfalls?
Well, I’ve learned a simple solution: speak to developers to build a shared understanding within the team.
I know groundbreaking stuff. Speak to people. You never thought of that.
But the thing is, it works. I’ve worked within dev, design and product teams for years. And speaking to developers on a regular basis is one of the most impactful things I have done to get projects over the line.
It’s not easy. Developers hate meetings and ideas that waste their time. But it is one of the most impactful activities you can do to make sure misunderstandings don’t happen.
Don’t believe me? What if I told you this is the same lesson learned by SEOs who get sh*t done when they move in-house? And I’ve already written about these lessons or recorded podcasts so you can learn more.
Here is what I want you to do.
Bookmark and read the following newsletter SEO & Devs: 5 Lessons from In-house: #4 Conversation > Documentation.
Take some time to listen to The SEO Sprint Podcast (especially Areej AbuAli, Abby Gleason and Gus Pelogia episodes).
If you enjoyed reading this article, then consider the following:
📰 Share — Please share the newsletter with your network or colleagues if you think they might find it helpful!
✉️ Subscribe to The SEO Sprint newsletter — if you haven’t already, please consider subscribing.