Frustrated by technical SEO tickets that never get fixed? In this episode of Whiteboard Friday, Gus Pelogia explains how adopting a "product mindset" can bridge the gap between SEOs and developers. Learn how to leverage sprint planning and discovery meetings, bundle tasks into larger projects, and build MVPs to prove value and get your initiatives prioritized.

Click on the whiteboard image above to open a high-resolution version!

Hi, everyone. I'm Gus Pelogia, SEO product manager, and today I'm here to talk about how to develop a product mindset for better SEO.

Now, as an SEO, I sit in a product team, which means that I have UX and I have engineers. All of these agile ceremonies are part of my day-to-day work. And that really helps me to understand the universe that the engineers and the developers are in. So it makes a lot more sense than just hearing back from them once a month, like a lot of people in SEO will have, that it's like, "Oh, this ticket? Oh, we forgot about it. Oh, we're going to do it later."

So I want to talk to you about how all of the ceremonies are and how you can bring that to your day-to-day, and hopefully you're not going to be frustrated with tickets that don't get done or all of the technical things you want to fix but never get fixed.

These are some of the agile ceremonies. These are part of my day-to-day. There might be others that I just don't follow. But daily standups, sprint planning, discovery, backlog refinement, and sprint review.

It's a lot to talk about all of them, so I want to focus on two of them today.

The first one is the sprint planning. So every two weeks, that's the length of my sprint, some are longer depending on the company and the team, but every two weeks, I sit with the engineers and say, "Right, these are the tickets we're going to do in the next two weeks."

At this point, the tickets are already organized. You know the velocity that your engineers have. So if you have three people on your team and they do three story points or five story points and we vote before on how big a ticket is, and maybe me, as an engineer, I'm a junior, I can only do five story points every sprint, so that gives me an idea of who is available and how much they can take.

A little extra tip here is that they are doing things that are not just the tickets that you requested. So I go ahead with a team lead, and I say, "Hey, how many points do you think you can give me next sprint?" And that really helps me to look at the impact versus the effort because maybe there is something that is a nice to have, but once the engineers estimate that this is going to be 10 story points, so this is actually a month of work for somebody, do I want them to spend the whole month doing this?

Or maybe there's something that has a higher impact, and it's a lower effort that it really helps you to decide what to do next. Honestly, there are a lot of things that we put on this list and later realize it's not worth doing a lot of those, and they just keep rolling and staying at the end of the backlog until someday we decide let's mark this as "won't do" and we move on. 

The second ceremony that I want to talk about is discovery. This I find just fascinating to be in a meeting like this because it really helps me to get a lot of answers from engineers.

As a product person, you might see the memes and jokes around the product person is just demanding we want this, we're going to release that, and the engineers are the ones that are actually doing all the heavy lifting behind it.

If you're not aligned, then you're promising something that will not be delivered on time, or you're going to just put pressure on somebody because you made a promise somewhere else and they have to figure it out. 

So in the discovery meeting – that's when you meet with all your stakeholders. There might be an SEO, UX. You might have a content editor. And you're going to have your engineers. You're going to say, "Right, this is the next thing we want to build." 

I love to go to these meetings well-prepared. So maybe you can do an AI prototype of the next page you want to do. Or maybe you already have all the arguments to explain why you want to build this or that. You kind of get like a sense from the engineers – is this something that’s really easy? Because it looks easy to do, but they might see, and they will definitely see things that we, as SEOs, are not seeing.

So, for example, you say “oh, we just need to update a plug-in.” Well, actually, we need to update some other ones because there is a security threat. There are always more reasons than just the ones that we are seeing as SEOs. The engineers have to do all of this work. Even if it's sometimes invisible work, you'll see it if it's not done, if something is broken. Then you're pointing fingers. So they do have to work on a lot more things.

