My name's Hugo Froes, and in this article, I'm going to be discussing user-centered product ops. Before I get started, I want to share a bit of background.

I'm currently a Product Operations Principal at FarFetch. I'm also a teacher, mentor, and coach, and facilitator when I have the time. Lastly, I love solving problems and I guess that's why I was drawn to product operations.

I'll be covering:

My journey to product ops

I want to take you a bit further back in my journey to the beginning. I was born and raised in South Africa in 1979. In 1999, I moved to Portugal to start my design career.

Like many people, when we start off our careers, I felt like there was always something missing, something that didn't make design seem like what I wanted to do. So I spent a better part of the early 2000s looking for my place and some of the later 2000s.

Funnily enough, in 2012, I discovered the world of user-centered design...

It was love at first sight, suddenly it made sense to me attaching to that. So I started moving into this area. The thing we started talking about were user experience, design thinking, and service design.

It was during this time I helped startups to grow, products to be born, and many public services to improve. But my focus was always on the people.

Moving into ops

Moving into product ops, again, it was about the people for me; empowering people, empowering teams, empowering products. Focusing so much on this empowering of people and the people feeling more comfortable and structured.

I guess the question is, why all this background?

It’s so you understand why I'm going to try and convince you that product ops can and should be user-centered.

In this article, I'm going to go through some of the principles we can pull from user-centered methodologies, and how I've applied them to my work. Hopefully, you'll find it useful and take away some things to apply to your own product ops practices.

Product ops

When we're talking about product ops, traditionally, what we see are keywords like efficiency, optimization, communications, processes, development, data, connective tissue, and documentation procedures.

All these keywords seem to focus on the process, the optimization, and the change. It's kind of ironic considering product people have become strong advocates of the users and their needs to build better products.

However, being user-focused can and will add an extra layer to every step of the process. That's what seems to be missing here and that's what I'm going to be talking about.

Being user-centered

What does being user-centered mean? It means focusing on:

  • The people working on the teams, those adopting the changes and going through them,
  • The people who need to develop and find their path within the org,
  • Those who need to communicate with each other, and
  • The people who want to increase their capabilities. Lastly,
  • Those who want to enjoy their work and be part of the community of practitioners.

It's about the product people - the people within the org.


If we look at a more or less standard approach to product ops, it can be broken down into four areas:

Building understanding

We have the first level which is building understanding, understanding the problem, the organization, the teams, and the people.

Identifying opportunities

The second part may be about analyzing what we've learned in the previous step to identify those opportunities for change.


Thirdly, we come to the ideation which is coming up with solutions to the challenges we've identified, and that bring the most value.


Lastly, it's about the implementation, the adoption, the impact of that change, and measuring that impact.

I'm going to dig into each of these steps and see how user-centered adds that extra layer, at least the way I see it.

Building understanding

Ops level

Starting off with building understanding, we look at the first level and if we're talking about ops, we know we need to understand the various aspects of the company and the people.

But at an ops level, we might include the following activities, things like interviews, observation, analysis.


Build empathy

When we talk about the user layer, we start talking about things like building empathy, which is trying to understand the people, not just the efficiency.

  • Who are the people working on the team?
  • How are they working with each other and connecting?

Looking at the problems from the person’s perspective

Looking at the problem from the person's perspective, so it's not just what the impact is for the company, or what we think it is for the org. But it's also looking at the problem from their point of view.

Identify advocates

Here, we might also identify advocates, people who can be those people who help us implement and who will be a defender of our process and the change we're trying to implement.

Understand the why

Then understanding the why. It's not just digging in. It's easy to have a lot of data and we'll have a lot of data, we'll have analytics, information coming from all over, surveys, etc. but it just tells us what's happening. With the user-centered approach, we can then understand the why.

  • Why are these things happening?
  • Why is it impacting the team negatively or positively?

And so what do we do once we've built that understanding?

Identifying opportunities

Now we move on to identifying those opportunities. The opportunities of change, the opportunities of things that could make change for the team.

How many of us have sat in a room and tried identifying those opportunities of change and putting together these big diagrams or mixing up ideas all over the place?

Ops level

It's about pinpointing those problems, areas that we should focus on. Being clear on where can I bring the most value or the most impact?


Objectives and intended outcomes

However, on the user-centered side, we also look at understanding the objectives and intended outcomes before moving towards a solution.

Potential impact

It's not just about implementing and saying, "Okay, let's see what's going to happen", we try and think about the potential impact of those changes on the teams, especially things like health and efficiency. Because the team health is important and how they accept those changes.

Visual thinking

Of course, the visual thinking, we can do pattern matching and sense-making. This comes a lot from looking at visuals very often, or looking at the way systems are connected from the user side and connecting to the user; user flows, customer journey maps.


Now, opportunities are great, but we need to think about the opportunity we want to seize, and how can we affect change within the team?

So we go into the ideation and the ideation is about trying to come up with those solutions once we've identified those opportunities.

  • What will be the actual change we will be implementing?
  • What will be the small things we’ll be implementing within the team?

Ops level

At an ops level, it may be about pulling together our knowledge around things like scrum frameworks, agile, lean, a lot of experience of how we've worked, how we've seen squads working in team organization, and trying to come up with a framework or the approach that will solve the problem.


People, culture, structure

However, when we go to the user-centered side, we use design ideation techniques to first look at the best way to solve the problem based on the people, the culture, and the structure.

Focus on the right solution

We don't just jump into something or base it on something we know exists. We focus on the right solution rather than forcing the people to adapt to an expectation of the methodology; "Agile has to work this way. Lean has to work that way".

What we're doing is saying, no, maybe it's a mix of them or maybe it's none of them, and we have to figure out a new solution that fits best with our product team.

