How can you transition from a background in UX design to product ops?
Hugo Froes, Product Operations Lead at OLX Motors Europe, then Product Ops Lead at Farfetch, talked us through how he transitioned from these roles, dived into what he found valuable and how this shaped his focus in product operations.
Hugo has a wealth of knowledge, experience, and advice to share on navigating the product ops function. Here we’ve got the highlights from the Q&A, but if you want to listen to the whole thing, simply click below and enjoy all the insights. 👇
Q: What does product ops look like at Farfetch?
A: Our team sits inside Consumer Product, all the work that’s done for users and customers. We report directly into the VP of Product in Consumer Product and we're overlooking all the teams within that like product engineering and design.
We have another two main areas, one is around Biz Ops and the other is around the platform (dealing with a lot of our external partners). There’s product ops in those areas as well, and we connect amongst ourselves. We like to think of ourselves as the Global Product ops team, but then we each have different approaches in each of the business units.
We have three main focuses that shape the work we do within our area:
- The practices of the team: how does the team work as a whole?
- Productive efficiency: how to make the product more efficient.
- Raising capabilities of the team: support learning and development of the team as a whole (training, onboarding and recruitment).
There's a whole bunch of things we're working on and there's almost nothing we couldn't pick up on but we have to, obviously, keep control of what we're working on so that we don't lose track of the work.
Q: How did you end up getting into product ops?
A: I almost sort of fell into it. When I joined Farfetch, I focused on UX service design and building capabilities of designers and design ops so I joined the team to be the practice team inside design in Consumer Product.
Then, we started getting pulled into some of the product conversations as the year went on and it makes more sense for us to be more product ops because we can create more impact there. We were touching on so many things that had to do with product rather than design.
It was a natural and organic transition. Our new VP of Product agreed with the idea and we were inserted in the product strategy and operations team.
Q: The six-month mark is usually a good time to pause and re-evaluate, have you reached that point yet?
A: We do this almost every six months. We're analyzing what the next step of our team is because we're spread a bit thin right now. We don't have enough hands, but we don't want to grow just to grow, we want to be sure that it's something that makes sense.
We’re looking at our goals for the next few years, our structure, and how it should evolve. We've got two tracks as well: the technical track and the single contributor track. There’s also the management track so all of that opens up a world of possibilities.
Q: What is design ops?
A: Design ops is somewhat similar to every other ops. The difference is usually the frameworks you're building up and the way you're going to deal with people.
When we’re working with the design team, we’re looking at building team capabilities such as recruitment, hiring, onboarding, training, building frameworks to work better, looking at processes, rituals and interactions, and seeing what's working and what's not. Essentially, it's helping the team grow.
Sometimes in Design Ops you can have conversations much more easily. We're talking about ideation, empathy or research in that team, as opposed to if you're talking to the product team, maybe they're thinking more about business or strategy. It doesn't have to be necessarily that way but we did notice that the personalities are almost completely different when we change between the two teams (product and design).
Q: What skills do you use from design that serve you well in product ops?
A: I use almost all of them constantly.
One of the main things we take from design is strong research into everything we do. Decisions aren't made lightly. We try to figure out what is the reality of how things are working and the ‘why’ behind it before looking into potential solutions.
We also look at the impact it will have on the team so having empathy is also essential. If I've bombard the team with too many changes, it's going to be overwhelming for them and they won't be able to do it, whereas if I break it down into smaller workable parts and make them feel like they're owners of certain parts of it, it feels more comfortable for them.
Another one would be to simplify complexity. We start mapping out things that already exist, and change them into a simple diagram that people can look at instead of a huge piece of documentation.
The last one is around pattern matching. Looking at how different patterns arise, or different structures, you start understanding that there are different types of PMs, directors, leaders, and teams, and trying to figure out how they all connect as well and bringing up those patterns is fascinating. By playing it back to them, they’re doing their own brainstorming and they also almost don't mind bringing us into more conversations because they feel that we're not there to judge them.
Q: Was there a big project that was quite impactful where you leveraged your design skills in your product ops role?
A: We did an analysis of the product teams at the end of the year and when we came out of it, one of the things we wanted to do was to lay down what were the ways of working and understanding the teams.
One of the things we came out of it after analyzing and breaking it down, connecting the patterns or making sense of the information, was a product maturity matrix. We came up with a beta to the CIC framework to measure the maturity of the product team as a starting point to have further discussions. Then we brought in other people to also give their feedback and input and pulled up on that.
Anyone in our role wants to understand the maturity of the teams because by doing that, we can then understand what needs to move up and what needs to move down. Wardley maps are an interesting way to map out different parts of your team or of your organization and then look at which are different maturity levels. In the end, it helps you analyze or make that analysis of the teams or the structures or processes and it can be used for basically anything.
Q: What are you enjoying most about this role now in product ops, compared to what you were doing in design?
A: We have more impact on the whole product team and on the whole business unit. You're working with them to help build or structure for product to be stronger and you help shape the way they work. You can focus on the people in a team and understand their frustrations and needs.
At the end of the day, it's challenging and new for me. After 20+ years of working professionally, it's always great to expand the way we look at things. I'm reading books I've never read before, I'm exploring areas or ways of working I've never explored before. Every day is different and there's so much variety in what you're doing.
We actually have an incredible team that’s super open. We're always talking. Our Slack is so active and we always have exactly the same amount of context as everyone else, which is incredible. It's something we try to pass on to the other teams and we started trying to implement in the product team.
Q: What are the challenges you're facing in product ops?
A: There are established processes and to change those things at a huge company and organization level can be quite difficult sometimes. If you're not seeing the immediate value of the solution you're proposing, then that's going to be difficult with buy-in.
You might have a great solution but people won't adopt it just because of the investment they've had in the old process and the potential learning curve that will come with the new process.
We’re dealing with people and sometimes we feel like a therapist but if you're somebody who's almost like a sponge, it can become quite overwhelming with the number of things you've got to keep track of.
On the team level or the head level, the way you communicate and the facts that you're putting forward are so different and you have to be able to switch between the different areas which is definitely a challenge.
Q: What tools or resources have you found most helpful in navigating product ops?
A: I found product conferences and the Product-led Alliance are doing some great stuff.
I suggest John Cutler as a person to follow on social media. He's always posting about product, development and practices.
I've been reading a lot about product change management and software development processes. A book I loved reading was Switch by the Heath brothers, about how small change can affect big change so quick wins that can actually have a big impact.
In our team we’re always exchanging content, pushing and challenging each other to learn more. If one of us does a course, we do a write-up and we share it with our colleagues.
Lastly, I think it's important to be connected to the community.
Q: What advice do you have for other designers or people from non-traditional backgrounds who want to get into product ops?
A: For anyone who hasn't done that before, you have to get to know and understand product development. If you're not in product development and never worked in that process, you will feel lost in product Ops.
Understanding processes like Agile, Scrum, Lean, and even design sprints, and how they can be impacted.
This is often overlooked but I would recommend looking at engineering processes and jargon. Even though we're working with the product team, we have to know how the engineering team connects to them because product overlooks a lot of these teams. Product managers are dealing with designers, engineering, analytics, data, and all these different teams so we have to understand how they connect to these teams and reduce friction or barriers between teams.
Understanding the importance of balancing business strategy and customer needs is another one.
Another one is learning how to remove yourself from the ‘what’ and focus on the ‘how’. You're not going to be working on what we built as a company at the beginning but looking at how we build it.
Then, read up on organizational change and how to manage it.
Coach and guide rather than command. It's very easy for us to think about a new process or new framework and say “Guess what this is going to be implemented, just do it”. That won't work. People will fight against it, there will be conflict and it will complicate the actual implementation. We have to help guide them and coach them.
The last one is to be prepared to fail and learn. We're doing that constantly, every single day, even from meeting to meeting or conversation to conversation.
