Get the Best of Both Worlds with a Hybrid Team

In the hectic world of tech start-ups, a lot of things related to team structure and internal processes happen…

• By accident
• Out of necessity, or
• In order to meet an immediate need

In the case of our user research team at Lightricks, all of the above pretty much constitutes how the small user research team that I lead was established. Two years in, however, I’ve come to regard my current team structure as a happy accident.

Jump to

• How our team is structured
• The core benefits of an unembedded/hybrid UXR team
• How can you have an impact if you’re on the outside?
• Actionable takeaways (even if you’re on an embedded team)

How our team is structured

I’ll walk you through why our unembedded team—gasp—is what I see as an optimal structure for many organizations and challenge some of the prevailing tropes about UXR teams. You can take home some actionable insights either for rethinking your team’s structure, or just making some simple, minor adjustments to increase your overall impact.

Our small and mighty UXR team at Lightricks is myself (the team lead), along with two other researchers. I report to the VP of Product and we don’t sit on any of the specific product teams which include PMs, designers, and tech leads. All three of us conduct research for all of our products (we have several) and while we work with all of the product stakeholders, we’re a separate entity. Over time, it’s become our superpower.

The core benefits of an unembedded UXR team

Around a year into our team’s existence, a few stakeholders brought up the idea of embedding each of us into a different product team, as opposed to our current structure, where we were on separate teams from the designers and product managers that fuel product development.

I was open-minded and took some time to really reflect on how our structure affected our work in general, and our ability to have an impact. I realized that there were three core benefits to our unembedded team that I wasn’t sure I was ready to forgo.

✔ It’s a smoother path to choosing research initiatives based on impact

At a company of our size (around 600 employees) with multiple products and a modest, three-person research team, we have more requests and potential research initiatives than we can handle. Regardless of team structure, every team needs to prioritize. Since I’m not beholden to any one product, I can choose initiatives based on our UXR team’s overall goal—impact on the product.

For example, at Lightricks, we have three core products. If each of us were embedded on one of those teams, we’d always be doing equal amounts of work on each product. Sounds fair and equitable—but as the team lead, I don’t want to prioritize fairness as much as I want to prioritize potential impact.

It has happened many times that our team is solely working on initiatives on two out of our three core products, simply because those research projects were:

1. Best aligned with the current business goals and/or
2. Had a higher likelihood of resulting in actual action by the product teams

Though not every product team serves multiple products, the same principles can apply to teams that have one product with multiple teams or product managers working on different initiatives. For example, some companies may have a group of product managers and designers working on growth initiatives, whereas another team is working on the core user experience.

Rather than designating one user research to each product or each product initiative, why not reserve prioritization for the research projects that will best align your company’s goals at any point in time and meet your goal of having more impact?

✔ We have less emotional involvement temptation to people-please

There’s no question that part of being a skilled user researcher is the ability to design, execute, and deliver insights with objective, methodologically sound research projects. It’s also true that putting certain safeties in place can help make sure that your team is living up to that standard—and being a team on your own can help.

At Lightricks, we have multiple layers of management and employees that drive our product roadmaps. It happens frequently, like in any healthy and innovative environment, that certain people champion specific initiatives based on their industry knowledge and their overall beliefs about what will help the team meet its goals.

When researchers are embedded in product teams, they’re in all of the meetings where certain things are being evangelized. They're highly entwined with the work being done, and they’re right there to be a part of the blood, sweat, and tears of each initiative.

They’re often reporting to and having their performance evaluated by the people that are behind certain initiatives. Given all of that, you can imagine how complicated it can be to come out with UXR insights that don’t support key initiatives, or that direct product teams (including your direct manager) in the directions that they weren’t planning to go. While I’ve never met a researcher who lacked the integrity to deliver the insights and recommendations that their colleagues don’t want to hear, it happens in subtle ways.

For example, when you’re prioritizing between projects, you may do so with the desire to make specific people happy without realizing. Or, maybe you’re softening your language when you’re presenting results because you’re subconsciously worried about how it will land.

On an unembedded team, we’re certainly engaged in politics and aware of who is championing what internally for the sake of impact—but we’re more removed, and therefore less emotionally invested. This curbs the temptation to people-please, because we have some distance from the personalities and the details.

✔ It’s easier to maintain a standard of rigor when researchers are managed by researchers

Though my direct manager is one of our VP of Products, he’s a high-level manager—he’s not micromanaging the details of our work. As for my direct reports, they’re obviously managed by a fellow researcher. What all of this adds up to is that day-to-day decisions about research are made by myself and my team, all researchers. That allows us to maintain certain standards of rigor.

There is a natural tension that exists between speed and rigor, with stakeholders usually prioritizing speed and researchers left in a tough place. We need to meet the need for speed, but also maintain certain professional standards so that we only put out insights and recommendations that we truly stand behind.

On embedded teams, it can be doubly challenging because you so often have to move to the rhythm of the product team and the final call is usually being made by someone who will choose speed over a minimum standard of rigor. For example, the dreaded, “Let’s just talk to a few users and get an idea rather than doing a whole set of interviews.”

