Power of Persistence, Discovery before Sprints, Problem Space vs Solution Space
Monday 3-2-1 - Edition #7
Hello 👋,
Welcome to the 3-2-1 Monday newsletter.
Every Monday morning, start your week with the following:
💡 3 short ideas about working with devs and product teams.
📰 Two articles to explore to help be more effective with product and dev teams.
❓ One question for you to think about this week while working.
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) Power of Persistence
I’m going to let you in on a little secret about your SEO requests.
Unless you are persistent and boarding on annoying, it is likely that your SEO requests aren’t going to be made a priority.
Why?
Simple, the product and engineering teams deal with so many requests from business stakeholders that SEO recommendations are just part of the noise.
Just asking once is not going to be enough.
As a product manager, I always got requests from business, marketing and SEO teams. They would put them in the backlog with the intention of coming back to them later. I never did because another priority would always be around the corner.
Only those team members who followed up and annoyed me would have their requests looked at again. Then if they were a priority would get them pushed into the delivery process.
Not only did they follow up, but they also provided me with the following:
Why it was important
A specification that is needed
When it is needed by
This works because if the problem is worth following up on, it is an actual priority, rather than just an idea or something nice.
Product and engineering teams won't prioritise SEO tasks if you are not persistent or consistent with your communication.
So if you’re wondering why something hasn’t been implemented, review your communication and ask yourself:
How many times have you asked for something to be implemented?
Why should the team work on it?
What is the agreed specification?
2) Discovery and planning before Sprints
If you work in a team that uses Scrum, here is a tip that has helped me reduce sprint planning from hours to minutes.
Do discovery around tickets to get them ready before sprint planning.
The problem is that many think a ticket is “ready” when written and submitted to the dev backlog. From my experience, a ticket is only ready when the team agree on the contents and has a shared understanding of what is in the ticket.
When you write an SEO ticket and submit it to the backlog, the reality is that it is raw. A raw ticket is when you’ve written the ticket but hasn’t been discussed or reviewed by a development team.
This means when you get to the sprint planning event, the team must get their head around the tickets before they can estimate or even agree on doing the ticket. This can take a long time and can cause planning meetings to take hours.
Fun fact. You don’t have hours; I doubt you’ll be allocated 30 mins.
Instead, I have collaboration anchor points during the week dedicated to discussing SEO tickets or projects. This means the SEO, developer and product manager spend 30 mins max discussing and talking about a ticket. Getting it “ready” for the dev backlog and sprint planning.
Discovering and getting tickets ready before sprint planning allows the team to agree on realistic tickets. This allows developers to be warmed up to the problem and give accurate estimates of tickets, allowing the team to chunk tickets into smaller tasks easily.
3) Problem Space vs Solution Space
Do you ever feel like you don’t quite understand a business's target audience? The solutions or content you create just aren’t quite resonating with customers.
Understanding your target audience is a key skill in product management.
How do teams do this? Well, they get out of the building (GOOB).
This concept is also called immersion. Product teams need to observe and interact with customers in their own environment.
In product, there is a concept called problem space vs solution space:
Problem Space: This is where your target audience can be found and where their problems occur.
Solution Space: This is where your business builds solutions to solve customer problems.
A big problem in business is that we build solutions without ever really speaking to our customers. This means we lack empathy or understanding of their pain points or frustrations. This can result in spending resources and time on solutions that don’t drive results for the business or target audience.
Successful product teams get out of the building and try to understand their target audience’s pain points in their own environment.
This practice of immersion is something that is done at companies like Google, Airtable and Atlassian. Product managers go and try to understand customer pain points and problems in their own environment.
This means doing activities like:
Interviewing customers face-to-face
Visiting customers in their environment
Conducting workshops to understand specific problems
Listening to customer sales or support calls
Reviewing customer feedback
So, if you think you don’t understand a business's target audience, try GOOB.
📰 2 Articles to Explore
Articles to explore to help be more effective with product and dev teams.
What distinguishes the Top 1% of product managers?
by Ian McAllister
“The top 10% of product managers excel at a few of these things. The top 1% excel at most or all of them.”
Using Prioritization Matrices to Inform UX Decisions
by Sarah Gibbons
“Visuals such as charts and matrices can help practitioners base important decisions on objective, relevant criteria instead of subjective opinions.”
❓ 1 Question For You
A question for you to think about this week while working.
How persistent are you when communicating SEO recommendations?
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.
That moment when you're reading the first point in your newsletter Adam, and you start questioning your own requesting and communication procedures, just to see the same question at the end. :)