Research-Ops is an emerging new discipline that has taken its name with a nod to DevOps and DesignOps.

I was inspired to gather my point of view here for the following reasons:

  • There’s not a lot written on this topic because it is not a ‘thing’ yet.
  • I wanted to spread hope and share the possibilities with the research community who can feel exhausted between budget conversations and/or executing in silos. (Been there-done that).
  • Announce to the leaders who are eager to find new ways to increase customer obsession in their organizations. This is the structural change that can set the behavioral change in motion.

First things first; a hat tip to Kate Towsey who baptized the Research-Ops slack channel and legitimized the need for this capability.

Alright, let’s get started. The definition is shifting sands. So, let me begin with mine and be prepared for a reality check.

Research-Ops is an emerging discipline. The primary goals are to:

  • Operationalize customer research function to reduce inefficiencies and scale across projects via repeatable process with reliable timelines, ready-to-apply methods and templates.
  • Make research more relatable and encourage cross-functional team participation in understanding customers
  • Make research insights more accessible for everyone in the company to easily find, collaborate and integrate the findings in their work

Simply put, it democratizes customer insights, takes down barriers to understand customers, and makes everyone take responsibility for creating remarkable customer experiences.

So what needs to happen? Here’s a progression to consider:

1. Make research a team sport

Researchers / Research managers: A relatively easy starting point as this expands on to what you may already be doing.

The design Process:

I can’t believe I am beginning here. But there is a good chance that your teams may not have an official design process. It is not so much that the process document is a game changer; what is valuable is the co-creation and deliberation that resulted in the shared understanding of how the teams work together.

In the context of Research-Ops, it can serve as a frame of reference to see where the teams can benefit from operationalizing research.

Examine with the team:

  • Do they need better access to insights when they begin grooming?
  • Were usability findings ignored because it was too complex and/or the team not involved?
  • Did teams need something during iteration that they could not access?

Inclusion:

As a researcher, invite your cross-functional teams to join you when conducting the research or analysis. It increases their skin in the game, gives you a reality check for your biases. And imagine that you no longer have to spend your meetings convincing them of customer’s problems but focus on solutions.

Don’t limit cross functional teams to designers, product managers and QAs. Aim for a grander collaboration by inviting people from market research, VOC, customer success, sales and data science teams. The perspective they offer during this process can result in re-framing hypotheses, sharper analyses and richer insights.

Build the habit of Self-service:

Stand up a shared repository for storing research work products. This maintains one source of truth and encourages self-service. When someone requests a report, always send the link.

I used to have the shared repository hyperlink as part of my signature. This serves as a silent cue to others.

Increase the sense of ownership

Establish naming conventions together with the product team and keep it simple. The sense of pride and ownership will creep in faster than you can imagine.

Example: Product.Feature.Version.Research#. Research planv#/screenersv#/formativeorsummative

Facilitate skill expansion:

Have quick start templates for conducting research, usability, competitive research for everyone in the team to feel confident to step up. Gauge their interest and skill level and offer coaching.

Have a slack channel or office hours to answer their questions. What better way to motivate your team and free up the for you to focus on higher order needs?

Communicate to Inspire

Send a newsletter every 2 weeks/monthly. I did not do this actively worrying about adding email noise. But hearing Lindsay talk about her invisionapp newsletter made me think that I should have done better.

Imagine your newsletter to include:

  • A cool customer story in the form of video/image/verbatim.
  • The completed studies and the ROI in terms of opportunities unlocked/risks avoided
  • List of upcoming researches, a short description of goals and the location

Can you conjure up the smiling faces of your team, PMs and directors? Not all at once, but you eventually get there.

Fall in love with the problem:

Similar to design critique sessions, consider meeting to discuss the problems. Focus on the problems, hear from various teams the cascading feature /product impacts. The goal of these meetings are not resolutions but rumination. This provides an opportunity to combine or expand studies.

Seeing is believing

Visualize the research findings, the design process and may be the research calendar in large posters to improve visibility. It sparks conversations from unexpected corners and furthers healthy debates. A BW 24×36 poster can be printed for under $5.

Start the conversation on experience metrics:

“How do we know our feature is successful from a design standpoint?”

A driven designer’s question got me started on product analytics lunch-and-learns. These help move customer research up the value chain to establish experience KPIs and play a strategic role. Let’s instigate new ways to think; Google’s HEART framework is a great place to start.

2. Triangulate customer insights

For this to work, researchers need the middle managers to encourage, make the right connections and clear the roadblocks.

Smart teams understand the value of big and small data. One way to showcase this is to give a makeover to reporting by combining qualitative and quantitative data. The image below is one of my attempts to bring the quantitative metrics(top) and then delve in to qualitative verbatim (bottom) by journey phase.

Customer Insights — What & Why

You can get pretty ambitious and creative here. Remember to frame the findings it in the context of the journey and segment the results for audience to digest the context.

3. Bridge the CX- divide

For this to work, the UX-CX teams need to reach out and the managers to facilitate these conversations.

In my experience, large enterprises house many types of research organizations. From my observations, CX teams typically focus on corporate level journeys, VOC (NPS), Market research, future state mapping. UX teams usually engage at the product/feature level journeys within product teams.

Usually, these teams don’t know the other exists and/or there’s tension to acknowledge. There is so much room to reuse and amplify each other’s work.

Here’s the Forrester report on this topic from 2015 that I have leveraged to make progress. For starters, just begin a cadence of meetings to get to know each other, check-in with one another when you begin a research effort. Share research plans and deliverables. Stop reinventing and make time to invent.

Don’t get hung up on the semantics. You know to do the right thing!

4. See the Forest and the trees

For this to work, we need the buy-in of the top level leaders as these changes are not limited to budget but team expansions and organization designs.

This also requires a mature organization and committed leadership to appreciate and invest right. The dividends will be commensurate with investments, manifesting as high performing teams and an innovating culture.

This is about establishing research dedicated to problem space and solution spaces. Indi Young legitimized this discussion and her illustration is given below:

Simply put,

Problem space refers to exploratory research that defines the problem. The questions are broad and usually aligned to company’s customer promises for the fiscal year.

E.g. What does personalization mean to our customers? Or something like, We need to improve the to candidate experience.

Solution space is about the space after a problem is defined. This is aligned to the specific product /portfolio priorities. (Ideally, they do have a dotted relationship with corporate themes)

E.g Reducing abandonment in the check-out flow or Making I easier for customers to discover products

When this becomes a well-oiled machine, the backlog from the problem space will serve as your innovation pipeline and inform your roadmap for the next year. The solution space teams with be focused on building intuitive experiences.

In some organizations, the CX teams work on the problem spaces. then again there is no disciplined socialization with the UX team. The UX teams are also poised to run their own problem and solution space research depending on the scope of the portfolio. To learn more, check out Marty Cagan’s, continuous discovery.

Overwhelmed? Take a breath. Even if you are a research-team-of-one, getting more deliberate about some of these will bring renewed purpose to your everyday. It is time to level up!

“Getting started is more important than being right”. You will get there and there’s help 😊

I wholeheartedly welcome your feedback and inputs. While my perspective stems from my first-hand experience, I know it can use some debate, discussion and refinement. Thank you for spending your time here!





Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here