An Interview with Oren Friedman: Building for Machine Speed Without Losing the Human Touch
by Kate Towsey
Subscribe to get sharp thinking all about ResearchOps delivered straight to your email inbox. It’s free!
The ResearchOps Review is brought to you by Rally—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack.
In 2011, venture capitalist Marc Andreessen published an essay in The Wall Street Journal (and later on his blog)1 that opened with a prophetic line: “Software is eating the world.” Andreessen was right: software did “eat the world.” Amazon became the largest global bookseller (and marketplace); Spotify took a bite out of record labels; and Netflix devoured video stores and cinemas. As Andreessen wrote at the time, software programming tools and internet services made it “easy to launch new global software-powered start-ups in many industries—without the need to invest in new infrastructure and train new employees.” Replace “software” or “internet” with “AI,” and his statement is almost just as true now. Over the past fifteen years, software companies have transformed entire industries, the global economy, and your life and mine—as too will AI.
A few weeks ago, I sat down with Oren Friedman, the cofounder and CEO of Rally, to talk about how these economic and technological shifts are impacting research and ResearchOps, and how Rally is responding. We spoke about AI, of course, and the vision of a platform- or UI-agnostic future. But we also discussed how, just as technological advancements are making physical resources like rare earth minerals, oil, and gas more valuable2—worth fighting for, even—the ability to build human systems, and the soft skills required to build them, are becoming more valuable, too.
Soft Skills as Hidden Assets
“I don’t even know what else to talk about because it seems that the only thing that’s important right now is figuring this stuff out: stakeholder management, change management, relationship building, and the ability to sell the value of research,” said Oren during our conversation. “Every discipline is dealing with it, but I think it’s just extra potent for research professionals because of all the years spent trying to build people’s understanding of the value of research. And I do think it still comes down to soft skills. We’ve been talking about stakeholder management for years, but it’s never been more important than now to know how to talk to design, product, and other leaders and how to get in front of them.”
If you’ve worked in research for any length of time, you’ll know the ongoing challenge of encouraging colleagues from other disciplines to appreciate the value of research—or more pointedly, the value of good research…and, more recently, the value of researchers doing research at all. Most organisations are sold on the idea of including research in the product development lifecycle, and they’re investing in the operations required to make that happen, albeit through democratisation efforts.3 If you’re a research leader, the key challenge now is to upsell the importance of research quality to the same audience, which should, in turn, resolve the assumption that all research can and should be done by non-specialists and that researchers and their operational counterparts are pedantic bottlenecks.
During our conversation, Oren stressed that this stakeholder dynamic isn’t unimportant to research technology companies, like Rally: “Top of mind for us is how we can help equip research professionals to better manage these relationships so they can appeal to product, design, and other teams,” he said. “Research professionals, including ResearchOps, are coming from a position of knowledge, strength, and credibility, so how do we help reframe this subservient, hierarchical structure that’s happened within so many companies?”
Part of the solution is empathy and meeting stakeholders where they are; a core product principle at Rally. Oren spends a lot of time talking to product managers (PMs) and shared this observation: “A lot of the work people are trying to do, that PMs are trying to do, they may not even call it ‘research.’ They may not think of it in the context of a study the way a researcher would. And so, even with the basic primitives that researchers use, it can be easy to gloss over PMs who just aren’t thinking about research that way. They’re using different terminology, methods, or frameworks to reach their goal of making good decisions. They might call research ‘continuous discovery’ or ‘talking to a customer,’ for instance.”
The concept of meeting people where they are came up several times in my conversation with Oren, not only because it’s a Rally product principle, but because shifts in the product landscape mean that research professionals are being obliged (forced seemed too aggressive a word, but it’s not inaccurate), to build how research operates around stakeholders’ language and workflows—a user-centric approach, ironically.
Democratisation Is Now a Directive
Four years ago, research democratisation was a strategic choice for research leaders. In most companies, now focused on efficiency and profit, it’s a directive. Every week or two, I hear a story about a company that has laid off all or most of its research team while retaining its ResearchOps capability, tasked with democratising research across the entire company. Oren has seen this dynamic first-hand: “Just a few weeks ago, a company we work with laid off the entire research team but kept the ResearchOps team. It’s as if research and ResearchOps now have to redefine and re-articulate their value to the product team, even though a light democratization program has already been in place. Now it’s like their whole job rides on the democratization program working—and working well.”
Rather than resist the change, many savvy research leaders are leveraging the value organisations now place on well-designed research operations (used to build scaled-up research democratisation programmes) to gain the buy-in required to build better relationships with stakeholders and, eventually, to rebuild their research team. As part of this tactic, these leaders are becoming operations specialists in their own right, in line with an interesting trend in the research professional landscape. One in which researchers are doing research operations; ResearchOps specialists are being asked to lead and sometimes do research; and both are being tasked with enabling everyone else to do research. No doubt, the world is topsy-turvy. But when these savvy leaders do start hiring, they hire specialised researchers to deliver high-quality, high-priority insights to the most important parts of the organisation, hinting at an optimistic future for their operations-forward research teams.
Optimism aside, for many, the transition isn’t easy. Oren shared, “I’m noticing it’s a really hard bridge to cross for research and ResearchOps teams who, for the first time, are supporting people who are less in tune with a healthy research process.”
A Healthy Research Process
That healthy research process is key, particularly when there are fewer or no researchers involved to model good research practice. ResearchOps can do some of this work, but researchers are needed for research strategy and craft advocacy. This is truer still because AI is making knowledge or insight generation seem effortless, speedy, and requiring little skill. “The tempting thing for product teams is to try to find the fastest route to whatever insight they’re trying to capture.” Oren’s deep in the weeds of this democratization shift. “But that’s a fundamentally flawed way of approaching it because if there’s no rigour or guardrails, the quality of the insights deteriorates, then the quality of decision making deteriorates, and what does that point back to? It always points back to research, which degrades the value of research and the understanding of it within the company.”
The research profession has always been aware of the importance of pacing—slowing people down in an increasingly fast-paced world to observe, learn, question, and absorb knowledge is the ongoing operational challenge—but demonstrating the value of pausing to a sceptical product leader in the middle of a cost-cutting cycle, with access to AI, is another matter altogether.
The knee-jerk reaction is often to insert more operational guardrails and standards, but when people feel forced to work in ways that seem onerous, they tend to rebel. As Oren put it, “Research or ResearchOps might be worried that PMs are just going to log into Gong, for example, search through all the insights, reach out to customers, not obtain consent, not log anything, not send incentives, not put the data in any central repository, and so on. But for each PM, designer, or engineer, that’s the easiest path. They aren’t incentivised to think in systems; they’re incentivised to think about the fastest way to get their own job done.”
Finding the Right Balance
This push-and-pull of seemingly opposing forces—control versus convenience—has been a key challenge for research professionals for years, but solving it is more critical than ever. In a world where anyone can chat their way to an insights summary, search a call library, or vibe-code a workaround, a heavy-handed (if correct) research process is easier than ever to ignore.
“It’s this yin-yang concept of convenience: PMs and other folks want the ultimate convenience of being able to query something and go (that’s the yin).” Oren invokes the traditional Chinese symbol representing opposite yet interdependent forces. “And the other side (the yang) is control: to support good practice, ResearchOps wants to set controls in a way that enables both ultimate convenience and safe, responsible research.”
Oren says it as it is: “For too long, ResearchOps has indexed on control at the cost of convenience, and that’s what I think could lose them their jobs. Because if it’s overly controlling, then it’s like, ‘Move out of the way! I’m just going to go figure it out on my own.’ So, we’re trying to design a system that helps ResearchOps teams create these convenient experiences while retaining control. Yes, still simplifying the UI because UIs aren’t going anywhere quite yet for the non-researcher, but also starting to work towards a more agentic future where you don’t need to open a specific application to do something.”
That agentic future won’t only change how people interact with research platforms, but also how they engage with research operations: “I think gone are the days in the not-too-distant future of training people on how to use a new SaaS application that your company is adopting. Because no one has the patience or time to learn new workflows or tools, and they no longer need to. They want agents to do it all for them; to be the orchestrators of their work. So that’s the kind of vision we’re trying to work towards at Rally.”
“I-Me-Mine AI” Isn’t Enough
PMs, designers, and engineers aren’t the only people who aren’t thinking in systems. In a recent article for The ResearchOps Review,4 I wrote about the notion of “I-Me-Mine AI” and the urgent importance of research and ResearchOps professionals taking a step back from their individual use of AI to consider and design its place within their wider research system, before anyone else does.
Oren also sees the chasm between those two modes of working—individual AI use and systemic AI design—as a once-in-a-career opportunity and ticking time bomb: “The beauty is that AI now allows for quality, speed, and cost, all things that were trade-offs before. Of course, there are still trade-offs, but it’s never been easier than it is today to sacrifice less of those things, as long as things are done right. And product leaders do care about doing things right—just not if it bottlenecks progress.”
The need for mutual empathy across disciplines (again, those soft skills) is also key for Oren: “I recently spoke to a product leader who explained that AI is moving so fast that he doesn’t want to fall behind, and he doesn’t want his organisation to fall behind. So he’s doing a lot of research and investigation on the right infrastructure needed for the product team to stay ahead of the curve because they’re also worried about their jobs, and about engineers moving into their realm, and design—you know, the blending between research, design, product, and engineering…it’s very intense right now. It’s also a really exciting opportunity, but how do we get research and ResearchOps folk to the point where they can have that systems-level conversation with them?”
Research and ResearchOps professionals are well-positioned to have these conversations, but many are understandably overwhelmed by the state of the profession, the world in general (a fair reaction), the speed at which AI is developing, and the implications for their careers.
“We’re trying to encourage ResearchOps teams to lean in and become more literate with APIs5 and MCPs,”6 Oren noted. “ResearchOps professionals can help set up these systems, such as setting up the right consent forms and cool-down periods, hooking up the right integrations, and inserting the right legally approved communications throughout the entire experience. ResearchOps needs to play the role of the chief architect of scaled-up, AI-augmented research systems.”
Oren’s right, and the moment is now.
When the Interface Disappears
Just as the boundaries between roles are becoming less distinct and the shape of organisations is evolving at a dizzying pace (read Carolyn Morgan’s article, “A Practical Guide to Structuring ResearchOps Through Organizational Change”),7 the format of research platforms is changing at breakneck speed. Everywhere, CEOs and founders like Oren are working hard to keep up with the pace of change—not just to secure their own survival, but to ensure their customers can deliver the experiences their stakeholders feel they need to keep pace. “Stakeholders are already demanding a NotebookLM-like storage as an output of all research materials,” a ResearchOps professional shared in a recent exchange. For many people, their personal professional success depends on their ability to work faster, and they’re looking to colleagues in operational roles to provide the tools they need—now. As a result, ResearchOps professionals (including researchers delivering operations) are seeing their roadmaps, standard operating procedures, and purpose shift overnight from support, training, and administration to technical systems design. But they don’t have to make this shift alone; research platforms like Rally are also responding to the change.
“It’s a new experience we have to design for,” is how Oren sees it. “Basically, using MCPs, we’re trying to figure out how, through Claude or through Slack, you might run these actions without necessarily knowing what’s under the hood. Because I think that’s another one of these leaps that research and ResearchOps teams have to make. We’re thinking about AI a lot in the context of meeting teams where they are, and how they’re trying to design the future of their work, which is orchestrating different agents that interact with your organisational tools and giving ResearchOps the Ferrari on the back end—the engine on the back end—and they are the engine mechanics, making sure that things run smoothly when you get in the car and you don’t all of a sudden have a flat tire or no gas.”
The New Competitive Advantage Is Interoperability
Until recently, most research platforms were developed in isolation—it was rare for them to collaborate—but that’s starting to change. I asked Oren to discuss Rally’s perspective on building open research systems, that is, systems that can integrate with other systems, and their approach to partnerships.
“Well, I’m happy to talk about it because partnerships are a very important part of our strategy as a company. We’re building a best-in-class solution, not an all-in-one solution. Rally launched as a user research customer relationship management tool (CRM), but we’re evolving into a best-in-class research infrastructure. No matter what research you’re trying to do as an organization, you need the infrastructure underlying it to make sure that it’s efficient, safe, governed, and fast—all the value props that the different people in the company care about, whether it’s from product to legal.”
The suite of tools now available for research, both specialist and non-specialist, has exploded over the past ten years. I asked Oren how they choose the tools they integrate with. “As infrastructure, we’ve tried to be agnostic about the tools we connect to because one of our product principles is to meet our customers where they are. So, whether you’re using Qualtrics for surveys, Listen Labs for AI moderation, Zoom, Microsoft Teams, Copilot, Claude or whatever, to make research work, your tools need to talk to each other. If they don’t integrate nicely and play nicely, then you’ll spend your time reconciling two spreadsheets, which no one’s got the time for, especially these days. So, integrations have always been a really important part of our strategy. We’ve been trying to create partnerships for a while, and we’ve found that some companies are really leaning in like Marvin; they’re aligned with us philosophically as we’ve been able to collaborate on certain customer pain points that we wouldn’t be able to do if we didn’t collaborate.”
Being Human Matters
If there’s a through-line to all of this (AI, democratisation, MCPs, partnerships, and the shifting shape of product and UX teams), it’s that research and ResearchOps professionals are being drawn into a more architectural role. Research operations are now less about enforcement and more about building: creating the conditions for speed without sacrificing quality; designing “friendly guardrails” that demand perfection only where essential; and meeting teams where they are, whether that’s in Slack, Claude, Rally, or an interface that’s yet to be launched.
On the future of human-led research: “I don’t think we’re going to be moving away from solving human problems,” Oren said, “because I think there’s always going to be problems in the world that people will pay money to solve. And that’s where every product fills a certain space. So, if you believe that we’re not going to stop solving problems for humans, especially when things are moving fast and changing so much, there’s an even greater need for understanding people. If you’re going to win in this highly competitive world, you need to find those gaps in understanding and build a solution for them. And that’s what research is, whether you want to call it research or seeking understanding or learning or whatever, I think that’s not going to go away. I don’t see a world in which AI moderators are talking to AI participants, and everything is fully abstracted. Because then, what (and who) are we designing for? If there are no humans in the conversation at all, then it’s like we don’t exist. I don’t think we’re going to move into that type of world. I might be wrong. I do think there will always be a need for a better understanding of humans and solving new problems. Because I don’t think we’re going to ever solve every problem. And if we do, then it doesn’t matter anyway, because we’ll have unlocked unlimited money and resources, and no one will need to work ever again!”
In other words, even as the tooling and teams shift, and even as “research” is renamed, remixed, and increasingly mediated by machines, the crux of research remains stubbornly (and gloriously) human: to reduce the risk of building the wrong thing, for the wrong people, for the wrong reasons—and to build beautiful things, ideally.
A final word from Oren: “I would like to see the industry and the profession championing that you don’t have to sacrifice quality for speed, that it’s possible to meet the timelines and needs of the organisation, to be user-centric, and to do so with a high bar, just like all these other disciplines are being challenged to do. No one is putting rubbish designs out there because it’s faster. The bar is still really high for good design work. The same goes for marketing and other disciplines. So, if other disciplines can do it, research can do it, too. And don’t give up on that because you’re the only ones championing it. No one else is going to fly that flag. And it’s important. It matters. It may not seem like it matters today because people are getting laid off left and right, but it almost has less to do with you as individuals—it’s a market correction, I think, in the context of an overinflated tech sector. As a research or ResearchOps leader, you’re getting the short end of the stick, but don’t lose faith in your skills and your inherent value.”
Sponsor and Credits
Rally sponsored the first year of The ResearchOps Review, when it was just an idea, making the dream of a dedicated professional publication focused on ResearchOps a reality. Thank you, Oren and the Rally team.
Rally UXR—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack. Join the future of Research Operations. Your peers are already there.
Edited by Kate Towsey and Katel LeDu.
Andreessen, Marc. "Why Software Is Eating the World." Andreessen Horowitz. August 20, 2011. https://a16z.com/why-software-is-eating-the-world/.
Achleitner, Paul. "Economic Power Is Returning to the Physical Realm: Paul Achleitner on why Hardware, Not Software, Is Eating the World." The Economist, March 10, 2026. https://www.economist.com/by-invitation/2026/03/10/economic-power-is-returning-to-the-physical-realm.
Research democratisation programmes enable non-researchers to independently do and, ideally, consume existing research.
Towsey, Kate. “The Research Operating System Too Few Are Building: Why “I-Me-Mine AI” Isn’t Enough.” The ResearchOps Review, March 5, 2026. https://www.theresearchopsreview.com/p/a-wake-up-call-for-researchops.
APIs (Application Programming Interface) enable two software components to communicate with each other using a set of definitions and protocols.
MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems.
Morgan, Carolyn. "A Practical Guide to Structuring ResearchOps Through Organizational Change." The ResearchOps Review, March 19, 2026. https://www.theresearchopsreview.com/p/a-practical-guide-to-structuring-research-ops.
I love the comment "the crux of research remains stubbornly (and gloriously) human: to reduce the risk of building the wrong thing, for the wrong people, for the wrong reasons—and to build beautiful things, ideally."
Love it. Thanks Oren for those words, and to Kate for putting it together.