Opening the gates: Addressing concerns about research repositories broadening access to insights | by Jake Burghardt | researchops-community

Many research teams are focused on enhancing how they organize their insights — but some end up effectively creating repositories just for themselves, hidden through access security or intranet obscurity. This gatekeeping reduces research impact within organizations, leading to waste. Internal research communities can come together to air their concerns, kicking off efforts to define shared approaches for expanding the access and visibility of their collective work. This article includes some common concerns about ‘opening the gates,’ along with some prompts to drive community discussion on how to mitigate those concerns. It’s time to move research toward the center of product planning across complex organizations — by knowing when to step out of the middle of research use.

So, we all agree that making research more findable in a repository is a good thing? Making more of our insights by getting them in some sort of searchable tool seems to be one of the things that up-to-date researchers are supposed to do now, right?

But, hold on: Let’s just keep our new repository for us researchers, okay? Maybe we can open it up to others later, after we’ve got all the bugs worked out?

Does this nervousness sound familiar? Maybe you’ve heard something along these lines in your research teams — or even said something similar yourself? I’ve found that it crops up a surprising amount when chatting with folks in tech who are interested in improving research knowledge management and insight follow through.

Enabling broad access to insights within an organization — sometimes referred to as ‘democratizing’ [1] — triggers some researchers in an existential way. You see their body language change when you talk about expanding the availability of their insights to whole communities of product managers, designers, engineers, marketers, and other leaders.

Starting with a pilot project can help relieve some of these concerns. Kicking off small, both in terms of repository scope and audience, is a solid approach. It leaves room for iterative learning and thoughtful growth, while limiting painful rework .

But, in some cases, after the initial ‘repository pilot for the research team only,’ the next step of scaling up the user population doesn’t actually happen. Either by design or through a lack of effective estimation and prioritization, teams prematurely move their focus to other initiatives. The barrier remains up around their insights prize. And, as a result of limited access, fewer research-based improvements are prioritized for the people an organization is striving to serve.

It doesn’t have to be this way. But it’s important to call out that broadening the access and visibility of research is not a topic to bulldoze through either.

Making the time for a community-based design process can build shared confidence around opening the gates, setting sights on new levels of shared research impact. A design process grounded in real concerns that are blocking broader access, as well as a clear-eyed discussion of data governance, expiration, and ethics.

And that kind of design process begins by doing one of the things that researchers do best: observing, eliciting, and collaboratively articulating needs. It begins by turning those skills inward.

Many researchers have a tendency to act as gatekeepers to their prior work. Sometimes folks have declared reasons for deliberately barring the gates. These reasons can be given a second look given current context and intentions. Other gatekeeping is less overt and more implicit. It takes the form of limiting effort spent on knowledge management, research marketing, and insight activation, in favor of moving on to the next round of data collection.

Depending on the size of your research community — and which disciplines you actively include in your community identity — you may have many individual research gatekeepers, each with their own reasons for standing guard.

However, if you start talking to researchers to get a feel for their reasons for gatekeeping insights, you will likely discover a set of common concerns, voiced slightly differently by individual practitioners.

And if you bring these professionals together to talk about their concerns — as well as their aspirations to influence planning — you’ll likely find that research colleagues will innately see commonalities and start generating ideas for moving forward.

With the goal of aiding in these conversations, the remainder of this article focuses on a typology of six common concerns beyond conventional research data governance:

  1. Teams will lose context and real connection with people
  2. My team already knows my work; I’m too busy for this
  3. Teams will access the wrong insights for their needs
  4. Teams will draw the wrong conclusion from insights
  5. Researchers will miss out on opportunities to improve product ideas
  6. Teams will deliberately pick insights to fit their existing arguments

I’m not putting this typology forward as the definitive map of researchers’ fears about increased access and visibility of their work, but it’s a starting point. And I hope that you find the related ideation questions, below, to be useful conversation starters for addressing particular concerns.

It’s worth calling out that some concerns may not be addressable in a way that meets the needs of everyone in your research community. For example, it simply may not make sense to broaden access to certain content given specific research participation agreements, levels of personally identifiable information, market segments, highly confidential audiences, types of research work products, etc.

The gates to all research work products are never thrown completely open, nor should they be. However, it’s important not to let particular needs for limited access set off an alarm that slams shut the rest of a research community’s insight gold. There’s usually room for multiple approaches.

And with that, here’s the first of the six concerns:

Some researchers in your internal community may focus on the context that’s lost when teams access individual ‘pieces’ of research in a repository. Empathy for people can suffer when teams connect with research that has been reduced to a set of self-service search results, rather than taking part in research projects in real time. Important connections among studies can go missing in lists of atomic ‘nuggets.’ The meaningful grain of the holistic experience can disappear when folks only find subsets of the particulars.

As with several of the concerns in this article, this driver of gatekeeping tends to lean on an ‘either/or’ rather than a ‘multiple approaches’ mindset.

Concerned Researcher’s text message: “Won’t a repository distance our stakeholders from the big picture? And won’t it also dissuade them from getting involved in research projects?” Research Operations Leader’s response: “I hear you. I believe we can use our repository program to push a clearer big picture from across our collected research. And we can turn every touchpoint with the repository into an opportunity to promote ‘real time’ involvement and other new norms.”

Repository programs can drive more connections and conversations around research. And your research community can decide what to emphasize in each of those interactions.

Some prompts to ideate new Research Operations possibilities:

  • How might we use our repository to turn every research project into a sort of meta analysis of compiled learning?
  • How might we establish metadata pathways that allow insight seekers to zoom out from granular information in our repository to larger, context-setting views?
  • How might we incorporate messages about upcoming opportunities for product teams to participate in research projects, marketing in our repository and its communications?
  • How might we grow a common description in our repository for the ‘nutrition facts’ of studies, characterizing research in a way that builds literacy while highlighting the methods that we want to emphasize?
  • How might we push new feeds of customer stories from our repository in order to keep product people connected with the people they want to serve?

Some researchers are entirely focused on their assigned team ‘clients.’ They worry that broadening access to their work will lead to unnecessary headaches. These researchers may see value in increasing the internal accessibility of existing research in order to better serve ‘their team,’ but they may not understand how their work could drive valuable planning in other product teams.

Concerned Researcher’s text message: “Won’t a repository just create noise? I don’t expect other teams to get the research that I do for my own team, and I’m not sure why they would want to?” Research Operations Leader’s response: “It turns out that there are teams across our organization who don’t have a researcher, and they would get a lot of value from your insights. It’s value that’s hard to picture until we pilot it. It could dramatically increase the impact of your work.”

Repository programs can connect existing research work streams to siloed product teams. They can link together related evidence for an insight from multiple projects and researchers. And they can then make the resulting wins into a visible currency, elevating your entire research community.

Some prompts to ideate new Research Operations possibilities:

  • How might we get started identifying insights that could be used by more product teams, and experiment with ‘routing’ that research out of our repository, in order to grow insights’ organizational ‘impact radius’?
  • How might we extend the timelines of research projects to reconnect with stakeholders on insights, using our repository to drive recurring ‘echo’ read outs and activation efforts, promoting reengagement and accountability?
  • How might we use our repository as an opportunity to up-level selected insights into more durable forms that will be more applicable across teams?
  • How might we track impact reach in our repository and amplify wins where research from one team was routed to another and led to unforeseen ‘bonus’ impact?
  • How might we connect dots across various research teams’ roadmaps, making time to find commonalities in order to promote collective efficiencies and develop richer, multi-faceted insights in our repository?

Another area of concern that you may hear from your research community is around insight seekers not finding the ‘right’ insights that they really need within a repository’s contents, leading to less optimal outcomes. Most product people accessing a repository do not arrive with a holistic mental model of the breadth of available insights that they could tap into. And they may not be willing to invest in figuring out repository tooling, jumping to conclusions from the content they happen to discover from a cursory look around.

Concerned Researcher’s text message: “Won’t a repository make it too easy for people to find research that doesn’t really apply to them? How is that good for us?” Research Operations Leader’s response: “It’s true: we can’t stop at a search box. We’ll need to build our repository for findability of crucial topics. And research operations staff will also need to run programs to train, report, and collaborate differently with a range of product teams.”

Repository programs can grow a toolset and operations that ground the right insights into product teams’ own work practices. Going further, these programs can actively introduce product people to insight tools and keep them connected to important insights at key junctures in their own work.

Some prompts to ideate new Research Operations possibilities:

  • How might we establish repository ‘locations’ that have a natural mapping for product people, as close as possible to product practice?
  • How might we grow and surface our repository metadata to improve access to related clusters of insights, balancing product teams’ mental models with researcher-advocated point of view?
  • How might we train product people on how to find and apply existing research in our repository, immersing them in key learning for their own initiatives?
  • How might we provide services around mapping insights to product teams’ existing backlog items — as well as gaps and unmet needs in their roadmaps — in order to ensure that teams are applying appropriate research?
  • How might we push recurring, cross-study reporting from our repository to the right product teams — instead of relying on them to find the right research on their own? [2]