So talking with them and understanding how complex something is at this stage, before anything is built, gives you a sense of, oh, I really want to pursue this. Or maybe I have five of these in the air. They're all big. We can't do all five. At this point, before anything is built, you already have an idea of, okay, this is how we're going to filter this. Or maybe you just drop an idea completely because it's going to cost way too much, and there are other things that must be done first.

It definitely helps you to avoid a lot of surprises when two weeks later, something is in a sprint, and you're talking about this ticket and people are like, "Why is this?"

So the discovery kind of aligns everyone to say these are the next things we're going to do.

It's much smoother later, once things are being built and when the process is happening, and things are in action. 

Something else that I do, that I learned once I started working with the product teams and thinking like a product manager, is to go away from just doing tasks to building topics or projects or epics, like we like to call them.

Here are some examples. You might see some 404s, and you say, "Well, we need to fix the 404s." But if you sell this as a bigger project and include all the little things that are inside, then suddenly this is one important thing and not 50 tasks that are just sprinkled all over a sprint. Maybe you want to fix 404s. Instead of doing that, you will eliminate all your non-200s. 

Or instead of just updating plug-ins, you want to tackle all security issues because plug-ins come with plans. So there's a bigger task in here, and that one, updating the plug-ins is just part of it.

A similar thing, maybe you were just starting with, we need to write some blog posts, whatever that means, to do something like a content hub. So you're just selling this as a separate project or something bigger. And maybe some people that don't care about blog posts, they would care about a content hub because a content hub might include some PR. It might include videos. It might include other things, and other teams are involved, and everyone can see a potential benefit for them as this is happening.

It's also easier to say this quarter we're going to do 4 things instead of we're going to do 200 tasks. It's easier to sell. It's easier to understand. And people are more committed to do that from start to end.

Same thing with maybe you want to add some CTAs. Let's do a conversion rate program. It's much bigger. It's not just CTAs. But there are more things and more teams involved.

Or resizing images is just one task that you can do to improve page speed, which is much bigger than just chopping some images. 

The next thing I want to talk about is how to build an MVP. This is a concept that I learned as I started working with product teams, and it really helped me to make a lot of these projects a little bit smaller and deliver something faster and learn from it because the MVP is the minimum viable product, and it's just enough to prove that something works. 

So if you don't make it too long, if you don't need to add all the flair and glare sometimes, but if you see this is working, that's enough to give confidence to people to say, "Let's invest on this for another one, two, or three months."

I promise you, every time you have an idea, and you start building it, halfway through it, you discover new ideas. You see that it can change the direction a little bit.

So even if you had the most perfect idea that you thought we must do this from start to end, and it's going to be great, halfway through it, you realize, "Eh, I don't care too much about this." Or, "This is too complicated for just a little improvement." So you start shortening things just to the level to say this still works.

It still does what the team and the company expect from it, and then you can move on to develop the full version once you have more confidence that something actually works.

An MVP might be you just do a release in one market. It might be that you reuse a design that already exists on a page instead of creating a completely new one.

It might be doing something manually, just to see, okay, this does work, and then you can go and create like a whole system that will automatically do things on your pages, yada yada yada.

So yeah, MVP, it's great. It also helps you to build that confidence, but to make sure that you are not in the wrong direction. And if you are, maybe you have time to change, or maybe you realize this was not a good idea at all from the get-go, so you can stop there. 

The last thing I want to talk to you about is that output is different than outcome. Often, let's say if you're delivering a technical audit, you have a list of problems, things that need to be fixed on a website.

This is just the output, right? Nothing was fixed. No extra traffic is coming through, no leads, no sales. So you still need to prove that something works and has an impact.

Just delivering a piece of a job, it's maybe half of the work, and then proving the impact and learning from it and doing a little bit better every time, that's when you start getting the outcome.

That's when things start doing what they are meant to do and start getting real results.

That's all I have for today. So I hope this was useful. I hope you had a good time learning a little bit about how an SEO team works embedded in a product team. And see you next time.