Simplify complexity

Next, we look at simplifying complexity, which is reducing complexity. This helps us to mix and match existing methodologies, like I was saying, and uncover new ways of approaching the work.


Lastly, we have the actual implementation. So we've implemented it within the team and we see how it's going to impact the team.

Ops level

It's about measuring that change. It's about managing that change.

  • Is it a big or small change?
  • Does it get pushed all at once?
  • Or should it break down into smaller bits?

But anyone who has gone through this process will potentially agree with me - even the most well laid out plan or new approach that will solve all the problems never goes smoothly, it doesn't. We'll run into skeptics, we'll run into adoption, it can be more complex than expected.


This is where the human factor helps us understand the impact, identifying issues in time to adapt.

Constant learning and iteration

As I was saying, managing the change, measuring the impact on the ops level but when we go into the user side, we're talking about constant learning and iteration. The first solution will rarely be the best version of itself.

Coaching and collaboration

Coaching and collaboration with the people on the team, for them to feel comfortable and empowered by the change.

Team health and culture

Looking at the impact on the team’s health and culture at all stages.

Comfort and sentiment

Constantly analyzing the comfort and sentiment of the team. This is important because even if the change is being more efficient, being better, and you feel it changing the whole product team, if the whole team isn't feeling comfortable, and they're feeling like it's not giving them what they need or like it's pushing them to a direction they don't want to go.

They will eventually stop being advocates or stop defending it and feel uncomfortable.

People are unpredictable and complex

There is something we need to remember when being user-centered and want to pass this message on to you - people are unpredictable and complex.

Expecting they're all the same is a fantasy, the sooner we accept that the better the solutions we present.

I guess the big question is, how can we keep the user top of mind and not lose ourselves in only the optimization and efficiency?

Because that's the thing, it's very easy to look and say, "Well, we've managed to optimize this, we've managed to make it more efficient, the teams are better, they're working better."

But how do we stay user-centered?

I've got four tips for being user-centered that work for me as a way of remembering at all times how to stay user-centered.


Build relationships with others in the team

It's about building relationships with others in the team. This includes various stakeholders across the org, such as engineering, UX research, design, business partners, and the list goes on.

Depending on the org, you will have different relationships you need to create, but these relationships are important.

Put a face to the people

It helps to put a face to the people, and how the change will impact them. We can even map out the different types of people and stakeholders, and even create persona types if we feel that it's comfortable.

But it helps us to put that face to the people we are going to be impacting with our change.

Foster comfort for best results

Ultimately, if they feel comfortable with us, they will contribute and help. If our relationship is well worked with them, this is a great way to get advocates, they will defend what we're trying to do, and they will help you, they will help contribute to the change.


This is important.

Be open and transparent

Be open and transparent about why you may be doing what you're doing and what you expect from the team. Ambiguity or something that isn't clear can create confusion for the team.

Be clear about the knowns and unknowns

Be clear about what you do and don't know. Often we try and cover-up, "I don't know how this is going to impact", and if the team knows you're unsure of something, they're the best people to help you actually answer those questions.

But they can only do that if they are aware of those doubts you have. If they don't know they can't help you.

Identify the right places and cadence to communicate

Then it's about identifying the right places and cadence to communicate for optimal interaction. Depending on the type of change, the changes and complexity of communications will need to change.

We can't assume that one size fits all and anyone who has tried to implement any change will see that; we'll talk through Slack, we'll do emails, we'll do comms, we'll do a presentation, we'll do a roadshow, a lunch and learn.

There are hundreds of different ways to do it and each one will have different impacts. It will depend on what change we want to do, the different ways to communicate.


Bring others into the process

It's important to bring others into the process and this is probably one of the hardest parts. In some cases, many of us are trying to implement product operations completely by ourselves, or at least that's the way we feel. But it isn't that way. We are not a silo.

We don't go off into a room decide on the solution, then throw it back at the team. If we bring them into the team, they become advocates, they help us to structure it, they also feel like they own it.

Helps adoption. More people have context

It also helps with the adoption because more people have context and so we don't have to explain it to everyone. There are people who help us explain it to others, and sometimes in a better way to their team than we can explain.

Also builds relationships

Again, it's that advocate, and it all connects to the first tip around building those relationships and creating those relationships.

Think about the impact

Consider the impact on the team

I see this as potentially one of the most important tips about being user-centered and where can bring the most value.

Whenever you think about change, don't just focus on the potential for impact for the company in the process. Think about the impact on the team, and the day-to-day. This is important.

How much will it change their world?

If we have a notion of the level of change for them, we can help mitigate uncertainty and discomfort.

Will they ever obtain value from the change?

If not, be clear about that. Don't let them find out the hard way. Because can you imagine how it is if you implement this change, and they think, "Oh, my goodness, this is going to make things so much better" and then they don't ever actually extract any value from it? It will be disheartening for them.

Is it all focused on the product?

Lastly, building on the previous point, is it purely focused on the product? So is it not a change for the team? How will the team perceive that? Will it affect morale or create ambiguity? Be clear about that, prepare for that, it's the best way you can do it.

Remember that they're an important part of the success of the product, those people that are working on the team. These sentiments can influence things such as health, culture, adoption, evolution, retention, even innovation, and the list goes on.

They affect that and they can affect the culture, the environment. Without them, we will never succeed.

Final thoughts

That's why I'm going to leave you with this final message - include the people in your process to really achieve incredible results.

Similar to how good PMs should include customers in their process, we have to include the product, other stakeholders, people in the process, we have to include them for it to get really valuable results.

Don't let your dreams be dreams go out there and be user-centered in your product ops work.