Even when stakeholders find the ‘right’ insights for their needs, they may come to conclusions that researchers had not intended. It’s a given that the words and artifacts of a research project don’t capture everything. There’s always some margin of problematic ambiguity. And some researchers feel ashamed that they don’t have more time to document their findings as clearly as they would like. (I’ve certainly been there.)

Concerned Researcher’s text message: “Won’t a repository increase the likelihood that product teams act on insights the wrong way? If there’s not a researcher there, won’t they do the wrong thing?” Research Operations Leader’s response: “Good point. We can choose how to capture insights in our repository so that self-service access leads to the outcomes we want to see. And we can make how our research is being used more visible, so that we can inspect the conclusions that teams make on their ow

Repository programs can establish standards for constantly connecting insights with their related proposals and actions. These programs can also enable new types of insight follow through, leadership opportunities for researchers, and impact traceability.

Some prompts to ideate new Research Operations possibilities:

  • How might we capture our experiment ideas and design solutions in our repository, closely linked to related insights?
  • How might we provide metrics and visibility to researchers so that they can understand who is accessing their work in our repository, allowing them to follow up if they so choose?
  • How might we establish standards for referencing repository contents as part of product teams’ own work products, so that everyone can see where specific insights are being used? [3]
  • How might we use our repository to grow language and norms aimed at clarifying ‘research-based’ versus ‘research-informed’ product judgements?
  • How might we drive new product design guidelines and systems from our repository, establishing standards for redesigns and future launches?

Another area of concern, related to teams drawing erroneous conclusions from insights, stems from the ordinary desire that many researchers have to be more involved in product conversations: the fear of being left out. These researchers may see a broadly accessible, searchable repository as a barrier to them getting looped into the working sessions and communication threads where they might suggest new directions.

Concerned Researcher’s text message: “Won’t a repository cut us researchers out of important design conversations? After all, we want to help make ideas even better based on what we’ve learned.” Research Operations Leader’s response: “Let’s keep you looped in. We can design our repository to make your contact info integral to your insights. And our repository programs will not be passive — we will work to connect you and your insights to the product teams and leaders that you want to impact.”

Repository programs can generate new kinds of involvement across product teams, ranging from active researcher time in core conversations to recurring connections that are managed by Research Operations staff.

Some prompts to ideate new Research Operations possibilities:

  • How might our repository promote contacting the researcher, team, or larger community that generated particular insights?
  • How might we regularly connect with product teams about their feature new ideas in order to apply existing research, whether directly related or analogous?
  • How might we establish more consistent processes for integrating research from our repository into product teams’ own backlog capture and prioritization practices?
  • How might our research teams consistently convene product conversations to ensure that crucial insights and research staff are more integral to ideation and prioritization?
  • How might we spotlight unbuilt, high-value feature ideas and improvements from our repository so that these ideas remain part of ongoing planning conversations?

Last in our list of common concerns about broadening insight access and visibility is a fear that I’ve typically heard from more seasoned researchers. These researchers have been burned by their insights being misused by someone looking for any possible evidence to support a bad product idea. Not the wrong conclusion on accident, but deliberate misuse. Research appeared to ‘back up’ a direction that led to poor user experience — and the research author found it beyond excruciating. Opening up the gates to research in a repository tool could lead to more of these painful cases. There’s nothing wrong with supporting an existing feature idea when it’s something people actually need. But all researchers want to see more new directions actually initiated from research — to see the cart placed squarely before the horse.

Concerned Researcher’s text message: “Won’t a repository just make it easier for anyone who’s looking for any possible scrap of evidence — whether it applies or not — to justify what they want to do?” Research Operations Leader’s response: “I know that’s hard to deal with. But think of all of the positive cases of research usage that we will be scaling up across the organization. We can amplify what we want to see and work to minimize negative uses, which would likely happen in some form regard

Repository programs can push a strong perspective on what matters most from research. At the same time, program staff can react to emergent uses of insights, both positive and cringeworthy.

