Scrum Theory, Assumptions, Writing is Thinking
Scrum Theory, Assumptions, Writing is Thinking
Edition #21 - 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 Scrum Theory Matters
Scrum is one of the most popular agile frameworks (9/10 teams use it).
So if you work with a product and engineering team. There is a very high chance of using the Scrum framework in one way or another.
This is important because the Scrum method teaches product and dev teams the need to deliver solutions using Scrum Theory.
Scrum Theory is based on two key ideas:
📈 Empiricism: The theory of making decisions based on experience.
🗑️ Lean Thinking: Reducing waste and continuously improving.
This means teams are taught to identify opportunities based on evidence and break down solutions into small iterative releases. This helps reduce risk and create predictability.
So, why does this matter when working with product and engineering teams?
Well, Scrum Theory is baked into how these teams will decide what to work on when using Scrum. These teams will want to work on opportunities that are:
🙈 Pick ideas backed up by evidence
🔨 Break down ideas into smaller pieces
💥 Release small pieces frequently and often
📈 Measure the impact of releases to gather data
🧠 Learn and adapt future releases based on evidence.
Any idea goes through this process. Not matter if it comes from product, UX, SEO or development. Tech teams obsess over avoiding placing bets that don’t drive business results.
It’s all about reducing risk. And creating predictable small releases that drive business results.
But how do you use Scrum Theory to get SEO projects executed?
First, you must know how teams think using the Scrum delivery methodology. You’ve already done that by reading this newsletter 🙂.
Second, you need to make sure you are working within their process:
🙈 Include evidence when providing SEO recommendations
🔨 Break down ideas into smaller pieces by getting devs involved early
💥 Join Scrum ceremonies to make sure smaller pieces are released
📈 Make sure to measure the impact of SEO releases to track success
🧠 Work with the team to interpret results and adapt future releases.
Do you want to learn more about working in a Scrum team? I’ve written in more detail about surviving Scrum as an SEO professional if you’d like to find out more👇.
#2 - Killer Assumption Stack
Picture this.
You’ve got a great opportunity to drive more relevant SEO traffic to the website. The product manager is onboard. They’ve told you that the way the website works, the opportunity can be implemented. You get buy-in from UX, sales and even someone from the leadership team.
Everyone is excited about the idea.
All you have to do is speak to the Tech Lead on the dev team. You have written a product brief, and a specification and even gotten a design from the UX Design Lead. You book a meeting with the Tech Lead to get that “green light”.
The Tech Lead looks over your product brief, specifications and the design.
“We can’t implement this,” they say.
Your eyes widen in shock and embarrassment. The Tech Lead then go through and explain why your idea, in its current form, won’t work. You start to panic. So many stakeholders were excited about this SEO project.
Luckily the meeting wasn’t a total loss. Your idea has legs, but it needs more discussion with the dev team to iron out feasibility issues. It can be done, but not the solution you had originally intended. Now it’s back to the drawing board.
This scenario happens in companies ALL THE TIME (yes, I’m shouting).
In this scenario, the assumptions are obvious:
🤖 The product manager assumed he understood the tech stack.
🗣️ You assumed the product manager knew what they were talking about.
👥 Business stakeholders assume you and the PM understand the idea.
Assumptions stack. And in teams, this house of cards can kill your projects dead in the water.
The problem is assumptions are everywhere. Whether you are building software or SEO features, a product and dev team can easily make the wrong assumptions about users. Then build the wrong feature to solve their problem.
So, how can you avoid killer assumptions on SEO projects?
There are two important ways you can avoid killer assumptions:
🗣️ Get stakeholders involved as early as possible in the project.
🚫 Identify your killer assumptions early so you can overcome them.
How do you identify killer assumptions? Well, I use a quick 4-step framework to discover, map and prioritise killer assumptions.
The 4-step process is as follows:
⁉️ Identify Risks and Assumptions - Start by writing down the risks and assumptions that might kill your SEO project. Ask yourself questions like “What has to happen for this opportunity not to work?”.
🆚 Risk vs. Impact Matrix - Create a 2x2 matrix. Map your risks and assumptions that you have written down based on the risk level and the impact it will have on the project.
🎓 Learning Log - Take your high-risk and high-impact assumptions, then prioritise them to create a “learning log” of what you need to understand to turn unknowns into knowns.
🧪 Experiments - Finally, I create a list of experiments or ways of de-risking the SEO project. Do I need to gather more evidence? Do I need to speak to the design, dev team or product team?
#3 - Writing is Thinking
Writing is a superpower, and it can literally change how you think.
Albert Einstein (yes, that one!) recommended writing as a way to clarify ideas:
“If you can't explain something simply, you don't understand it well enough. Writing can help to clarify ideas both externally and internally.” - Albert Einstein
Writing and thinking are closely linked; by improving one, you are also improving the other. Good writing is the result of critical thinking, and this can lead to even clearer thinking.
But why does this matter when working in tech cultures?
Well, world-renowned physicists are the only ones who recommend writing. Successful companies like Amazon and Stripe make writing part of their culture.
Jeff Bezos even wrote about the importance of writing in a 2017 letter to shareholders:
“We don’t do PowerPoint (or any other slide-oriented) presentations at Amazon. Instead, we write narratively structured six-page memos.”
At Stripe, writing is the number #1 way that teammates communicate.
“Writing forces you to structure your thoughts in a manner just not possible when you verbalize it. When I write, I have to offer structured, precise thoughts.” — Dave Nunez, Documentation Manager at Stripe
Writing is an important part of business culture at both these organisations, as it:
Increases time efficiency
Facilitates knowledge sharing
Encourages clear communication.
Writing forces employees to invest more time in shaping their ideas before sharing them. It makes information more accessible to everyone in the company.
How can I use writing to improve how I work in tech teams?
Honestly? Use writing to think through your SEO recommendations, projects or opportunities. It might shock you to learn that many people who send requests to the dev team don’t think them through.
It’s easier to make the devs figure it out.
This is why in tech teams, PMs use product requirement documents (PRDs) or product briefs. It helps them think through problems. Get feedback from developers, UX and other stakeholders. Shape the idea into something realistic.
Here is what I want you to do for your next SEO project:
Open a new Google document. Give it a title.
Write down the following questions:
What problem are we trying to solve?
Why is this problem worth solving?
When do you expect this to be complete?
Who are we targeting?
What are the specifications? (See here)
What questions do you have/need answering?
Answer these basic questions as best you can.
Throw it in a draw for a day or two and return to rewrite it.
Get feedback from stakeholders you trust (dev, UX, content, etc.)
This very simple process will help you think critically about your project. And getting feedback from stakeholders will help curb those assumptions.
p.s. Pro-tip #1: When sharing a document like this, always ask if there is a template the product team already use.
p.p.s Pro-tip #2: If you share the document with a stakeholder, ask for at minimum 1-2 pieces of feedback. They HAVE to share feedback in the document.
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 helpful!
✉️ Subscribe to The SEO Sprint newsletter — if you haven’t already, please consider subscribing.