Opening the gates: Addressing concerns about research repositories broadening access to insights
Overview:
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.
Wait, you want to do what with my research?
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.
Understanding researcher concerns in order to find ways to move forward
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:
- Teams will lose context and real connection with people
- My team already knows my work; I’m too busy for this
- Teams will access the wrong insights for their needs
- Teams will draw the wrong conclusion from insights
- Researchers will miss out on opportunities to improve product ideas
- 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:
Concern 1. Teams will lose context and real connection with people
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.
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?
Concern 2. My team already knows my work; I’m too busy for this
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.
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?
Concern 3. Teams will access the wrong insights for their needs
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.
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]
Concern 4. Teams will draw the wrong conclusion from insights
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.)
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?
Concern 5. Researchers will miss out on opportunities to improve product ideas
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.
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?
Concern 6. Teams will deliberately pick insights to fit their existing arguments
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.
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?
Moving toward the center of product planning — by knowing when to get out of the middle
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.
In summary
- 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 on LinkedIn
Sign up for email updates (monthly, at most)
Footnotes:
[1] 2016, Tomer Sharon: “Democratizing UX” https://tsharon.medium.com/democratizing-ux-670b95fbc07f
[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