Some prompts to ideate new Research Operations possibilities:

  • How might we build new norms by consistently celebrating when product teams start with research as the basis of generating new product ideas, rather than propping up their preconceived ideas with existing research?
  • How might we establish escalation paths for cases where insights are being applied in ways that are not valid?
  • How might we drive visibility of top customer problems to solve so that leadership is aware of research’s collective point of view on what’s most important to tackle next?
  • How might we activate our repository by pitching aggregated research at times when teams are actually thinking big about product strategy?
  • How might we use our repository to call out cases where product audiences have conflicting needs, or cases where research uncovers violations to our organizations’ values?

Look into the root causes of many of these concerns, and you’ll find researchers’ desire to be intrinsically tied to their own outputs. We want to be deeply connected to the flows of information that we generate. Totally understandable. It makes sense. And it’s worthwhile to acknowledge that it’s ideal for researchers to be deeply involved in product teams’ processes.

However, researchers in growing organizations often find that their own involvement doesn’t scale across all the places where their research could be valuably used. There’s simply not enough hours in the day, and product decisions may occur months or even years after related research projects.

Comparing the ratio of insight-generating folks to other roles in an org chart can make problems of scale more apparent, highlighting the lakes of influence in certain product teams and the oceans of untapped potential in other silos.

Centralizing research insights in a repository is an opportunity to expand how research activation works, both in high-touch and self-service scenarios. Building on current collaborations, researchers’ can deepen their contributions to a prioritized set of product teams. At the same time, repository programs can drive broader, organization-wide engagement with core knowledge areas.

And let me close with the idea that broader visibility of research outputs represents a massive opportunity to shift perceptions of research within your organization.

A carefully branded repository program can become a ‘club’ that people want to join. New ‘members’ can include both new research contributors from different disciplines, as well as insight-seekers wanting to go after real and important customer problems.

And this growth in ‘membership’ can elevate the role of research from a ‘production line’ or ‘client service’ mindset [4] toward a situation where researchers and their insights are even more integral to product strategy and road mapping. A situation where more great things are getting done for the people that your organization is striving to serve.

  • Even though many researchers in tech are wanting to enact the ‘best practice’ of a research repository, they may have very different motivations for doing so. Many researchers want to focus on findability of insights for themselves and have real concerns about making their insights more broadly accessible.
  • Researchers’ professional self worth can be tied to their deliverables, and bulldozing a point of view about reducing gatekeeping will likely backfire. Instead, make space to air out concerns and facilitate a deeper discussion of research ethics, governance, insight expiration [5], and other concerns. Consider a more consensus-focused design process within your research community, aimed at building shared confidence toward opening gates and new levels of shared research impact.
  • Individual researchers’ concerns about broadening access to their work are often not unique. Beyond essential research governance factors, concerns fall along some common fault lines, and there are research operations possibilities that can ease these concerns.
  • While it’s ideal if researchers are deeply embedded in each product teams’ decision making, this model doesn’t scale in growing organizations. Researchers can shift perceptions within their organizations by deepening engagement with key product teams using aggregated learning, while at the same time pushing mechanisms for broader self-service to vital insights.

If you’ve read this far, please don’t be a stranger. I’m very curious to hear about your challenges and approaches for coming to community consensus about opening your teams’ gates. Thank you!

Connect: LinkedIn | Medium

— — — — — — — — — — — —


[1] 2016, Tomer Sharon: “Democratizing UX”

[2] The ability to push reports from filtered sets of repository content is an area of system requirements that I’m not seeing get enough air time. Creating a destination for insights is great, but being able to create on-the-fly reports from metadata structures can be a game changer in many scenarios in the planning process. Some basic automation could be transformational. In this Research Repository Tool Requirements Comparison, related cases are captured as “Ability to create reports, research summaries within the tool” and “Notification center and ability to follow new insights generated”

[3] Referenceability is another area of research repository requirements that I’m not seeing get enough air time. Being able to link to research is a primary enabler for better integrating into planning. Not just sharing out exports, but linking back into the repository in a granular way.

[4] For more thoughts on the distinction between “production line,” “client service,” and “integral planner,” see earlier post:
Aiming for integrated research, not just a research repository tool

[5] For more thoughts on insight expiration, see earlier post:
Extending insight ‘shelf life’ to get more value from research in product planning

Read the full article here

Leave a Reply

Your email address will not be published.

Design inspiration: trendy illustrations in UI

Design inspiration: trendy illustrations in UI

Check out how designers use illustrations in mobile and web interfaces and get a

Powerful Panel Management and Recruitment Automation for Teams That do Research at Scale

Powerful Panel Management and Recruitment Automation for Teams That do Research at Scale

Table of Contents Hide The evolution of Research Hub The evolution of an

You May Also Like