Outcome Mentality, Writing Effective Tickets and Impact of Shipping Slow
3-2-1 Mondays - Edition #3
A weekly newsletter that provides practical advice for SEOs on how to work with product and development teams.
If you want to help improve The SEO Sprint, please leave feedback!
To receive articles like this, please subscribe to The SEO Sprint 👇.
Before we jump into this week's newsletter, I wanted to promote Similar.ai, whose teams have impressed me with a product that can help SEO teams get things done.
Similar.ai is a no-code SEO automation toolbox that provides organisations with a way to unlock the power of AI to implement SEO recommendations at scale across thousands or millions of pages.
Once integrated by your engineering team, Similar.ai allows SEO teams to create bespoke no-code recipes at scale. For example, SEO teams are using Similar.ai to:
❌ Clean-up duplicate pages - Create recipes to automatically 301 redirect, canonicalise or noindex duplicate or irrelevant content at scale across thousands or millions of pages.
🔗 Create intelligent internal linking - Create internal linking recipes that add internal linking blocks to combine AI understanding of topical relevance with a page-by-page understanding of demand to help boost SEO traffic.
📃 Content creation - Create recipes that can optimise or create product-led content that drives SEO traffic to your website using keyword, topic and inventory data.
Not only does this solution allow you to implement bespoke SEO no-code recipes quickly, but their toolbox allows you to use A/B split testing to measure the impact of your work!
Similar.ai is the no-code automation SEO stack designed for anyone to use and grow their business at scale.
Sound too good to be true? Then book a demo call with their team today 👇️.
💡 3 Short Ideas
Short ideas on how to improve working with devs and product teams.
1) Outcome Mentality in SEO 🧠
The world's most successful product and engineering teams have learned to focus on solving customer problems rather than just shipping deliverables.
How do they do this?
They focus on measuring outcomes, not focusing on outputs.
Page load speed optimisation projects are a very good reflection of this concept in action.
For years it has been a known fact that site speed impacts the bottom line of a business. Yet, many brands and website owners have only really begun improving page load speed since the launch of Core Web Vital metrics.
However, the focus on simply hitting the Core Web Vital metric scores is an output-focused mentality. The result of focusing on deliverables raises a number of questions from internal stakeholders around dealing with site speed:
How does page load speed optimisation work to change user behaviour?
How many changes do we need to make before it has a positive impact?
How do you know the changes you made have a positive effect on driving results?
These fundamental questions are what outcomes can help teams answer. The definition of outcome vs outputs are:
🏕️ Outcome - An outcome is a way to measure success based on positive user or customer behaviour. It’s what you want customers to do to drive business results.
🔧 Output - An output is simply deliverables or a tactic that you assume will impact business results.
As SEO professionals, we need to shift to an outcome mindset.
Our focus shouldn’t be on the number of deliverables we ship but focus on positively changing customer behaviour that drives business results by working on the right deliverables.
It doesn’t matter if we achieve the change from one deliverable or a hundred, the important thing is changing customer behaviour that drives business results.
In other words, we need to maximise business outcomes and minimize SEO deliverables to drive results.
In large organisations where priority and resources are essential, making sure you are working on the right deliverables is critical.
I’ve written more detail about the Outcome Mindset shift in SEO 👇
2) Writing Effective SEO Tickets 🎫
Creating effective tickets is critical to getting things executed by a development team.
A ticket can be a single source of truth for a task being requested by a product, business or marketing team. A misunderstood or poorly written ticket can cause a delay in a project being completed.
If the ticket isn’t understood by dev teams this can:
🐞 Create bugs or defects in the SEO code quality of a website
⌛ Delay SEO projects while the team try to understand the ticket
❌ Get SEO projects rejected because it lacks technical feasibility
It’s critical that development tickets are clear, easily testable and can be marked as done, and help developers have a shared mental model of what we are trying to achieve.
Unfortunately, if you Google “how to write dev tickets”, you get a lot of optimised content that doesn’t provide practical advice (thanks, SEO?). I’ve written hundreds of dev tickets, gotten feedback from real projects and made all the mistakes you can make.
After trial and error, I settled on a framework that incorporates many of the best practices to write an effective ticket that applies Specification by Example, Essential XP: Card, Conversation, Confirmation and Shared Understanding concepts.
I call this framework Examples, Card, Conversation and Confirmation (ECCC):
🖌️ Examples - Gather concrete examples using SEO data or designs to communicate to the development teams what you want them to build.
🗃️ Card - Write a card (ticket) with your acceptance criteria and scenarios based on your concrete examples.
🗣️ Conversation - Discuss the ticket with the development team and use the examples and scenarios to build shared understanding.
✅ Confirmation - Once you’ve discussed the ticket with the dev team, and made any adjustments, you should confirm the ticket is “ready” to be moved into the dev backlog.
I’ve written in detail about how I write SEO tickets using the ECCC framework in the following newsletter 👇
3) Shipping Slow Changes your SEO Strategy ⚡️
Any SEO team’s strategy, roadmap or audit needs to take into account the release cadence of a development team.
How can SEOs do this? Easy, by asking a simple question:
"How often does your dev team ship code to production?”
The question can highlight if your development team are high-performing or low-performing:
High-performance teams spend their time focusing on delivering features, solving customer problems and driving business results.
Low-performance teams spend their time fixing past releases, waiting too long for things to be released and dealing with technical debt.
What is the difference between high vs low performing teams?
⚡ How fast and often they ship.
A survey conducted from 2,000+ companies between 2013 and 2017 by Nicole Forsgren, Jez Humble and Gene Kim found that what separates elite engineering teams from average ones is mostly how fast and often they ship code.
Why does shipping fast create successful, high-performing elite teams?
Well, the greater the complexity of a feature or piece of functionality, the longer it takes to ship. The longer it takes to push code, the greater the chance that there is:
Scope creep – Specifications are complex, which creates uncertainty on what is needed.
Blockers – More code means there is a greater chance 1 line of code will block the entire release.
Bugs – The more significant the code the higher the chance that bugs are missed.
This is why in 2013, Intercom famously wrote that shipping is your company’s heartbeat. It brings life to your team, product and customers. Shipping fast often helps a business get feedback quicker and helps “steer” the business forward in the right direction.
The release cadence of a development team (how often they ship code to production) can directly impact how much an SEO team can get done. So we need to take it into account when creating our SEO strategies.
What is a release cadence?
The release cadence is how often a product and development team releases code into production. A release cadence can happen daily, weekly, fortnightly, etc.
For example, when I was at DeepCrawl, the development team released every 2 weeks, whereas with a current SaaS client, they release code every week, and an enterprise client releases every 4 weeks.
SEO teams need to take into account the release cadence of a development team and ask a simple question to identify:
⚡ High-performance teams - A development team that ships code in a day or every week can allow SEO teams to get big initiatives and small fixes implemented, which drive a business forward.
👣 Low-performance teams - A development team that ships code every 4+ weeks will most likely need to have initiatives ruthlessly prioritised to make each attempt count.
I’ve provided further details on how the release cadence of a development team can change your SEO strategy 👇
📰 2 Articles to Explore
Articles to explore to help be more effective with product and dev teams.
10 Traits of Great PMs
by Noah Weiss
"PMs have diverse backgrounds, murky responsibilities, and wildly varied expectations across companies. It’s nearly impossible to define what makes a PM great. With those caveats, here is an attempt at ten commonalities."
Three drawings I use to explain agile
by Michael Williams
"For the past couple of years, I’ve been coaching product leaders and product teams trying to transform the way a giant organization works. We talk about things like communicating priorities, why iterative development is important, and how to balance tech debt versus refactoring. When those concepts come up, I draw out my mental model of that idea and it (almost) always helps us communicate much more effectively."
❓ 1 Question For You
A question for you to think about this week while working.
How often does your development team ship code to production?
How did I do this week?
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 useful!
✉️ Subscribe to The SEO Sprint newsletter — if you haven’t already then please consider subscribing to the newsletter.
Enjoy the rest of your week 😎
Can I add a subsequent question to yours?
How often does your development team ship code to production?
And how can you turn it into a meaningful KPI to drive change into your own organization?