In our case, because we’re first and foremost accountable to each other, we have the space and autonomy to have discussions where we figure out the best balance between rigor and speed. This establishes red lines that protect the integrity of the craft.

How can you have an impact if you’re on the outside?

This is a fair question. It can be difficult to stay informed with what’s going on when you’re not embedded in product teams. It can also be more challenging to follow-up after passing on actionable insights and recommendations. How are you able to make sure that product stakeholders are implementing and/or considering what you think is important from a user perspective?

For our team, these are certainly the main challenges of our unembedded structure. Here’s how I’m mitigating these issues so that we can still reap the benefits of being on our own.

✔ UXR needs to be embedded in processes, not necessarily teams

This was a huge mindset shift for me, and it took me some time to realize that at least for us, this was the best of both extremes when it comes to team structure. In order to have an impact, it wasn’t that we had to be on specific teams—we needed to be included in processes at various stages of the product development cycle.

I mapped out what I felt were the most crucial points for us to be embedded in processes, specifically for our team:

• The idea phase – Where we can help stakeholders understand user perspectives, needs, and motivations and do some competitor-oriented research.
• During the design process – When we can put early prototypes and concepts in front of users while there is still time to iterate before we release something new.
• Post-experiments – When we can explain the why behind testing results so that future iterations will be more likely to move us toward our goals.

Once I’d identified these three core touchpoints, I worked (and continue to work) toward making sure that we’re included in the meetings, Slack channels, and documents at all of these junctures.

For example, I found out that there are internal Slack channels where user behavior metrics are discussed even before official experiment results are released. Once I joined them, I knew where important experiments were headed before they were concluded. That enabled me to sync with the relevant stakeholders, then plan post-experiment research that was ready to go right after the analysts made the final call.

The result of this was that we were faster in delivering insights and recommendations for iterations, making us more agile and useful at this stage of the product life cycle. This was a simple case of figuring out where and when this process was happening, and then showing the value of including us.

Ultimately, what I found was a genuine openness to including us at all of these stages in the product development cycle. The work to be done was a matter of working out the details and logistics. For example, we’re now included much more often when a team is working on something big pre-release so that we can offer insights and iterations on the go.

✔ Relationships are more important than structure

At the core of an embedded team, you have relationships. Relationships include regular touchpoints—and most importantly, trust and reliance. While I was strategizing how to maintain our current structure, I came to realize that I could get most of these benefits by focusing on my relationships with key managers and stakeholders.

I made an actual list of the colleagues that would be most important in making sure that we were embedded in the necessary processes and that we had a voice in various stages in product development. I worked very intentionally toward building more in-depth relationships not only by regular meetings, but also by having deeper conversations and making sure that we were on the same page about what we all gain from strengthening our systematic collaboration.

Actionable takeaways (even if you’re on an embedded team)

Would I be tickled if you made it this far and were rethinking your commitment to an embedded team structure? Yes, I would be. However, even if you’re not thinking of making any sweeping changes, there are actions that you can take even on an embedded team. These decisions can help you reap some of the benefits that being separate has to offer.

✔ Create standards for rigor, define red lines, and align with key stakeholders

Even if you’re reporting to someone who isn’t a researcher, it’s important for you and your team to set minimum standards so that you can feel 100% confident in the user insights that you’re bringing to stakeholders.

Do some brainstorming around the methodologies that you typically use, or different research initiatives that you participate in. Where can you make compromises for the sake of speed? Where can’t you?

After your team has spent some time brainstorming, meet with your manager and then other stakeholders to get on the same page. Make sure to be explanatory about why you’re putting certain standards in place. Consider the whole thing an investment in rigor and an opportunity to build more alignment with your manager and your colleagues.

✔ Assess whether the research team is embedded in the right processes

Even if you’re already on an embedded team, the possibility still exists that you’re not involved in all of the key processes in product development. Being in recurring syncs with product managers and designers is a good start, but it’s important to assess whether you’re truly embedded in their workflows.

Are you doing generative research when the product team is looking for new ideas? Are you a key player in the idea phase when product teams need insights about users? Do product stakeholders assume that they know why certain product iterations succeeded or failed, or do they ask you to help them figure it out?

All of these questions and more can help you figure out if you’re on the right track to what we’re all chasing: increased impact.

✔ Put checks and balances in place to ensure your objectivity

If you’re lucky enough to have other researchers at your organization, consider setting up weekly or bi-weekly meetings where you go over things like how you’re prioritizing your current initiatives, your findings, and your stakeholder presentations. Make it explicit that you’re all looking to check each other’s assumptions and look for any internal influences or biases that could prevent you from doing your best work.

Tip: If you’re a solo researcher, you could ask a colleague outside of the product team to help occasionally. I once had a product marketing manager from our marketing team doing this for me before I hired more researchers and it was surprisingly effective!

…

Team structure for user researchers is widely debated. When I reached a point where I needed to reflect on what truly worked for us, I found that being our own independent team embedded in processes yielded a happy medium, work that I’m proud of, and a team that’s both empowered and internally trusted.