The keys to democratizing research responsibly: guidance, guardrails, and oversight

Research democratization is controversial. Some companies and research teams embrace it as a way to effectively scale their practice and encourage customer centricity. Some teams think of it as a sub-optimal compromise, but necessary to get research done with constrained research headcount. Some researchers are vehemently, ideologically opposed.

I have developed successful democratization programs at both Dropbox and Airtable. The research teams at both companies were mid-sized (20–30), well-respected within the organization, and well-funded. I had full support for thoughtful democratization from research leadership and the research teams. And our cross-functional partners were generally very appreciative of the support and opportunity to conduct quality research.

A robust democratization program provides access to some of the tools and processes of research. But more importantly, it provides guidance, guardrails, and oversight.

• Guidance is available on the basic principles of evaluative research, in the form of concise, relevant education, along with templates and examples.
• There are guardrails in place, governing what types of research partners can undertake, who they can talk to, and ensuring a positive, ethical experience that protects the privacy of participants.
• And there is significant oversight from a professional researcher, such that no study is launched without sign off from a qualified researcher.
• (To learn more about how to design a rigorous democratization program, read my article Scaling evaluative research at Dropbox.)

Those that are opposed to democratization tend to offer up a consistent set of objections. In most cases, I completely agree with their concerns, but I differ from them in how I define democratization. Detractors often imagine democratization as research anarchy, with anyone in the company talking to any user for any reason, drawing misguided conclusions, and then saying that their conclusions are backed by research. This would surely be a disaster, and this is not at all what I mean when I talk about democratization. When I talk about democratization, I’m talking about an intentional, robust program providing guidance, guardrails, and oversight.

So let’s look at five of the common arguments against democratization, and think about how these very real risks can be mitigated with an intentional, and well-resourced democratization program.

I spent years studying the craft of research and earning my PHD. A product manager or designer can’t possibly do it as well as I could

No, they can’t! And that’s why a democratization program should be very specific about what kinds of research it will and will not support.

If you are an experienced researcher with an advanced degree, then you should be focused on the strategic research projects that will help your company identify new markets, deeply understand your customers, uncover and solve new user problems, etc. You should not spend all your time on tactical usability studies, helping designers confirm whether an affordance is best served by a dropdown menu or a set of radio buttons.

Tactical evaluative research is the sweet spot for democratization. Every new feature should at least go through basic usability testing before launch. If you don’t want to spend your PHD-qualified time doing usability studies, they either won’t get done at all, or worse: a designer will do a “hallway study”, relying on feedback from your tech-immersed colleagues to determine whether an average user can effectively use your new feature.

But if you have a robust democratization program in place, offering guidance, guardrails, and oversight, then your partners can safely and effectively answer those tactical questions through studies that they execute on their own, with guidance and oversight from a researcher. Meanwhile, the professional researchers on your team can focus their time on answering the bigger questions that will drive your company forward.

If we let our partners do their own research, they will only validate their own existing ideas and biases

Yes, that’s exactly what they will do! …if they don’t have your help.

Product Managers are going to talk to customers whether you help them do it or not. And they should be talking to customers on their own. There can be real value in these direct customer connections. They can help PMs develop customer empathy, visualize first-hand how their products are actually used, generate product ideas, and expose them to customer problems… to a point.

Are these customer conversations a replacement for rigorous research? They absolutely are not. Do PMs understand the difference? Most of them do not, and that’s precisely why your professional research team needs to be involved.

Help your partners understand what rigorous research looks like. Help them understand that without proper sampling, representative participants, professionally crafted questions, etc., any data they gather is just anecdotal. Help them understand what they should and should not take away from their informal conversations with customers. If you have the bandwidth, help them do a better job of conducting those informal conversations.

You can’t prevent your partners from talking to users, nor should you. Rather than trying to shut these conversations down, enable your partners to use them more appropriately and effectively. Help them understand what types of customer input should and shouldn’t be used to justify product development decisions. And make sure they understand the difference between what they are doing and the rigorous research that the research team engages in.

No other discipline is democratizing, so why should we? Designers aren’t letting other people design interfaces

Yes they are! Designers aren’t expecting their partners to whip up pixel-perfect designs for new features. But researchers are expected to learn Figma well enough to edit or even create prototypes that will be used in research.

Data scientists aren’t expecting their partners to conduct deep analysis on behavioral data. But they do create dashboards to provide visibility into basic metrics, so that partners can get self-serve answers to common questions. And as a researcher, I have definitely been expected to learn and employ SQL so that I can self-serve recruiting queries.

Research democratization is no different. Our partners should not be expected to (or allowed to) create personas or answer strategic research questions through foundational research. But with the proper guidance, guardrails and oversight, they absolutely can learn to deploy a study in UserZoom or UserTesting to effectively answer basic usability questions.

Research democratization isn’t giving away the keys to the kingdom. It’s nurturing cross-functional relationships and deepening cross-functional collaboration. Personally, I’d much rather work in a company where people are sharing their expertise and enabling one another, rather than building silos and jockeying for organizational “territory”.

