Habit Flywheel, Makers Schedule, Problem Statements
Habit Flywheel, Makers Schedule, Problem Statements
Edition #25 - Monday Ideas
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 👇.
[Sponsor]
Think You Can Outsmart Google's Algorithms On Your Own?
To boost your website's organic traffic and increase lead generation, you need high-quality backlinks.
Dofollow.com helps SaaS companies turn their content into a sustainable customer acquisition engine.
Gain an advantage in search results with backlinks from the world's most desired SaaS websites:
HubSpot
Zendesk
Mailchimp, and
BigCommerce, to name a few.
💡 3 Short Ideas
Short ideas on how to improve working with devs and product teams.
1) The Habit Flywheel
Working with developers is a habit.
But like any habit, It takes time and is hard to form.
I’ve seen teams give up on working together after just 2 or 3 weeks of trying. But what I’ve learned is you’ve got to keep pushing.
The reality is going to take a minimum of 2 months to get teams to form the habit of working with developers on projects automatically. Which means you can’t give up after 2 or 3 weeks.
You need to keep pushing to form collaboration habits.
Steven Ripplinger recommends thinking about habit forming like a Habit Flywheel.
The Habit Flywheel is a mental model of how people can form new habits. The flywheel is a 3 step process:
🏁 Start - You start the habit or use forcing mechanisms.
🏃 Form habits - You start to form habits over time (which is hard).
🔄 The Habit Flywheel - Your habits form a flywheel, and it gets easier.
Just like most things, The Habit Flywheel requires ongoing effort to maintain.
How can SEO professionals use The Habit Flywheel when collaborating with developers?
You are going to need to take ownership of the partnership.
Habits need a forcing mechanism. It takes a lot of effort to climb the long road of habit forming. Once you start, it should get easier and easier to get developers into a meeting.
Until it becomes second nature to both SEOs and development teams.
I’ve found these three practices can help kick-start the collaboration habit:
🤏 Start small: Start small with 1 meeting a week before going big.
📅 Place anchors: Make sure to put recurring meetings in the calendar.
⚠️ Keep a routine: Keep pushing the routine of attending meetings.
Forming collaboration habits takes time. So I keep following these simple steps to help teams get into the routine of meeting and working together to solve problems (product or SEO).
2) Why Maker’s Schedule Matters
Developers hate meetings. But why?
Because developers are on a maker's schedule.
A famous Paul Graham essay Maker’s vs. Manger’s Schedule defines the maker schedule as:
Individuals who make things (developers, designers, writers, etc.) that need to block out a minimum of half a day to complete a task.
To a developer, designer or content writer meetings are a disaster.
A maker needs long stretches of time to think through a problem and complete a task. A single meeting in the middle of the afternoon can cause the developer to context switch. Studies show context switching is the silent killer of productivity (see previous newsletter here).
It isn’t just academic studies that show this. A survey of 1,000 developers found the second biggest productivity drain was attending unnecessary meetings.
Why do we need to take into account the developer’s maker's schedule?
Simple. Developers’ productivity will directly impact their ability to hit deadlines.
A lot of companies make the mistake of pulling developers into meetings. Even when they are not needed. All the while silently killing project productivity.
Then they turn around and blame developers for not hitting deadlines. Which can demoralise the team and further reduce productivity.
It’s a vicious cycle.
So, how can we as SEO professionals help break this cycle?
We need to take into account the maker’s half-day units of time. They need long stretches of uninterrupted time to get things done.
I’d recommend the following actions to give makers plenty of time to work productively:
👋 Anchor points - Schedule meetings early morning, at midday or late afternoon.
🗂️ Group meetings - Book meetings after other meetings.
🔄 Schedule routine - Make each week a routine so devs know what to expect.
🎯 Plan ahead - Book meetings 1-2 weeks ahead of time so devs can plan their week.
📄 Meeting agendas - Create a meeting agenda (and share it).
These tweaks to booking meetings really help developers and designers hit deadlines consistently.
3) Tip for Writing Problem Statements
You bring the WHY the developers can tell you HOW.
As a baby PM, I was terrible at framing work in problems worth solving by the development team.
If you don’t know, any good developer is a problem solver. That’s literally their job. Finding technical solutions to business problems using technology.
It’s your job as the business stakeholder (PM or SEO) to bring problems to the team worth solving.
The issue is that A LOT of business stakeholders are terrible at communicating problems. This goes double for SEO professionals (including me).
I was terrible until I learned the trick of writing a problem statements.
A problem statement is a written statement made up of three parts:
🤔 Situation: What are the current facts the business is facing?
🤯 Complication: What is the event which has caused issues?
☠️ Problem: Summarising the situation and complication into 1-2 sentences.
Let’s take a quick example of a problem statement:
I use this simple template to make sure I am focusing on solving the right problem. And I am framing the SEO work as a problem to solve. Not just a list of tasks that need to be completed.
Don’t be fooled by the 1-2 sentences per statement.
It takes time to refine and edit each part of the problem statement. You also need feedback from your internal network. To make sure it makes sense and you understand the assignment.
Once I’ve figured out the problem I then need to make sure I answer the WHY question. Again, this is about validating if the problem is worth solving.
Writing down the PROBLEM and WHY it is worth solving are the first two questions I ask when working on:
✍️ Product Briefs: The document I provide to developers and designers.
🌏 Strategy documents: The document I provide to business stakeholders.
P.S. Don’t forget to remove the situation and complication before you’re ready to share any documents. Only show the problem statement to your stakeholders.
P.P.S. There is a lot more to writing problem statements and clarifying problems in SEO. If you want to learn the step-by-step process check out my course.
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.