How product thinking can make you a better SEO

I’ve always considered myself a user-centric SEO. Much of my work has focused on search experience optimization, or SXO, which is about looking beyond rankings and traffic and paying attention to what happens after someone clicks through from search.

• Are users finding what they need?
• Are they making it far enough down the page to see important information?
• Are they getting confused by the layout?
• Are they clicking things that look interactive but aren’t?
• Are they taking the action we actually want them to take?

That way of thinking has been part of my work for a long time. Moving into product felt like a natural progression, since I wasn’t the first to think about users. But I didn’t expect the level of detail to be so different.

Product has forced me to think about the user experience before we even build something. I’m thinking more about use cases, how a feature could evolve, how developers interpret requirements, what happens if someone uses something in a way we didn’t expect, and whether a decision we make today will make the next version harder to build.

Basically, anyone who’s coming into contact with a product is a user, and you have to think about how to translate it for each audience at each stage of development. That shift has also affected how I think about SEO.

Communicating with developers is a skill of its own

One of the biggest lessons I’ve learned is that communicating well with developers usually means being simple, direct, and very clear about the problem you’re trying to solve.

As SEOs, we’re used to making recommendations: Change this title tag, add these internal links, fix this technical issue, etc. Because we usually have a pretty clear idea of what we want the end result to look like, it can be easy to get overly specific about how something should be implemented.

Working more closely with developers has made me realize that knowing what needs to happen isn’t always the same as knowing the best way to build it within a specific product.

When I’m scoping something now, I focus on a few basics:

• What’s the problem?
• Why does it matter?
• What outcome are we trying to achieve?
• What requirements absolutely need to be preserved?

That last question is especially important. Sometimes requirements need to be specific. If links need to be present in the rendered HTML, say that. If a user needs to view something in a certain way, make that clear.

But that doesn’t always mean I need to tell the developer exactly how to get there.

There’s a difference between saying, “These capabilities need to be present,” and saying, “Build this exact component using this exact implementation.” The first communicates the requirement. The second assumes I know the best way to solve it inside the existing codebase.

Sometimes the product team knows, and sometimes the developer has a much better idea.

They may know there’s already functionality we can reuse. They may see a cleaner implementation. They may know the approach I’m suggesting will create technical debt somewhere else. Or they may be able to solve the same problem in a way that’s easier to maintain and scale.

I’ve learned that being too narrow when scoping something can actually make the solution worse. You can accidentally increase development effort, design around one use case when the same functionality could solve several, or create something that works now but becomes difficult to maintain later.

That doesn’t mean tickets should be too vague, though. The goal is to explain the problem clearly enough that everyone understands what needs to be solved, while leaving enough room for the people who understand the codebase best to help decide how to solve it.

This strategy has changed how I think about a good product recommendation. The goal isn’t always to hand developers a fully designed solution. Instead, give them enough context to understand the problem and enough guidance to make sure the final implementation actually solves it.

Dig deeper: How SEOs can successfully collaborate with web developers

Forward-thinking matters more than expected

Product has also made me think much further ahead than I used to. Sometimes, SEO work can be very immediate. You identify the problem, recommend the change, implement it, and move on.

When you’re building something into a product, it gets harder to think that way because you have to consider what happens after version one.

• What happens when we need to change this in six months?
• What happens if another team wants to use it?
• What if the requirements expand?
• What if the thing we’re building today becomes the foundation for something much bigger later?

That doesn’t mean you need to build every feature for every possible future scenario. You still need an MVP, and overbuilding creates its own problems. But I’ve learned that there’s a difference between building something simple and building something that boxes you in.

Say you want to create a module that displays three related internal links. The immediate SEO requirement is pretty straightforward: Show three relevant links.

But once you think about it through a product lens, you start asking more questions:

• Would we eventually want to show more than three links?
• Could different page types need different logic?
• What happens if there aren’t three relevant results?
• Would editors ever need to override the recommendations?
• Could we reuse the same component elsewhere?
• Do we want to track clicks on those links?

You don’t need to build all of that into the first version. The point is to know where the feature could realistically go so you don’t make an early decision that creates unnecessary limitations later.

I’ve started thinking less in terms of “How do we fix this right now?” and more in terms of “How do we solve this now without making the next version harder than it needs to be?”

That change in thinking has probably been one of the most useful things product has taught me.

Start with the problem before falling in love with the solution

Another lesson product has reinforced is something that already comes up a lot in SEO testing: A tactic is not a problem statement.

SEOs can get attached to solutions quickly. “We should add FAQs to the page,” or “Let’s create a new page for this.” We may need these things based on the data we’re working with, but we need to think more about the why from the user perspective.

Product forces you to spend more time defining the actual problem before jumping to the solution that feels obvious.

An FAQ section is one solution, while creating a separate page is another. However, neither should be considered the answer until you’ve clearly defined what issue you’re trying to address.

From an SEO perspective, think of this as a testing process. The key is to avoid assuming something will work just because it’s considered a best practice. Start with data, formulate a hypothesis, implement a change, and observe the results.

This approach clarifies your strategy and tactics for clients and enhances your communication skills. Viewing SEO through a product lens and applying that perspective to your deliverables makes you a more effective communicator.

Product thinking follows a similar process. My boss, James Nash, gave me a set of guiding questions when designing:

• Do I know what use cases this flow needs to solve? If yes, can I clearly show how each gets addressed?
• Is my design/scope boxing us in? Will this still make sense after new versions of this come out?
• Is it clear to the user what they should do?

Another important thing James has brought up before is that if a user can mess something up, they will. You have to account for every way a user can misunderstand and make sure your scope or design is foolproof.

Dig deeper: 9 ways to become an SEO problem-solver

Shipping something isn’t the same as solving the problem

This is probably where product overlaps most with the way I already think about SEO testing.

Getting something implemented can feel like the finish line, especially when a project has been sitting in a backlog for months. Once it finally ships, it’s tempting to mark it as done and move on.

Product makes it clear that shipping isn’t the same as solving the problem. Once something goes live, you still need to know whether:

• People are using it.
• They’re using it the way you expected.
• The original problem improved.
• You accidentally created a new problem.

The workflow is closer to:

• Problem.
• Hypothesis.
• Scope.
• Build.
• Launch.
• Measure.
• Learn.
• Iterate.

That process feels very familiar if you come from an SEO testing background. Remember, implementation isn’t the end of the test. It’s the point where you finally get to see whether your hypothesis was right.

The same principle applies to product work. A feature shipping successfully only tells you it shipped. It doesn’t automatically tell you that it worked.

This distinction between output and outcome is one I think SEOs could benefit from thinking about more often. A shipped feature is an output, a solved problem is an outcome, and those aren’t always the same thing.

Product has made me more obsessive about the details

SEO and SXO already made me think beyond the click and about the user’s behavior. It made me question whether people were actually interacting with pages the way I expected. And SEO testing made me question whether so-called best practices were actually improving anything.

Product has taken that mindset and pushed it much further.

Now I’m thinking about the wording in a ticket, the flexibility of a component, the edge case nobody noticed yet, what a developer needs to know vs. what they should have room to decide, whether something can scale, and whether the way we build it today will create problems later.

I’m also thinking more carefully about what happens after launch and whether the thing we built actually solved the problem we started with.

Product taught me how much detail goes into building something for those users in the first place. That, in turn, has changed how I look at SEO recommendations because they get built into products people actually have to use.

Dig deeper: SEO product management: Key framework and fundamentals