What do a necklace, a bowl of salad, and a compass have in common?

They are all metaphors that product managers at Dashlane use to describe their role. The insight they revealed, among others, helped me shape what Dashlane’s first-ever product operations role should look like.

Product operations is a relatively new concept for most companies today. However, operations roles for product design and user research have been gaining traction over the past few years. Each product operations practitioner has their own path to the role. This is mine, and what I was able to bring from my experience in research to this space of growing importance in the product ecosystem.

It all started with anthropology

I had an early calling to anthropology in middle school. After pursuing it all the way to graduate school, I saw it more as a mindset than a discipline. Anthropology is a way of appreciating the interconnections between people and concepts and recognizing the importance of questioning everything from business norms and buzzwords. I began to apply this approach as a researcher in the social and public sector, using ethnographic methods to surface blockers and potential solutions. I also performed effective public service delivery and international development programming.

Soon enough, I realized that a lot of the work I was doing behind the scenes — improving on our research process and ensuring research is conducted as effectively and ethically as possible — was essentially research operations.  Realising this, I dove headfirst into a full-time research operations role at Dashlane as a leading password manager. This is what I was most passionate about doing.

It became clear that the problems where the research operations role was meant to solve went beyond research processes. The reason why we weren’t being as customer-centred or data-driven as we would have liked stemmed less from an ineffective research process. It came more from a lack of consistency and collaboration in our product development process.

The plan was made to expand the scope of my role from research operations into product operations. However, since Dashlane nor I had ever had such a role before, how do we begin to define it?

Treat the process as a product

Given my background as a researcher, my first instinct was to take note of the observations I have made so far about what takes to build a successful product. Two insights stuck out to me.

First, understanding user needs are critical to meet demand and ensure our product gets used and loved. It’s not just about understanding these needs, but learning how to prioritize them, and doing that analysis across different data points.

But what good is understanding users’ needs if we can’t align around shared goals? I learned early on that siloes can only limit us. We need to find ways to collaborate effectively to build a product users will love.

When I reflected on these two points, I realized they are just as important to follow in defining product operations. In many ways, a product ops team functions as a miniature product team — the product process is my product, and the product team are my users. Therefore, my success in product ops hinges on my ability to understand the needs of my users, the product team, and align around shared goals for the improvement of my product — the product development process.

I’d like to share what I did next in the form of five lessons I learned from user research.

Lesson 1: Anything can be data, but only if you analyze it

Through anthropology, I learned that you can extract a deeper understanding of human behaviour in everyday interactions. However, the time it took for me to analyze those everyday interactions is what created a set of actionable insights that we could act upon.

It’s a common misconception among non-researchers that the most time-intensive part of the research is collecting data. You should actually be dedicating more of your time to look at data and find creative ways to analyze it.

In product ops, you can use this lesson by treating your notes from conversations with colleagues as qualitative data. Doing so can give you a sense of what the issues are with the product process.

In my role, I have intentionally carved out analysis time after critical conversations and meetings to ensure these notes don’t end up in data purgatory, but rather get pulled into valuable insights. I make this easier for myself by having an analysis framework I created early on. I tend to build on this and evolve it as I see new patterns in our company practices.

Lesson 2: Check your bias

The second lesson I took with me from user research to product ops is to check your bias. In user research, I followed the rule that a well-defined problem shouldn’t presuppose a solution. By defining a problem in that way, I could ensure I was being truly attentive to user needs, and not bringing in my own bias for what I think we should do.

In anthropology, there is this concept of interpretivism. We all interpret things differently, and when you analyze something, you need to check that you aren’t just representing one person’s interpretation of events. It’s important to test the validity of your interpretation by bringing in a few other perspectives.

The way I apply this in product ops is by inviting particular people in my product team to help me look at some of my initial notes. They do a deeper analysis together with them so that they hold me accountable. Often this also allows me to surface solutions I wouldn’t have thought of otherwise. Of course, surfacing those unexpected solutions requires that I frame my problem in the first place in a way that opens it up to more than just my solution.

Lesson 3: Engage stakeholders

This is a good segue into the next lesson, which is to engage your stakeholders. In user research, we struggled to have our insights feel actionable and get integrated into how our product team made decisions. Inviting people along for the process of collecting data, analyzing it, and proposing solutions helped to solve this problem.

Product ops can seem like a lonely role, but I see it as a team effort. I try to engage my stakeholders so that they are just as invested as I am in finding and implementing a solution to problems in our product development process.

Lesson 4: Practice empathy

A fourth critical lesson I’ve learned from user research is to practice empathy. Empathy, to me, is to withhold your assumptions and judgment when interacting with others. Make an effort to understand the other person, and put yourself in their shoes. Empathy helps quickly build rapport so that users trust you and want to share their honest thoughts and feelings about the product in interviews.

In product ops, I try to use empathy to similarly build trust with others, as strong relationships are critical to deliver on my product operations responsibilities. For example, if I’m struggling to reach alignment or understanding with a colleague who contradicts my opinion, empathy helps me navigate away from the conflict. It prompts me to convert my statements and retorts into questions about how and why my colleague feels differently than I do.

Lesson 5: Build learning into your roadmap

Finally, it’s important to adopt a model of continuous learning. In user research, we didn’t just plan one research project after another, but we considered the meaning of continuous learning and the importance of building on what we have learned from previous research.

This is trickier when research is not your full-time job. So I have tried to apply this lesson in product ops by:

• Establishing a cadence for researching users: In the last weeks of a quarter, I have interviews with all the product managers and a select group of stakeholders to help inform my product operations goals for the next quarter and keep me in tune with their needs.
• Continually adding to data and analysis: That framework I mentioned? It’s a living document, which I continually add to and build out as I have new interesting conversations and observations that can give me a sense of where I can deliver value.
• Planning to iterate on solutions: I take a phased approach to my product ops initiatives and gather feedback where I can so that I am constantly iterating and building on what I learned.

“I have no special talents, I am only passionately curious.” – Albert Einstein

This is one of my favourite quotes; it encompasses the anthropological mindset of questioning norms and biases and appreciating interconnections. How we go about practising passionate curiosity in our product teams has been captured in the five lessons above: analyzing what we learn, checking our bias, engaging stakeholders with empathy, and continuously learning. I believe that if product operations professionals and product teams adopt an attitude of passionate curiosity, and these lessons, our companies will only be better for it.

Discover more content on User Research.