Our research team is already too busy. They don’t have time to support non-professionals who want to dabble in research

This is absolutely correct! If your current research team is already beyond capacity, asking them to also run a democratization program will result in over-stressed researchers, under-supported partners, sub-standard research, and a whole heap of heartache. Democratization is not a side-gig for your existing team.

A proper democratization program must be properly resourced! In most cases I believe that requires dedicating a headcount specifically to scaling evaluative research. A dedicated resource can devote all of their time to supporting partners’ research efforts, creating educational resources and supporting individual projects through direct consulting.

Many (if not most) of the projects that will come through a democratization program are last-minute projects that weren’t accounted for in the regular planning cycle. Your regular researchers cannot drop everything they are doing to support a late-breaking usability test. But a dedicated resource can!

As a dedicated democratization lead, my calendar wasn’t filled with meetings all day, the way it was when I was an embedded researcher. When a panicked PM urgently needed to evaluate a new feature before the fast-approaching launch date, I could absolutely help them when they needed it, which was now. (Of course we don’t want to encourage or reward poor planning, but anyone working in research knows that these last minute projects always materialize somehow, despite everyone’s best efforts at planning ahead.)

So who should this dedicated resource be? The democratization program head should always be a professional researcher. This role does collaborate extensively with the Research Operations team, and in some cases might even report into the ReOps team. But this isn’t a role for a ReOps specialist looking to transition into a research role. The primary value that a democratization lead brings is their first-hand knowledge and experience of how to conduct quality research. The person running this program must be an experienced researcher, and have some proficiency in teaching research concepts and techniques.

And the people who will be most successful in this role have a mindset that defaults to enabling learning and empowering others. Governance and process are very important aspects of this role, but if your default mode is one of generosity rather than a guarded or defensive stance, you and your partners will be set up for greater success.

If we teach our partners how to do research, they won’t need us anymore

This is the one assumption that I will flat out say just isn’t true.

The single most common thing I heard from partners after they engaged with my programs was, “I have so much more respect for what you do now!” Almost everyone said some version of this to me. I heard it all the time.

When your partners engage with a robust democratization program, they are learning about how research SHOULD be conducted at every step along the way. And they can see for themselves that they aren’t up to the task without your help.

Or, as Nancy Perry from Microsoft put it, “In addition to the empathy that they build with customers through this process, they’re also building empathy with us, aligning the researcher-stakeholder relationship in a more cooperative direction.”

If you just hand your partners a UserTesting account and call it a day, then they will conduct terrible “research” and likely make terrible decisions as a result, and they might even think that they can do research now. But that’s not intentional democratization.

It is absolutely possible to scale your research practice by engaging your partners to conduct their own evaluative research, if they have the necessary guidance, guardrails and oversight. If you share your knowledge and experience with them, through an intentional and well-resourced democratization program, you can get their usability questions answered, while the rest of your research team focuses on the big strategic research projects that only professional researchers are qualified to tackle.

So how do you build a robust democratization program? Here are some of the fundamental components of an intentional and rigorous democratization program:

Guidance: education on the basic principles and techniques of evaluative research

• Educational resources should be tailored to a cross-functional audience: concise, modular, and digestible.
• Educational resources can be static documents, webinars, live workshops, or any combination thereof.
• Also provide templates and examples of good research plans, discussion guides, findings write-ups, etc.

Guardrails: clarity around what the program supports, and mechanisms to ensure compliance with best practices

• Develop explicit policies on what kinds of research partners can and can’t do. (IMO, tactical evaluative research is the sweet spot for democratization.)
• Develop governance policies that ensure crucial best practices are followed around appropriate sampling, participant experience, participant privacy, bias mitigation, etc.

Oversight: personal, custom support throughout the process, ensuring quality research

• Hire a dedicated, experienced Researcher whose primary job is to build and run the program.
• Build in multiple checkpoints that require feedback before moving on to the next step in a project.
• Leverage access to enforce oversight: use access to research platforms, to recruiting platforms, to customers, etc. as leverage to ensure compliance with policies and best practices.
• Provide thorough feedback on all deliverables, and explain why you are suggesting the changes that you are. This is one of the most effective ways for your partners to learn.

To learn more about my approach to designing a rigorous democratization program, read my article Scaling Research at Dropbox, which describes the components of that program in detail. (Note that every company and product is different. This article describes what worked at Dropbox at a specific point in time. You will certainly need to make adjustments to craft a program that works in your company and context.)

And for other great perspectives on democratization, check out these excellent pieces as well:

• Give Your Research Skills Away: Why Coaching Product Teams Won’t Put You Out of a Job by Nancy Perry of Microsoft
• Five dysfunctions of ‘democratised’ research by Leisa Reichelt of Atlassian
• Democratizaton is our Job by Behzod Sirjani of yet Another Studio

What experiences have you had with democratization? What has worked and what hasn’t? Have you changed your mind about democratization one way or the other? What changed your perspective? Tell us about it in the comments below!